A four-year-old, MIT-licensed Python library with 4,100 GitHub stars just became the internet's latest proof point for one-shot AI coding — and the interesting part isn't the Rust code, it's what the demo does and doesn't prove.
On August 10, 2026, Ruby on Rails creator DHH posted on X that Fable "one-shotted" a full Rust rewrite of TerminalTextEffects — a Python terminal-animation library by developer ChrisBuilds — using 11 million tokens in a single pass. His numbers: startup time down from 87ms to 2ms, rendering speed up 9.6x, zero runtime dependencies, and a 3MB single-file executable replacing a Python installation entirely. The post embedded a video showing all 37 of the library's built-in effects — beams, matrix rain, burn, thunderstorm, and more — animating the full Omarchy ASCII logo through the new Rust binary. It crossed 227,900 views within hours.
This isn't explainx.ai's first look at an AI-driven language migration. Bun's Zig-to-Rust rewrite, covered here in July, moved over half a million lines across 1,448 files using dozens of coordinated Claude Code agents run over 11 days. DHH's demo is the opposite end of the spectrum: one small library, one pass, one afternoon's worth of attention. Both are useful data points — for very different reasons.
TL;DR
| Question | Answer |
|---|---|
| What happened? | DHH posted that Fable rewrote TerminalTextEffects (Python → Rust) in a single 11M-token pass, with all 37 effects verified working |
| What are the headline numbers? | 87ms → 2ms startup (43x), 9.6x faster rendering, zero dependencies, 3MB static binary |
| Is this the same as the Bun rewrite? | No — Bun ported 535,496 lines with ~50 coordinated agent workflows over 11 days; this is a single small library in one pass |
| Why did startup improve so much? | Mostly because Rust removes CPython's interpreter-boot overhead — a known, structural gap, not a surprise |
| Was this an easy case? | Yes, and replies to the post said so — a small, fully-specified Python codebase with no legacy cruft is close to the ideal input for an AI rewrite |
| What would 11M tokens cost? | At Fable 5's published $10/$50 per-million rates, likely tens to low hundreds of dollars — DHH didn't disclose the exact split |
What actually happened, in DHH's own numbers
TerminalTextEffects (repo alias ttfx, also called TTE) is a real, actively maintained open-source project — a terminal visual-effects engine and Python library that animates text with effects like beams, burn, matrix rain, and thunderstorms. It's MIT-licensed, sits at roughly 4,100 GitHub stars, and — notably — the Python original already shipped with zero third-party dependencies. That detail matters for reading the claim correctly: the Rust rewrite's "zero dependencies" isn't a new property Fable invented, it's parity with what the Python version already had at the package level.
What changed is everything underneath the package boundary:
| Metric | Python (before) | Rust (after) | Delta |
|---|---|---|---|
| Startup time | 87ms | 2ms | ~43x faster |
| Rendering speed | Baseline | 9.6x baseline | 9.6x faster |
| Runtime dependencies | 0 third-party packages, but requires a Python interpreter | 0 crates, no interpreter needed | Interpreter eliminated |
| Distribution | Python package + interpreter | 3MB single static executable | No runtime install step |
| Effects verified | 37 | 37 | Full parity claimed |
DHH's video demo ran all 37 effects against the "full Omarchy ASCII logo" — Omarchy being DHH's own Arch-based, Hyprland desktop distro — as the visual proof of parity. That's a reasonable smoke test for a terminal-effects library: if every effect renders correctly against a large, real input, functional parity is plausible even without a byte-for-byte test suite comparison.
Why the startup number is the least surprising part
The 87ms → 2ms jump is the headline figure, and it's also the most structurally predictable one. Even a Python script with zero third-party dependencies still pays CPython's fixed startup tax on every invocation: interpreter initialization, sys.path resolution, and import machinery for the standard library modules the script actually uses. None of that requires a single external package to be slow — it's baked into launching the interpreter itself.
A statically compiled Rust binary skips that tax entirely. The OS loads machine code and jumps to main; there's no bytecode compiler, no import resolver, no interpreter to boot. A ~40x gap between "cold Python process" and "cold native binary" is well within the range you'd expect from removing an interpreter, independent of how good the Rust code underneath is. The 9.6x rendering-speed number is more interesting — that's compiled-vs-interpreted execution speed inside the actual animation loop, not just process startup — but it's also the number DHH gave the least detail on.
None of this makes the demo fake. It makes it exactly what a correct Rust port of a CPython program should look like. The headline is less "Fable found 40x of hidden performance" and more "Fable correctly executed a well-understood category of rewrite."
The real debate: was this the easy case?
Replies to DHH's post zeroed in on the right question. As one commenter put it, this "would be one of the easier things to do" precisely because the spec was fully written already, in full detail, as working Python code. That's a fair read, and it's worth taking seriously rather than dismissing as underselling the result.
A source-available, fully-tested, single-maintainer library with:
- No undocumented behavior or tribal knowledge
- No flaky, environment-dependent legacy code paths
- A complete, working reference implementation that is the spec
- A small, well-bounded surface area (one library, 37 effects, no external services)
...is close to the ideal input for a translation task, whether the translator is an AI agent or a human contractor. The Python source doesn't just describe what the Rust version should do — it is an executable, unambiguous, always-in-sync specification. That's a structurally different problem than migrating a production system with undocumented edge cases, flaky tests, and years of "temporary" workarounds nobody wrote down — the kind of messiness Bun's Zig-to-Rust migration had to navigate with adversarial code review and language-independent test suites as the actual safety net, not just agent output.
This lines up with a pattern explainx.ai keeps seeing across production agent harness design: agentic coding tools do best against explicit, bounded specs, and struggle more as ambiguity and undocumented state increase. A fully-specified Python library isn't a bad test — it's a genuinely useful data point about the ceiling of one-shot translation. It's just not, on its own, evidence about the messier, more common case.
That same boundary shows up in the Hacker News discussion “If AI writes your code, why use Python?”: builders report that Rust's compiler feedback can help agents converge, while repeatedly warning that whole-library generation is much less reliable than tightly scoped, test-gated work. TerminalTextEffects is the unusually favorable overlap — a complete reference implementation, a bounded target, and outputs that can be checked effect by effect.
What "one-shot" actually means here
"One-shotted" is doing a lot of work in DHH's framing, and it's worth being precise about what it does and doesn't claim. It means the task ran as a single continuous agent pass rather than the kind of multi-day, multi-agent orchestration Bun's founder documented — no fleet of 50 dynamic workflows, no 64 concurrent instances, no 11-day timeline. It does not mean zero iteration happened inside that single session; 11 million tokens is enough for a large number of internal edit-compile-test cycles within one continuous run.
The distinction matters for what builders should take away: "one-shot" here describes the orchestration shape (single session, not a coordinated multi-agent campaign), not a claim that the first draft compiled and passed with no self-correction. Both are legitimate agentic-coding capabilities — they just answer different questions about scale. Bun's rewrite proves coordinated agent fleets can execute a 500K-line, multi-week migration with human-gated review. DHH's demo proves a single session can competently and correctly execute a small, fully-specified language port end to end without that scaffolding.
What would 11 million tokens actually cost?
DHH didn't publish a dollar figure, and the input/output split matters a lot for estimating one — output tokens (the generated Rust code) are priced well above input tokens (the Python source, iteration context, and test output being read back in) on every frontier model, including Fable 5.
At Fable 5's published rates — $10 per million input tokens, $50 per million output tokens, with a 90% discount on cached input — an 11M-token task lands somewhere in the tens-to-low-hundreds-of-dollars range depending on that split and how much re-read context hit the prompt cache. That's a rough bound, not a receipt. But it's a useful contrast: Bun's rewrite burned an estimated $165,000 in token spend porting roughly 535,000 lines. TerminalTextEffects is nowhere near that scale, and neither is its likely cost — which is consistent with the "easy case" reading above, not a contradiction of it.
What this means for developers
Put next to Bun's rewrite and Anthropic's own quiet Rust port of Bun's runtime inside Claude Code, this is the third public data point this year showing the same underlying pattern from a different angle: AI-driven language migrations are moving from "impressive demo" to "routine tool," but the size and cleanliness of the source codebase is still the dominant variable in how much orchestration the task needs.
- Small, well-specified, single-purpose libraries are increasingly realistic one-shot or single-session rewrite candidates — the kind of internal CLI tool or utility library most teams have a few of and never get around to modernizing.
- Large, ambiguous, production systems still need the multi-agent, multi-day, human-gated review process Bun's team used — worktrees, adversarial review, language-independent test suites as the merge gate — not a single long prompt.
- The performance story in language ports is often structural, not magical. A Python-to-Rust rewrite removing interpreter overhead should look like this. Reading the specific numbers (interpreter tax vs. actual algorithmic improvement) matters more than reacting to the headline multiple.
- "One-shot" is a claim about orchestration, not about zero iteration. Both single-session and multi-agent-fleet approaches are legitimate; they solve different scale problems, and conflating them overstates or understates what either one proves.
Honest limitations
- This is one person's public post with self-reported numbers, video verification, and no independent benchmark suite published alongside it — treat it as a credible demo, not a peer-reviewed result.
- DHH's account and prior track record (Rails, 37signals, Omarchy) give it more credibility than an anonymous claim, but "43x faster" and "9.6x rendering" weren't accompanied by published benchmark methodology, hardware specs, or the actual token-by-token transcript.
- Whether this generalizes to less clean, less fully-specified codebases is genuinely unresolved — the replies raising that question are correct to raise it, and this post doesn't have a definitive answer either.
- No official statement from Anthropic accompanied this post; it is a third-party usage report, not a benchmark Anthropic itself published.
Related on explainx.ai
- Bun's Zig-to-Rust AI rewrite: what builders should actually steal
- Claude Code quietly ships a Rust-rewritten Bun runtime
- Turso: SQLite rewritten in Rust — MVCC, async I/O, vector search
- Claude Fable 5 and Mythos 5: SOTA autonomy and safeguards
- What is an agent harness? The scaffolding layer that makes AI agents reliable
- Claude Opus 5 games go viral: one-prompt browser worlds
- OpenCut's rewrite: plugins, headless mode, and an MCP server
- Hacker News: If AI writes your code, why use Python?
Primary sources: DHH on X, August 10, 2026 · TerminalTextEffects on GitHub
Numbers and claims in this post reflect DHH's public post as of August 10, 2026. Token cost estimates are calculated from Fable 5's published API pricing and are illustrative, not an official figure — re-check current pricing and any follow-up benchmarks before treating them as exact.
