I ran npm install -D tsc-rs on a four-core sandbox, wrote a three-line TypeScript file with two obvious type errors, and pointed the new binary at it. It printed the same two errors as TypeScript 6.0.3, word for word, and --version answered “Version 7.1.0-dev”. That is ts-rust v0.1.0, a Rust port of Microsoft’s Go-based TypeScript compiler, written almost entirely by coding agents. The codebase port cost is the interesting part, and my verdict is that the headline number hides the real lesson: the author threw his first attempt in the garbage, and that is what saved him money.
I care because agents touch Trellis code every day, and sooner or later somebody says “let’s just have the agent rewrite the whole thing.” Mettons a 40,000-line module and a meter running for a month while the agent says “almost there.” I made up the module, not the feeling. So I read the v0.1.0 release, the README and the history file, and ran the thing for a few minutes.
What did the codebase port cost, and whose number is it?
Every number here is the author’s own. I did not reproduce any of them, and the author is not a neutral party. The README says he spent “over $400,000 in API priced tokens” on two OpenAI models, GPT-5.6 Sol and GPT 6 Astra. They wrote “over 1.3m lines of Rust over multiple months of /goal loops and never got past like 84% compat.”
Then he tried Claude Opus 5.5, mostly because his Claude Code limits were barely moving. It had a working v0 in 10 hours. He assumed it was building on the Codex code. It was not: “Opus 5.5 started from scratch.” Total was about $24,047 of API spend over two weeks, which the README says worked out to somewhere between 925% and 983% of his $200 plan’s weekly limits.
Two things to say about those figures. “API priced” means what the tokens would cost at list price, not what left his bank account. The $24,047 is the same kind of number, an API-equivalent value of heavy use on a flat plan, so the real cash was probably lower and I cannot tell you how much. And the README is not even consistent with itself: the top line says “over $420,000” and “you could probably have done it for ~$20k,” while the body says $400,000 and $24,047.
Still, a codebase port cost of 6% of the money and a fraction of the calendar time is a gap nobody gets from a better prompt.
Was it the model, or the restart?
The README tells it as a model story. The repo’s own docs/history.md is messier, and I trust it more because it argues against the headline.
It says the first OpenAI goal run, June 22 to 26, produced a broad prototype and burned 207,170,354 tokens. A later audit found 70 failing tests and the compiler running 2.6 to 3.4 times slower than Go. A narrow second run fixed a five-file contract, and a third added checker work that “never demonstrated full tsgo parity.” Total across the three runs: about 216 million tokens, counted as uncached input plus output. The raw log says 8.34 billion, but 8.12 billion of that is cached context replay, and the author won’t call it a spend estimate.
The same file admits what the README doesn’t: the archived log labels 236 of the original implementation turns as an earlier model, and only a brief July 8 resume as gpt-5.6-sol. So “the OpenAI models failed at this” is not what the evidence says. What it says is that a pile of code grew for months without a trusted measure of done, and then somebody restarted.
I am taking a side: the restart did most of the work, and the model swap got the credit. I can’t prove that. The README does not say what Opus was handed on day one, and as far as I can find nobody ran Opus on the stalled tree or Astra on a clean start. One person, one run each.
Why a port nobody read could ship at all
One paragraph, because I wrote about the mechanism yesterday with the openTPU agent verifier. The port had an oracle: the upstream Go compiler’s own tests. The README says all 181,711 ported Go tests pass, and that TanStack Query core and Hono check with diagnostics identical to Go’s. That suite is the only reason “I’ve never read a line of this code” is survivable. The author even marks the boundary in the README with a line he calls the Slop Line: everything above it written by him, everything below by his LLMs.
Reading the benchmarks like a skeptic
The speed table comes from one machine: an Apple M4 Pro, 48 GB, hyperfine median of five runs, six open-source apps including VS Code and Sentry. Geometric mean: ts-rust is 11.4 times faster than tsc 6 and 1.61 times faster than tsc 7, the Go version. On T3 Code, an app from the same GitHub org, the full check takes 7.25 seconds against 16.10 for tsc 7 and 62.63 for tsc 6.
Now the part the README does not shout. In that same table, bun check has a geometric mean of 20.9 times against tsc 6, and the README says it is “the fastest on every app except tRPC.” The Rust port is not the fastest checker in its own benchmark. Its pitch on Effect projects is different: the Effect diagnostics are built in, so one pass takes 11.13 seconds where tsc 7 plus the Effect plugin takes 21.07.
On “100% compatibility”: the README says “It has 100% compatibility in every real world project we have tested,” and then a Known problems section lists TS6059 errors in some monorepos, stale-output reads in tsc -b, and editor memory growing about 20 MiB per 1,000 edits. It is pinned to one dev revision of TypeScript 7.1.0-dev from September 29. It runs on Linux x64 and macOS arm64 only. The install section says “I have no idea if this will actually work.” I would not call it production-ready, and neither does he.
What I would do at Trellis before porting a codebase
First, never hand an agent a port without an oracle. If the old code has no test suite you trust, your first task is that suite, written by a human. ts-rust had 181,711 tests. We have nothing like that, and I am not pretending we do.
Second, budget by attempts, not dollars. In my post on where an agent pipeline’s budget went the money disappeared into checking, and the codebase port cost behaves the same way. My rule, untested: if the pass count on the oracle does not move for a full day of agent time, stop, keep the tests and the written plan, and delete the code.
Third, keep the spec above the Slop Line. Whatever the human wrote down, the intended behaviour and the cases that matter, stays in a separate file the agents cannot edit. The code below it is disposable.
Try this if you have a small module, a real test suite and a language move with a business reason, like a slow parser. Skip it if your reason is “the agent said it could.” And if you only want a faster TypeScript check today, run bun check and wait for ts-rust’s second release.
Next week I want to measure the codebase port cost on one of our small parsers: run two attempts at a rewrite with the same test file and a token cap on each, and write down what each attempt costs when it stalls. I don’t know yet whether our tests are good enough to tell me. If both runs pass everything on the first day, I will suspect the tests before the agent.
