1020 | Models, Agents, and Broken Trust

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

Milo: And I'm Milo. And honestly, today's episode is one of those days where you can feel the ground shifting. There's a new model race happening right now — faster, cheaper, and in at least one case, built on a completely different way of generating text. And those models are almost certainly going to power the agents that show up in every other story we're covering today.

Mia: Yeah, we've got AI agents both building software and, in one case, breaking into over a hundred websites. We've got monopolies in court, some wild open-source OS milestones, and hardware doing things drones and spacecraft have never done before. So let's just dive straight in, because the model releases alone are a lot.

Milo: Right. So the headline one: Inception has launched Mercury 3, a diffusion LLM. And this is interesting not just because of the numbers, but because of how it works. Instead of generating tokens left to right like every transformer you're used to, a diffusion model starts with noise and refines chunks of text toward the answer. What that buys them is speed — Mercury 3 claims over a thousand tokens per second.

Mia: Which is the number everyone fixates on. But the claims around it are aggressive in other ways too. It supposedly beats GPT-6 Luna and Haiku 5.5 on benchmarks, it's got a one million token context window, and the launch pricing is ten cents in, thirty-five cents out. Those are bottom-of-the-market prices for something claiming frontier-adjacent quality.

Milo: And that combination is what kicked off the real discussion. Because a bunch of commenters were saying, okay, great, benchmarks — but benchmarks are exactly where diffusion models have historically looked fine and then fallen apart in actual use. There were people pointing out that if you've been following this space, every generation of "benchmark-beating" models gets a few weeks of real-world testing and then the picture gets messier.

Mia: That was the recurring theme: "wait for the evals that aren't the launch evals." One commenter put it as, diffusion models promise parallel generation, so the question isn't speed, it's whether coherence survives — especially on long generations, coding, agentic tasks where errors compound. A million-token context on a diffusion architecture is genuinely unproven territory. Nobody's run long-horizon agent workloads on this thing in public yet.

Milo: But the skeptics weren't dismissive. There was a real thread of "if anyone can pull this off, it changes the economics of everything downstream." Because — and this connects to the other releases — the entire market is in a price war.

Mia: Yeah, so the same day-ish, MiniMax dropped M3.1 Flash. The specs: 428 billion total parameters but only 23 billion active — so it's a big sparse model that only fires a small slice per token. It's seventy percent cheaper than before, three times faster, and the pricing is fifteen cents in, sixty cents out. And the claim that got attention was strength on agentic, coding, and cybersecurity benchmarks specifically.

Milo: Which matters for the reasons we'll get to later in the episode — these models are being deployed as the brains of autonomous agents. But the immediate reaction was about the pricing curve. Commenters were doing the math out loud: a model that's fast, sparse, and dirt cheap changes what's economical to run. Tasks that nobody would've paid frontier prices for suddenly pencil out.

Mia: And then DeepSeek joined the party with V4.1 Flash 1017. Same pattern, even more extreme sparsity: 552 billion total parameters, only 16 billion activated per token. 230 tokens per second, million-token context, and they're citing a "knowledge index" of 45. The naming — a flash variant with a date suffix — suggests this is a fast-iteration cadence now, not an annual release cycle.

Milo: Right, and one commenter made the point that's worth dwelling on: with activation ratios this low — 16 out of 552, that's about three percent of the model firing — the game has become "how much capability can you pack into weights you barely touch." It's a very different engineering philosophy from a dense model.

Milo: The disagreement in the thread was whether this sparse approach actually generalizes as well as dense models on hard reasoning, or whether you're getting good benchmark scores and weaker tails.

Mia: Which nobody had settled. It was genuinely contested — some people said their own quick tests matched the claims, others said the benchmarks don't capture what they care about. Unresolved, basically.

Milo: Okay, but before we move on, there were two adjacent items in the discussion that I thought enriched it. One was Mistral's Timestral — a time-series foundation model, four sizes from 5 million to 209 million parameters, top results on GIFT-Eval and a couple of other benchmarks, and it can run inference on a CPU. Small footprint, specialized domain.

