0902 | Local Models, Breaches and a $300 Oscilloscope

Mia: Welcome back to the show, everyone. I'm Mia.

Milo: And I'm Milo. We've got a really interesting set of conversations to dig into today, and honestly, the thread that connects most of them is that AI is showing up everywhere — in your laptop's memory, in your browser, in a courtroom, on a factory floor — and in every one of those places, somebody is arguing about whether it's real, whether it's safe, and whether it's worth the money.

Mia: Right, so we're going to move from local models running on Macs, through the safety and money debates at the big labs, into an FBI investigation and a legal fight between Apple and OpenAI, then platform politics around browsers and app stores, some deep hardware tinkering, and finally robots and world models.

Mia: And the way we like to do this is to set each story up briefly and then really spend our time on what people are actually saying in the discussions — the arguments, the pushback, the firsthand experiences.

Milo: Exactly. So let's just jump in. Mia, you've been following the local LLM stuff.

Mia: Yeah, and this one really grabbed me. So the setup is simple: someone took an M4 Pro Mac mini with 48 gigabytes of RAM and ran Qwen3.6-35B-A3B locally, quantized to 4-bit, which takes about 20 gigabytes of memory. And the clever part is the architecture — it's a mixture-of-experts style model where even though the total model is 35 billion parameters, only about 3 billion are active for any given token. So you get the knowledge of a big model with the per-token compute of a tiny one.

Milo: Which is why it's actually usable on a consumer machine. And the person's motivation is worth highlighting too, because it's not just hobbyist curiosity — they specifically cite privacy risks and cost risks with APIs. Like, every prompt you send to an API is a trust decision, and the pricing can change under you at any time.

Mia: And I think that's the emotional core of the discussion. There's a real "I want this to be mine" feeling. People who run models locally talk about it like owning your own tools versus renting them. And the privacy argument is the one that tends to win arguments — once something sensitive has left your machine, you can't unsend it.

Milo: But there's an honest counterpoint too, which is that a 3B-active model, no matter how big the total parameter count, is not going to match a frontier hosted model on hard reasoning. The people in these conversations are generally realistic about that trade. The question isn't "is local as good as the API," it's "is local good enough for my tasks, with zero marginal cost and full privacy."

Mia: Right, and that question got a much more interesting answer recently, because there's a project called slotstream. This is where it gets technical, so bear with me. The idea is: mixture-of-experts models are huge on disk — in this case a 104-gigabyte model — but at any moment you only need a few of the experts. So instead of requiring all 104 gigabytes in RAM, slotstream streams the experts it needs from the SSD as tokens are generated.

Milo: So the SSD becomes an extension of your memory. And the result they report is running that 104-gigabyte model on a 48-gigabyte Mac at roughly 12 tokens per second. Which, for a model that size on consumer hardware, is a striking number — if it holds up.

Mia: And "if it holds up" is doing real work in that sentence, because the discussion around it got spicy. Several people pushed back, saying similar implementations already existed — that the core idea of streaming expert weights from storage for MoE inference isn't new. The criticism was partly about novelty — "you didn't invent this" — and partly a demand for fair comparisons: is 12 tokens per second actually better than what prior approaches achieve on the same hardware and the same model?

Milo: That's such a recurring pattern in these systems debates. Someone demos something impressive, and the community's first instinct is to ask, "what's the baseline?" Because a demo number in isolation doesn't tell you whether you're looking at an engineering breakthrough or a re-implementation with a nice writeup.

Mia: And to be fair, the defenders' position would be that even if the idea isn't novel, making it work smoothly at usable speed is itself valuable — the gap between "someone published this technique" and "I can run this on my desk" is often where all the hard engineering lives.

Milo: Sure. Though the unresolved question hanging over the whole thing is whether SSD bandwidth — even fast NVMe — can keep up as models scale. You're betting your inference speed on sequential read throughput and the OS page cache behaving well.

Mia: Which actually connects to something we'll get to later — the Turso io_uring work — because it's the same underlying question about what storage can and can't do for you. But before we go there, there's one more piece of this "cheap inference" story that's almost the opposite end of the spectrum.

