Paul Dix and Drew Breunig examine Claude Fable 5 from different sides: the large rewrites verification can support, and model costs for everyday work.
What they said
Paul Dix, founder and CTO of the database company InfluxData, was reacting to Bun 1.4, a JavaScript runtime whose maintainers used AI to convert its code from one programming language (Zig) to another (Rust) at large scale. Dix wrote:
“The fact that AI wrote 1M LOC and then refined it over the course of the next couple of months to produce a reliable piece of software that is currently running on millions of developer machines is absolutely mind blowing. […] If you can build a verification system and give proper direction, AI can produce a highly complex, highly sophisticated piece of software and it can continue to refine it until it just works.”
(“1M LOC” means roughly one million lines of code, the individual lines of instructions that make up a program.)
Drew Breunig, an AI writer and data strategist, was writing about the same model from the cost side. He argued that before Fable, developers had little reason to fine-tune how they used AI coding tools, because a newer, cheaper model would arrive soon and paper over the difference anyway:
“Prior to Fable, it felt silly to waste too much time improving your coding harness or context strategies. […] But then Fable landed. It was (and still is!) incredible. But the cost was so high and Opus was good enough […] for most of the code we needed.”
(“Coding harness” means the surrounding tooling and workflow that manages what an AI coding assistant does and how; “context strategies” means decisions about what information you feed the model before it starts a task. Breunig’s point is that neither was worth optimizing when a cheaper, better model was always about to arrive anyway.)
He pointed to GLM 5.2, a rival model that came out the same week as Fable, as one reason the calculation changed: he estimates it costs roughly a ninth of what Fable charges per use, and about a fifth of what Opus 5, a less expensive Anthropic model one step down from Fable, charges.
Who they are
Dix built InfluxDB, an open source database designed to store and query time series data, meaning data points recorded with a timestamp, like sensor readings or server metrics over time. He is commenting on Bun’s published rewrite. Breunig previously led data science and strategy work at PlaceIQ and its parent company Precisely, and now writes and advises on AI and data strategy, including work with the Overture Maps Foundation, a nonprofit that maintains shared map data standards.
The rewrite behind Dix’s claim
The project both are circling is worth spelling out, because it’s unusually well-documented. Bun, a JavaScript and TypeScript runtime (the underlying program that executes that code), was acquired by Anthropic in December 2025. In May 2026, its creator used a pre-release version of Fable to translate roughly 535,000 lines of Bun’s Zig code into new Rust code, according to Bun’s own blog post about the project. The rewrite reached merge in 11 days, with about 6,500 non-merge commits, saved code changes. Token consumption was worth about $165,000 at API prices.
Bun reported 19 known regressions, failures of previously working behavior, and said each had been fixed. Further testing and hardening continued after the merge. Dix’s “oracle” is the existing Zig codebase and its large pre-existing test suite: a known-good reference the AI’s Rust output could be checked against automatically, over and over, until it matched.
What they get right, and where it’s incomplete
Dix’s underlying point holds up: this wasn’t a demo. It was a large rewrite of infrastructure-level code, checked against real tests, that shipped and is running in production today.
But the case study has a limit worth naming directly: Anthropic owns Bun and used its own model to rewrite its own now-owned codebase. That doesn’t make the results fake, but it means this is a vendor demonstrating its product on an asset it controls, not an independent team’s arm’s-length experiment. It’s also a best-case scenario for the “verification system” Dix describes: Bun already had years of rigorous, human-written tests to check the AI’s work against. A project without comparable tests would need substantial work to build that verification system.
Breunig’s tiering argument is grounded in something concrete, a real, if self-reported, price comparison, rather than a vague sense that AI is “getting expensive.” The specific cost ratios are Breunig’s estimates. His broader claim, that teams now have to decide deliberately which AI model handles which task, doesn’t depend on the exact ratio being precise.
Where they agree, and where they diverge
Both argue that stronger models make workflow design more consequential. Before Fable, according to Breunig, it wasn’t worth investing in how you used AI coding tools, because the next model would likely be both better and cheaper. Fable broke that pattern: a real capability jump that didn’t arrive at a lower price.
Where they diverge is what to do about it. Dix highlights what a large token budget and strong verification made possible. That example does not establish the most expensive model as a requirement for every large task. Breunig’s advice points the other way for everyday work: don’t default to the expensive model, because cheaper options are good enough for most tasks, and the price gap is large.
Why it’s notable
Most coverage of a new flagship AI model centers on benchmark scores. Both of these takes skip that entirely and focus on what changes in day-to-day engineering practice once a model is both meaningfully more capable and meaningfully more expensive than what came before. That’s a more useful signal for builders than another leaderboard placement, because it’s about how the tool gets used, not how it scores in isolation.
What it means for builders
Before reaching for the most capable, most expensive model on a large task, ask whether you have a way to check its output automatically, tests, a working reference version, or some other objective pass/fail check. That verification step, not the model’s raw capability, is what let Dix’s example turn into working software instead of a pile of AI-generated code nobody could trust.
For routine day-to-day work, don’t assume your most expensive model option is the right default. Compare task correctness, retries, and total cost across the models available to your workflow. Treat model choice as a decision you make per task, based on both the stakes and whether you can verify the result, not as a single default you set once and stop thinking about.
End of article