Mia: That one got a warmer reception than the big general models, actually, because time-series forecasting is a place where "good enough and cheap" is exactly what practitioners want. And the CPU inference thing was a genuine talking point — people running forecasting on modest hardware without GPU costs.

Milo: And the second adjacent item: CERN and Mistral announced a strategic partnership to build what they're calling the first foundation model for collider physics, trained on billions of LHC collision events.

Mia: That one split the comment section in a fun way. One camp: this is exactly what public science institutions should be doing — training on domain data the labs themselves generated. The other camp was more skeptical about whether a general-purpose foundation model approach even fits physics data, versus task-specific models.

Mia: There were also a few jokes about the LHC finally producing something other than collisions — but the substantive question, whether "foundation model" is the right frame for scientific instruments, went unanswered.

Milo: Alright. So, those fast, cheap models are built to run agents. Which brings us to the big theme of the middle of the show: AI agents are changing how software gets built, and the humans in the loop are scrambling to adapt.

Mia: Start with the Ask HN thread, because it's the most relatable one. The question, essentially: how do engineers deal with shipping AI-written code they don't fully understand? And the person asking was describing a real emotional and professional discomfort — the code passes, it works, but they couldn't have written it, and they can't vouch for it line by line.

Milo: The responses clustered around a few positions. The dominant one — and I want to be careful, it wasn't unanimous, but it was the biggest camp — was: stop trying to review line by line, invest in tests and planning instead. The reasoning was that if you specify the behavior precisely and encode it in tests, you get verification without comprehension. You understand the contract, not the implementation.

Mia: But there was pushback, and the pushback is worth taking seriously. Several commenters argued that tests only cover what you thought to test, and the dangerous bugs in AI-generated code are exactly the ones you didn't anticipate. A test suite written by someone who doesn't understand the code can be confidently wrong. One person's framing was that comprehension debt is real — you're borrowing against future debugging sessions.

Milo: And there were firsthand experiences on both sides. People who said their teams had effectively restructured around this — planning documents got heavier, code review got lighter, and velocity went up. Others told stories about shipping agent-written code and paying for it later in incidents that took longer to diagnose precisely because nobody understood the code.

Mia: The unresolved question at the bottom of the thread was basically: does review culture scale to agent volume? If one engineer is overseeing the output of five agents, line review is mathematically impossible. But what replaces it — tests, planning, gradual trust — is still being invented in real time. Nobody claimed to have it figured out.

Milo: And there's a real-world data point that speaks directly to that: the PostgreSQL 19 beta process. Something like eight to ten significant features got reverted out of the beta. And the reporting around it noted that LLM-assisted review had raised the quality bar on older code — meaning reviewers, now armed with AI tools, were scrutinizing longstanding code more aggressively and finding problems that justified pulling features.

Mia: That one produced an interesting split in discussion. Some commenters read it as a triumph: more scrutiny, higher standards, features that couldn't meet the bar got cut before they shipped. That's the system working. Others were more uneasy — the point being that a raised bar changes what kinds of features can ever land. If every addition now has to survive a much harsher review environment, you may get a more conservative codebase, and some of those reverts might have been fine.

Mia: Whether the bar went up for good reasons or just because the tooling enabled more nitpicking — genuinely disputed.

Milo: And then there's the darker, more philosophical corner of this theme: a Ruby developer archived all of their gems. Publicly withdrew them, effectively. And the stated reasoning was striking — the claim was that Ruby and Rails are now being developed with LLM agents, and that the commons — the open-source ecosystem — is being strip-mined for training data without anything flowing back.

Mia: That thread got emotional fast. On one side, real sympathy: maintainers burn out, corporations build billion-dollar products on top of freely-given code, and now models trained on that code are generating the next generation of it. The argument was that the implicit bargain of open source — visibility, credit, contribution — is breaking because agents don't give credit and don't contribute back.

Milo: The counterarguments were also strong, though. Some commenters said pulling your gems hurts downstream users, not the model trainers — the training data's already been collected, archiving now is closing the barn door after the horses. Others said the whole framing of "strip-mining" is wrong because training on public code was always within the license terms.

Milo: And a few took the practical line: if you think agents write most new Ruby, then the surviving human-authored code becomes more valuable, not less.