Milo: Ah, you mean the tiny Transformer.

Mia: Yes. So somebody trained a small Transformer for about an hour and a half, costing 67 cents in compute, and it scored 44 percent on ARC-AGI-1. For context, ARC-AGI is this benchmark of abstract reasoning puzzles that was specifically designed to be hard for AI, and plenty of large LLMs have struggled on it or needed elaborate scaffolding to do well.

Milo: So the headline is basically: a model that fits in a teacup, trained for the price of a candy bar, matches a lot of much bigger systems on a benchmark meant to expose their weaknesses.

Mia: And the key to how, according to the discussion, is two things: test-time learning and turning the task into a supervised problem. So instead of the model relying purely on what it memorized during training, it adapts at inference time — it studies the examples within each puzzle and learns from them before answering. Which is philosophically interesting, because it suggests that for certain reasoning tasks, the bottleneck isn't raw model size, it's the training and adaptation strategy.

Milo: And you can imagine how that lands in a community that just spent a whole thread debating whether big local models are the way to go. One camp says scale and clever weight-streaming gets you frontier-ish capability at home. Another camp says actually, tiny models with smarter test-time behavior might be the real efficiency frontier. Those aren't mutually exclusive, but they imply very different futures for local AI.

Mia: Right, and both of them share the same underlying instinct, which is that the interesting action right now is in efficiency — getting more capability per dollar, per gigabyte, per watt. And it's worth zooming out for a second on why that framing matters, because there's a broader taxonomy people use here.

Milo: Yeah — there's a useful way to split inference work into two categories. One category is trading along the existing latency-throughput frontier: things like adjusting batch size, using parallelism, applying quantization. You're moving along a curve, sacrificing one thing for another. The other category is actually pushing the frontier outward: kernel optimizations, speculative decoding, and prefill-decode disaggregation — splitting the two phases of inference onto different hardware.

Mia: And if you map our stories onto that: the Mac mini setup with quantization and a small active parameter count is partly frontier-trading, slotstream is trying to push the frontier by redefining where the weights can live, and test-time learning is a completely different axis. That's why these conversations feel like they're converging on something — everyone's attacking the cost of intelligence from a different side.

Milo: Okay, but let's zoom way out now, because efficiency is also the battleground for the big industry arguments. And this next set of stories is where it gets ideological.

Mia: So, OpenAI. They've said that a model called Astra has reached the "Critical" threshold under their own Preparedness framework for cybersecurity capability. And the supporting evidence is a perfect 100 percent score on something called ExploitBench. And crucially — their response is not to ship it immediately. They're delaying development and release to strengthen protections first.

Milo: This is one of the first times, publicly at least, that a lab's own safety framework has actually bitten — where the framework said "this is too dangerous to release as-is" and the lab publicly said "okay, we're holding it back." That's the framework doing what it was designed to do.

Mia: And the discussion splits into roughly three reactions. One camp: this is genuinely good news, this is what responsible deployment looks like, a perfect score on an exploitation benchmark is exactly the kind of capability that warrants a gate. Second camp: it's a bit self-congratulatory — the lab grades its own homework, so a "Critical" announcement is also a marketing claim about how capable the model is. "Our model is so powerful we had to hold it back" is also a flex.

Milo: And the third camp, which I find the most interesting, is the one asking the structural question: can these gates actually hold? Because the moment there's commercial pressure — a competitor shipping, revenue targets, a race — does "we're delaying for safety" survive?

Milo: The unresolved question in these discussions is whether safety frameworks are load-bearing structures or decorative ones, and honestly, nobody knows yet, because we haven't seen a case where the safety call and the business call pointed in opposite directions and the company had to choose publicly.

Mia: Which is the perfect segue, because the business reality is exactly what the next story is about. Dan Luu published an analysis going after Ed Zitron's AI-pessimist predictions, and his argument is pretty blunt: the predictions keep missing.

Mia: Zitron has argued the AI boom is a bubble propped up by unsustainable spending, and Luu's counter is to point at the actual financials — Meta, Google, and Microsoft have kept growing revenue and profit, which directly contradicts the "these companies are collapsing under AI spending" narrative.

Milo: And the reactions to that split predictably. Luu's supporters say: look, you can argue AI won't live up to the hype, but you can't argue the companies driving it are dying — the balance sheets say otherwise, and pessimists keep confusing "I don't like this" with "this is failing." The other side says revenue and profit today don't prove the AI investments specifically are justified — capex is forward-looking, and big companies can absorb enormous bets for years before the reckoning shows up.

Milo: Both positions are coherent; they just disagree about what evidence counts and on what timescale.

Mia: Right. And it's notable that neither side in that debate is really engaging the third story in this cluster, which is the human cost. Because Dwarf Fortress's creator came out and said the games industry is in a state of collapse — his words, essentially, that CEOs are eyeing a "game generation button," reaching for AI to generate games, in an industry already bleeding layoffs.

Milo: That's a quote that clearly struck a nerve. And you can see why — Dwarf Fortress is this legendary, decades-long labor-of-love project built by a tiny team, simulating entire worlds by hand-crafted systems. If anyone has standing to say "games come from craft, not from a button," it's that studio. And the fact that it's coming alongside industry layoffs makes it feel less like abstract philosophy and more like a description of people's lives right now.

Mia: The discussion around it, though, quickly turned into a debate about incentives. Some commenters fully bought the collapse framing — games have gotten enormously expensive to make, layoffs are real, and executives looking for a magic cost-cutting button is exactly what you'd predict.

Mia: Others pushed back with the profitability argument: gaming is still a hugely profitable industry, "collapse" overstates it, and every technological shift — from cartridges to engines to streaming — produced the same panic. And some pointed out the uncomfortable truth that if AI game generation does work, the market, not the morality, will decide its adoption.

Milo: So in one cluster you've got: a lab saying a model is too dangerous to ship, an analyst saying the pessimists' financial doom predictions keep failing, and a game creator saying his industry is collapsing under AI pressure. And they're all really the same question from different angles: who bears the risk and who reaps the reward? The safety threshold is about societal risk, the financials are about investor risk, and the layoffs are about worker risk.

Milo: And they don't resolve neatly, because the evidence points different ways depending on which risk you're measuring.

Mia: Exactly. And the safety thread doesn't stay abstract, either — it spills over into actual security and actual courtrooms. Which brings us to our next pair of stories, and I'll warn listeners, the first one is grim.

Milo: So the FBI is investigating a dark web service called Nexus that's selling license scans — driver's license scans from the US and Canada — and the scale here is the shocking part: over 153 million records. The suspected origin is a breach at a Louisiana-based identity verification company. And it's not a static dump; the service is growing by roughly 400,000 new entries per day.

Mia: That growth rate is the detail that changes how you read the whole story. A static breach is terrible but finite. A service adding 400,000 fresh identity documents a day means either the original breach is still producing data, or there's ongoing access, or multiple sources feeding it. It's live infrastructure, not an archive.

Milo: And the discussion naturally went to what this means for everyone whose data might be in there. A leaked password you can change; a leaked license scan includes your photo, address, date of birth, license number — the raw material for convincing identity fraud, and you basically can't rotate your face.

Milo: People were connecting this to the broader identity verification problem: companies collect these documents to prove who you are, and in doing so they create these honeypots that, when breached, undermine the very identity system they were supposed to secure.

Mia: There's also the dark-web-market angle — the fact that it's a polished service with daily additions implies organization,运营, a business model. Which raises questions about how law enforcement actually goes after this. The FBI is investigating; what "success" looks like is unclear. Do you take down Nexus? Do you trace the source breach? Do you go after buyers?

Milo: Right, and the unresolved questions are big ones: which Louisiana company is the source — that hasn't been publicly named in what we have here — and whether the daily inflow can be stopped at the source. Until the breach vector is identified and closed, 400,000 a day keeps ticking.

Mia: Now, the other legal story is a different flavor entirely: Apple versus OpenAI. According to reporting on the case, a forensic examination of a former employee's MacBook allegedly shows confidential circuit diagrams were taken from Apple and used, and — this is the part that raises eyebrows — there are claims of instructions to destroy evidence. Apple is demanding expedited discovery.