Mia: Where did it land? Nowhere, really. It's one of those threads that's more of a symptom than a debate. But there were two supporting pieces inside this discussion that connected things.

Mia: One was Anthropic's "superfan" agents per component — their internal setup where dedicated agents monitor each component — and the point commenters kept making was that agents are actually pretty good at change-point monitoring, at solving the precision-recall tradeoff in deciding when something's worth a human's attention.

Milo: Which is, interestingly, a version of the answer to the review question — not "review everything," but "build agents whose whole job is noticing when to interrupt you." Whether that generalizes beyond Anthropic's internal infrastructure, unclear.

Mia: The other supporting bits were very hands-on: a writeup on managing Claude Code-type agents through tmux — using sessions, send-keys, and capture-pane to run multiple agents and steer them from a terminal. And the author's own reported limit: past about four agents, it stops working well. You can't keep four-plus agent conversations in your head.

Milo: That number — four — got picked apart a little. Some people said it matches their experience exactly; others said the limit is really about the interface, and that if your tooling summarized agent state better, the ceiling would move. The interface question keeps coming back: we're running many-agent systems through tooling designed for one human in one terminal.

Mia: And one more thing inside this cluster, because it's too good to skip: one-hash Bloom filters. The Lu et al. approach uses a single hash function but derives k coprime partitions from it, and Bluesky's been running their "gloom" implementation in production for nine months.

Mia: It showed up in the discussion mostly as a reminder that the non-agent parts of infrastructure are also evolving — and a few people appreciated it precisely because it's a small, verifiable, understandable piece of engineering, in contrast to the giant incomprehensible agent output we'd just been discussing. Someone said, half-joking, "this is the kind of code you can actually review," which, given the earlier thread, landed.

Milo: Okay. So we've had agents writing code. Now let's talk about agents doing damage — because this next story is the one that made the most jaws drop today.

Mia: Yeah. A hacker — or at least, someone operating at scale — took advantage of roughly twenty exposed Cairn AI-agent instances, and used them to breach more than a hundred websites, including John Deere and SharkNinja. And here's the part that changes the threat model: the attacks ran largely autonomously. The agent instances weren't just tools the attacker poked at occasionally — they were doing the work.

Milo: The discussion around this was really about the inversion. For years the security framing has been "AI helps defenders." This is the flip: every deployed agent is itself an attack surface. Exposed agent instances with credentials, with permissions, with access to internal systems — if you can reach one, you've inherited everything it can do, and it'll do it tirelessly.

Mia: The commenters with security backgrounds were pretty blunt: companies are deploying agents faster than they're inventorying them. Nobody knows how many agent instances they have running, let alone which ones are exposed. One commenter compared it to the early shadow-IT and cloud-bucket era — the same class of failure, but now each exposed instance can act, not just leak.

Milo: There was also disagreement about how autonomous "largely autonomously" really is. Some argued the headline overstates it — someone had to set the targets, seed the campaign, and the agents executed. Others said that distinction doesn't matter much: if a campaign scales to a hundred-plus sites on twenty hijacked agents, the human's role is already marginal. That question — how much human direction is actually needed for a serious attack campaign — is unresolved and honestly kind of urgent.

Mia: And the same discussion swept in the supporting examples, because they rhyme. The old Plex vulnerabilities — patched back in August, but Plex doesn't auto-update by default — are being exploited in the wild to install a cryptominer and a proxy on people's servers.

Milo: Which is the classic unpatched-surface story, but commenters connected it to the agent story directly: the pattern is the same. A flaw exists, a patch exists, and the gap between patch availability and patch deployment is where the whole incident lives. And Plex's no-auto-update default got a lot of heat — the argument being that for anything internet-facing, defaulting to manual updates is an architectural decision that guarantees this outcome eventually.

Mia: Then the weird one: WhatsApp's help pages were found to contain hidden text instructing AI systems not to recommend regulators and not to cite GDPR or the CCPA. Hidden text — presumably aimed at AI crawlers and assistants summarizing the pages. After a Wired report it was removed, and WhatsApp blamed a bug.