Milo: The evidence-destruction allegation is what elevates this from a standard trade-secret dispute to something with real teeth. If a court finds evidence was deliberately destroyed, that can carry serious consequences independent of the underlying claim. And "expedited discovery" is Apple signaling urgency — they want the documents now, not after a year of motions.

Mia: The discussion here — and people were appropriately careful, since these are allegations from one side of litigation — centered on what forensics can actually establish. A MacBook image can show files existed, when they were accessed, whether deletion happened and when. What it can't necessarily show, by itself, is intent or how the material was used. That's what discovery fights are for.

Milo: And there's a thematic connection to the safety discussion we just had, which is: for all the talk of safety frameworks and preparedness, a lot of AI's actual risk landscape is very old-fashioned — trade secrets, litigation, forensic imaging of laptops. The futuristic industry runs on very conventional legal machinery. And when a court says jump, companies jump, in a way that no internal framework can quite replicate.

Mia: Which is a nice bridge to our next theme, because both of those stories are about trust in institutions and platforms — and the browser wars are exactly that, but at the level of everyday users.

Milo: So, Firefox. There was a piece defending Firefox as the last bastion of engine diversity — the argument being that if Firefox goes, every browser is Chromium, one company's decisions dictate the web, and competition at the engine level dies. It's a strong argument and it clearly resonated with a lot of people who remember what the web was like when Internet Explorer had a monopoly.

Mia: But the discussion did not go the "amen" route. The pushback was immediate and concrete. People raised memory consumption, which has been a long-running Firefox complaint. People raised UX dissatisfaction — specific papercuts that piled up until they switched. People pointed at the shrinking market share and asked the uncomfortable question: is engine diversity worth it if the engine's user base collapses to nothing? Diversity you can't sustain isn't diversity.

Mia: And there was criticism of specific Mozilla decisions — the sense from some commenters that the organization's priorities drifted from the browser itself.

Milo: And I think the honest summary of that discussion is: almost everyone agrees a single-engine web would be bad. The disagreement is about what follows from that. One side says, therefore use Firefox, full stop, it's a civic duty. The other side says, therefore Mozilla needs to actually earn users back, because guilt isn't a sustainable business model and a browser people resent using isn't going to hold the line.

Mia: Now here's where it gets interesting, because Mozilla just made a move that cuts against its traditional positioning: they've shipped built-in ad blocking for iOS Firefox. Technically it's built on WebKit's content blocker API — which is what Apple allows iOS browsers to use — combined with EasyList rules. It's off by default and rolling out gradually, so not everyone has it yet.

Milo: Which is a fascinating double move, right? The same organization arguing it's the last defense of the open web is also embedding an ad blocker natively. Some users loved it — blocking ads without a third-party extension, on iOS where extension options are limited, is a genuine quality-of-life win. Others worried about the message it sends to publishers and the web ecosystem, and about the off-by-default rollout meaning nobody quite knows what configuration they have.

Milo: It's one of those changes that's technically simple and philosophically messy.

Mia: And speaking of platform control, the app store story is even more pointed. Google Play has banned Aurora Store's anonymous downloads — Aurora is the open-source client that lets you download Play apps without a Google account, and it works partly by using a shared account pool. That pool got flagged, and Google shut off anonymous access.

Milo: And the discussion around this had a genuinely surprising twist. You might expect the privacy community to uniformly back Aurora, but commenters were quick to correct a common assumption: GrapheneOS — the hardened Android project, which is about as privacy-serious as it gets — actually recommends using the Play Store, not Aurora.

Milo: Their reasoning, as people explained it, is that a shared account pool used by thousands of strangers is itself a privacy and security liability: your app downloads get associated with an account whose activity is mingled with everyone else's, and it depends on credentials you don't control.

Mia: That's such a good example of how these debates resist simple framing. "Independent client versus corporate store" sounds like an easy call, and then the security-focused community says the corporate store is actually the safer option because the independent client's workaround introduces its own risks. Users end up caught between platform control on one side and the fragility of independent workarounds on the other, and there's no clean answer.