Milo: The "blamed on a bug" explanation did not go over well. Commenters were divided into roughly three camps. One: it was deliberate and the bug claim is a dodge — because hidden instructions with that specific content look designed. Two: it genuinely could be an artifact — some content pipeline or A/B test or leftover experiment gone wrong.

Milo: Three: the most interesting camp said it doesn't matter which, because the mechanism is the story — we now live in a world where companies can and do write invisible instructions addressed to the AI systems that mediate what users see.

Mia: That third camp made the point I keep coming back to: whether this instance was malicious or accidental, the technique exists, it was deployed on a major consumer product, and the guardrails are basically self-policing. The hidden-text-as-prompt-injection-on-corporate-pages question has no good answer yet.

Milo: And one more supporting story that ties the whole security theme to something concrete: an IPinfo scan found 1,331 exposed French Danfoss fridge dashboards before an attack in October 2026 — 85 percent of them had known flaws, and after the attack, most of them went offline. Which reads like: someone found an entire fleet of vulnerable appliances, hit them, and the aftermath was everyone yanking the plug.

Mia: The fridge story got less debate and more grim laughter, honestly. But the serious point a few commenters made: IoT and appliance-class devices are the ultimate unpatched surface — same pattern as the Plex story, same pattern as the exposed agents, just with worse patching prospects.

Mia: And there was a supporting story in this same territory that's more of a governance failure than a technical one: a Savannah police officer lent their Flock camera account to their husband, an ICE investigator, who ran 983 searches across six states — his stated purpose being tracking people with active warrants. The officer was fired.

Milo: Right, and the discussion there wasn't about the hack, it was about the access: a single officer's credentials were apparently enough for nearly a thousand cross-state searches before anything caught it. People drew the line from that to the agent story — access controls designed on the assumption of one accountable human per account are breaking everywhere, whether the account gets lent to a spouse or hijacked by an attacker.

Mia: Alright. From agents attacking to power on trial — the courts are having a moment with dominant firms.

Milo: So the big one: Verisign, which holds the monopoly on .com registrations, is facing a consumer class action — with ICANN as a co-defendant — alleging unfair price increases. The core fact that made everyone's eyebrows go up: the underlying cost of a domain is roughly three dollars, and prices have risen more than 30 percent since 2021.

Mia: The discussion here was part economics, part "how did we let this happen." The monopoly itself dates back decades — Verisign runs the .com registry under agreement with ICANN — so the class action isn't challenging the monopoly's existence, it's challenging how it's priced. And commenters who knew the history pointed out the price caps in the registry agreements have been loosened over the years, which is what made the recent increases possible.

Milo: The counterpoint, and it was made sincerely: registry economics aren't just raw cost. Running critical internet infrastructure to a certain standard isn't free, and "cost is three dollars" is doing a lot of rhetorical work in the headline. But the rebuttal to that was basically "thirty percent in a few years on a captive market is not cost recovery, it's monopoly rent." Where the court lands — nobody knows.

Milo: But the fact that ICANN is named as a co-defendant means the suit is also testing whether the oversight body itself can be held accountable for the deals it signs.

Mia: Then the egg story, which is wilder than it sounds. The DOJ and others have been arguing in litigation that the three biggest egg producers coordinated their bids to prop up prices during the spike — and the reporting now treats the conspiracy story as established fact, not allegation.

Milo: The comment thread there was a mix of vindication and cynicism. Vindication because when egg prices spiked, "price gouging" and "collusion" were the dismissed explanations, and now the DOJ suit is asserting coordination in bidding specifically — which is a much stronger claim than parallel pricing.

Milo: Cynicism because several commenters said this is the predictable output of any concentrated industry: three firms controlling most supply will find coordination, formal or informal, and enforcement comes years after the damage.

Mia: The open question there is remedies. Even if the suit succeeds, commenters asked: what's the fix? Fines that are smaller than the profits? Divestiture? Nobody had a satisfying answer, which is a recurring note today — enforcement exists, but nobody's confident it changes behavior.

Milo: And the third one takes us to Brazil: Lula supporters protested outside Meta in São Paulo, alleging the platform favored Flávio Bolsonaro — and Brazil's electoral court gave Meta 24 hours to prove its fairness.