Milo: And it loops back to Firefox nicely — the browser fight is about whether one company controls the web's engine; the app store fight is about whether one company controls what software can exist on your phone. Same tension, different layer. Users want independence; independence is hard to build and easy to break.

Mia: Okay, from platform politics down to the metal. Let's talk hardware and low-level performance, because we've got two gems here.

Milo: Start with the oscilloscope, because it's my favorite kind of story. Someone bought a Tektronix TDS7104 — a 1-gigahertz-bandwidth digital scope — for 300 dollars. When new, its list price was around 24,490 dollars. Twenty-four and a half thousand. And the catch with these old high-end instruments is they're Windows-based machines — this one runs Windows 2000 — and they're often hobbled by license keys: features like bandwidth upgrades were software-unlocked.

Mia: So the project was getting the thing fully working: reinstalling Windows 2000 on it and getting the license options re-enabled, restoring all the paid features on a machine that's over two decades old. And the discussion around this is pure appreciation mixed with war stories — people love the genre of "yesterday's flagship is today's flea market bargain, if you're willing to do the archaeology.

Mia: " There's real knowledge embedded in these old instruments that a modern budget scope simply doesn't have, even if the modern one is more reliable.

Milo: Though I'd guess there were the usual caveats too — old scopes have aging components, calibration drift, and a 1GHz spec on a 20-year-old front end isn't quite the same as a fresh 1GHz. But as a 300-dollar object, it's absurd value if it works.

Mia: Now the other side of this topic is much more current: Turso's io_uring experiments. For listeners who don't know, io_uring is the modern Linux async I/O interface, and Turso — who build database infrastructure — ran a series of experiments to see what it actually buys you.

Milo: And the findings are a nice mix of "big win" and "reality check." The big win: using read-ahead, they consolidated device requests down to roughly one twelfth of what they were. So instead of many small I/O operations hitting the device, io_uring plus read-ahead merges them into far fewer, larger requests. That's a genuine efficiency gain for storage-heavy workloads.

Mia: The reality checks: first, sqpoll — the kernel polling mode where a dedicated thread spins polling for completions — consumed 65 percent of a CPU. Which means for their use case, the polling overhead ate the benefit; you're trading I/O efficiency for CPU burn. And second, they found that plain syscalls, when the data is in cache anyway, are fast — so the async machinery doesn't help you when you're not actually waiting on the device.

Milo: That last point is the deep lesson, and it generalizes way beyond io_uring: async I/O only pays off when you're actually blocked on slow hardware. If your working set is in memory, the elegant machinery is just overhead. It's the same lesson the slotstream debate was circling — the storage layer is only the bottleneck if your data is actually on storage, and knowing which regime you're in matters more than the technique you pick.

Mia: And there's one more systems story that fits here: Martin von Zweigbergk, the creator of Jujutsu — the jj version control system — has left Google to become CTO of ERSC, where his goal is to overhaul server-side storage. And importantly, for the people worried about the project: jj continues as an open source project.

Milo: People who follow jj were clearly watching this one closely, because there's always anxiety when the driving force behind a beloved tool changes jobs. The reassurance that jj remains open source and continues was the key point. And it's a fitting note for this whole section: someone who spent years thinking about developer tooling and storage-adjacent problems is now going to attack storage directly, at a company where it's the mission rather than a side interest.

Mia: So the through-line of this whole section is people squeezing real performance out of real hardware — whether that's a 24-thousand-dollar scope rescued for 300 bucks, or twelfth-fold I/O consolidation, or rebuilding storage from scratch at a new company.

Milo: Which brings us to our final theme, and it's a fun one: robots, world models, and creative tools. This is where AI stops being abstract and gets a body.

Mia: So first, Nori Robotics showed off a dual-arm mobile robot for 1,688 dollars. Specs: 19 degrees of freedom, assembled in San Francisco, and they've articulated a vision of skill sharing — the idea being that robots could share learned skills with each other, so one robot's learning benefits the whole fleet.

Milo: The price point is the headline. Dual-arm mobile robots have historically been research-institution objects costing six figures. Under two thousand dollars changes who can experiment with them. But — and this is important — the community reaction was skeptical. A number of commenters suspected the demo was staged, that what was shown was choreographed performance rather than autonomous capability.

Milo: Which is a real problem in robotics: videos are easy to produce and hard to verify, and the gap between "a robot did this once with hidden support" and "a robot reliably does this in your kitchen" is enormous.

Mia: And that skepticism isn't hostility, exactly — it's scar tissue. The field has seen enough polished demos that underdelivered that the default reaction to an impressive video is now "show me it working in someone's unedited home." The open question for Nori is whether real users, at that price, can actually do useful things with it — because if they can, the staged-demo question becomes irrelevant.

Milo: Next, World Labs — that's Fei-Fei Li's spatial intelligence company — released Atlas, described as an omni-modal world model. The capabilities as announced: it accepts text, images, video, and 3D as inputs; it can generate video with camera control, at 1440p, up to a minute long; and it can reconstruct 3D scenes from just a few images.

Mia: The camera control detail is what distinguishes this from the video-generation crowd. Lots of models can make pretty video; far fewer give you coherent control over where the virtual camera goes, which is what you need if the video is supposed to represent a consistent 3D world rather than a flickering dream. And the "few images to 3D" capability is the same idea from the input side — the model has some internal notion of space, not just pixels.

Milo: Whether that internal notion is robust enough for real applications — robotics being the obvious one — is the open question. But you can see the trajectory: if Nori's robots and World Labs' world models are both on the same curve, the "robot learns a skill, world model provides the physics" combination is the thing everyone's imagining, and nobody's quite demonstrated.

Mia: Meanwhile, on the pure web-creative side, there's Ambient CSS version 3, which does something genuinely clever: it generates shadows physically, starting from definitions of light sources, and calibrates the result against Blender raytracing. So instead of a designer eyeballing a drop shadow, the shadow is derived from an actual simulated light setup.

Milo: And the reaction was the usual split between "this is brilliant" and "this is over-engineered." The critics focused on two things: the knob-heavy UI — all those physical parameters are powerful but operationally fiddly for a normal front-end developer who just wants a shadow — and mobile behavior, where physics-calibrated effects may not perform well or render consistently on weaker devices. Which is a classic beautiful-tool problem: technically rigorous, ergonomically questionable.

Mia: And then, to close us out, something completely charming: the Movie Scene Map. It's built from Wikidata, it maps filming locations — 15,535 of them across 166 countries, covering 13,312 films and shows — and it's completely free, with GeoJSON and CSV downloads so you can take the data and do whatever you want with it.

Milo: This is the kind of project that reminds you why the open data ecosystem matters. Every one of those points is the product of someone having carefully catalogued "this movie was filmed here" into a structured database, and now it's a map you can browse, and the raw data is yours. No AI angle needed — though I suppose you could feed it into a world model and have Atlas generate the scenes. Someone will do that within a week, mark my words.

Mia: Ha! Probably. Okay, let's pull this together, because for all the variety today, there really is one thread running through everything. Local models on Macs, expert streaming, a 67-cent reasoning benchmark, a safety gate at OpenAI, financial doom debates, a games industry in crisis, 153 million leaked licenses, Apple's forensic laptop, Firefox's survival, Aurora's ban, a rescued oscilloscope, io_uring consolidation, a $1,688 robot, and a world model that can fly a camera through a scene —

Milo: — they're all, at bottom, arguments about efficiency and trust. Who gets to run things — your machine or someone's cloud. Who verifies claims — a framework, a court, or a skeptical comment section. And whether the next capability jump is going to come from more scale or from smarter use of what we already have. Those questions showed up in every single story today, just wearing different clothes.

Mia: Which means the follow-ups to watch are pretty clear: does slotstream's approach survive the baseline comparisons, does OpenAI's safety gate hold when it matters commercially, does the Nexus breach get traced to a named source, how far does Apple's expedited discovery get, and whether Nori's robot works outside a staged video.

Milo: We'll be watching all of it. Thanks for listening, everyone — we'll be back with more.

Mia: Take care, and we'll see you next time.