Mia: Twenty-four hours is the detail everyone fixated on. The discussion compared it to how other jurisdictions handle platform-bias claims — anywhere else, this would be years of discovery and expert reports. Brazil's electoral court basically said: show us, now. Some commenters found that refreshingly decisive; others said it's theater, because no platform can "prove fairness" in a day, which means the deadline functions as a political statement either way.

Mia: And this connects back to the WhatsApp hidden-text story, actually — in both cases, the platform's claimed neutrality is being tested by outsiders, and in both cases the platform's own artifacts are what get examined.

Milo: Okay, pivoting to something more fun, but with the same underlying theme of things crossing boundaries: open-source operating systems are blurring into each other.

Mia: Start with OpenBSD 8.0, because the headline items are genuinely surprising. The drm graphics stack is now based on Linux 6.18.y — so OpenBSD is shipping a Linux-derived graphics driver stack — with Intel Arc support. Clang/LLVM 22 as the base compiler. And vmm, the native virtualization, now supports up to 64 vCPUs.

Milo: The Linux-derived drm stack is the part people had feelings about. The pragmatist camp: graphics drivers are a porting nightmare, borrowing the Linux stack is how you actually get Intel Arc working, and ideology loses to working GPUs. The purist camp mourned a little but mostly conceded the point. The 64-vCPU vmm number got the virtualization folks excited — that's real server-shaped capacity now, not a toy hypervisor.

Mia: And then the even better one: Wine has been ported to OpenBSD. Sixty-four-bit Windows apps run — and the proof point that made the thread: Witcher 3 REMASTER runs. They did it with things like %gs emulation to handle the segment-register tricks Windows code relies on.

Milo: Which, for people who don't follow this stuff, is a genuinely hard piece of systems work — emulating x86 segment register behavior on a different OS is deep plumbing. The caveats were stated clearly, though: 32-bit support is absent, so older Windows apps don't work, and nobody in the thread claimed otherwise.

Milo: The open question was whether 32-bit would ever come, given how much old software depends on it — opinion split between "eventually, demand exists" and "the 64-bit world has moved on, don't hold your breath."

Mia: Meanwhile Linux 7.3 landed at record scale: 18,765 commits from 3,021 developers. And it includes two things that got attention for being delightfully weird: failfs, where all file operations fail — deliberately — and fchroot.

Milo: Failfs sounds like a joke until you think about it: a filesystem designed to fail every operation is a testing tool, a way to exercise error paths that almost never get hit in real usage. Several commenters said error-path coverage is one of the weakest spots in most software, and a kernel facility for systematically testing failure is smarter than it sounds.

Milo: Fchroot similarly — it's about chroot in a smarter way, and the details of what it enables were debated, mostly by people who'd actually read the patch discussion.

Mia: The record commit count prompted the usual debate about whether commit numbers mean anything — one camp said it reflects genuine growth in contributors and subsystems, the other said it's just larger companies pushing more automated and bot-generated patches. Nobody could settle it, but the developer count — over three thousand distinct people — was hard to wave away.

Milo: And inside this same discussion, three supporting items rounded out the picture. First: Mac.apk — runs Android apps natively on Apple Silicon, no emulator, no VM. In testing, 51 of 65 apps were fully playable, and it's alpha.

Mia: People were skeptical of the compatibility number until they read the approach — it's not emulation, it's mapping the Android runtime onto the Mac environment. The alpha caveat was respected, but "fully playable" for games is a high bar, and 51 out of 65 made people sit up. Second: the ASUS ProArt P16 with an RTX Spark and 128GB of unified memory, running Arch Linux ARM — about 116GB of that memory is visible to CUDA.

Milo: Which is the number that matters: unified memory means a single Linux ARM laptop can put over a hundred gigabytes in front of the GPU. For people running big models locally, that was the most practically exciting spec in the whole episode. The reported CPU performance roughly matched or beat Windows on the same hardware, which the Linux-on-ARM camp took as a victory lap.

Mia: Third, a bit of ops reality to balance all the shininess: GitHub had performance degradation across Actions, Pages, and Webhooks — workflow processing and webhook delivery delayed, mitigations on October 19th, monitoring continued afterward. It showed up in the discussion as the reminder that even the substrate everyone's agents and CI pipelines run on has days where it limps.

Mia: Somebody made the obvious connection: your agent-driven build pipeline is only as reliable as the for-profit pipeline underneath it.

Milo: Alright, last segment — hardware doing new things, in the air, in space, and in the lab.

Mia: The drone story first, because it's the most counterintuitive. Someone built a drone with only one motor. One. The trick: instead of a swash plate — the mechanical linkage that lets a helicopter rotor change pitch — the design uses a hinge, a magnetic encoder, and torque modulation. And here's the wild part: the rotor and the payload spin together.

Milo: The engineering discussion was genuinely good. People who know rotorcraft immediately understood the implication: the swash plate is one of the most mechanically complex, failure-prone parts of a helicopter, and this design deletes it entirely, replacing mechanical pitch control with electronic torque control on a spinning body. The obvious objection — doesn't the payload spinning be a problem?

Milo: — was addressed by people noting that for sensing and imaging you can deal with rotation, or counter-rotate optics, and that simplicity and mass savings might be worth it.

Mia: The skeptics asked about control authority and efficiency — modulating torque for control is lossy compared to pitch control, at least in theory. Whether it scales beyond small drones, whether it's actually more efficient in practice — all open. But nobody disputed the core achievement, and the video, per the thread, was convincing.

Milo: Then a very different use of the same technology: Ukraine's 92nd Brigade says they've done the first evacuation of a wounded soldier by drone — a heavy-lift hexacopter pulling a wounded person out.

Mia: That one had a somber, practical discussion rather than a hype one. The points made: casualty evacuation under fire is one of the most dangerous operations in warfare — traditionally you risk a helicopter and crew to get one soldier out. If a drone can do it, the calculus changes completely. Commenters noted this is a natural evolution given how drones have reshaped the battlefield, but also that a claim from a brigade is a claim — the details of how it was verified weren't in what we have.

Milo: Up next, space: ESA's Hera mission will rendezvous with Dimorphos and Didymos in November–December 2026, and image the crater DART left when it slammed into the asteroid back in 2022 — from about 25 to 30 kilometers out.

Mia: The discussion here had a nice arc. DART was the first test of deflecting an asteroid, and it worked — we changed Dimorphos' orbit. Hera is the follow-up that finally looks at the crime scene up close: what did the impact actually do to the body? Commenters pointed out the planetary-defense significance: every future deflection mission will be designed based on what Hera finds about how the crater formed and how the asteroid responded.

Milo: And the mood in that thread was unusually positive — one of those rare space stories where the plan is funded, the timeline is near, and the science is clear. The main uncertainty people flagged was just how much the asteroid's structure surprised us last time, and might again — rubble piles behave unpredictably.

Mia: And the last one brings it down to Earth, or rather into it: organ-on-a-chip technology as an alternative to animal testing is advancing — but per an IEEE report, the main barriers aren't the chips. They're validation methods and the culture and habits of the scientific world.

Milo: That framing is what made the thread interesting. The technology, by the reporting, is progressing; the obstacles are institutional. Commenters with lab experience chimed in on what that means in practice: regulatory frameworks are built around animal data, labs are organized around established protocols, careers and methodology are built on decades of animal models. A chip that produces equivalent data still has to fight its way through a system designed for a different kind of evidence.

Mia: Some pushed back gently, saying the culture isn't mere stubbornness — animal models capture whole-organism effects that chips genuinely can't yet, so skepticism is partly scientific caution. Others replied that this is exactly why validation standards for chips need investment — you can't ask a new method to meet a bar that's never been defined for it.

Mia: And that's where we'll leave it, because it's the same note a lot of today's stories end on: the capability is arriving faster than the systems for trusting it.

Milo: That's a good place to close. Fast models shipping faster than anyone can evaluate them, agents writing code faster than anyone can review it, agents breaking things faster than anyone can patch them, courts testing monopolies faster than remedies exist, and hardware doing things our categories weren't ready for.

Mia: Thanks for spending your half hour with us. We'll be back tomorrow — presumably with three more model releases.

Milo: See you then.