tsc-rs is a Rust port of the TypeScript 7 compiler that Claude Opus 5.5 wrote in about two weeks, and its README says it passes all 181,711 tests ported from Microsoft’s Go compiler. Theo Browne of Ping Labs released it on October 7, 2026, along with the line that made it travel: he spent over $400,000 of API-priced tokens with OpenAI models and got nowhere, then roughly $24,047 of Claude and got a working compiler.
That cost ratio is the headline. I think the more useful story is why this particular task worked, because it tells you which of your own projects an agent can actually finish.
I have not run tsc-rs myself. Everything below comes from the ts-rust repository README, the npm registry, and the coverage and critiques published in the 48 hours since launch. Every benchmark here is author-reported.
What Is tsc-rs?
tsc-rs (the repo is called ts-rust) is an MIT-licensed Rust port of Microsoft’s Go-based TypeScript compiler, type checker and language server.
It is a port of a port. Microsoft announced its own Go rewrite of TypeScript in March 2025, and that native compiler became the default tsc in TypeScript 7.0, with full builds 8x to 12x faster than TypeScript 6 according to InfoQ’s coverage of the release. tsc-rs takes that Go code and translates it into Rust while keeping its algorithms, CLI, language server and API.
The practical details from the README:
- Install:
npm install -D tsc-rs, thennpx tsc-rs -p tsconfig.json - Version: 0.1.0 on npm, published October 7, 2026; the package itself was first created on October 3
- Upstream: pinned to microsoft/TypeScript commit
673a5f17d713from September 29, 2026, which is TypeScript 7.1.0-dev - Platforms: Linux x64 and macOS arm64 only; no Windows, no Linux arm64
- Extras: built-in Effect diagnostics (a port of Effect-TS/tsgo 0.46.1) and a WebAssembly build
The README also contains the sentence that most people quoted: the author has “never read a line of this code.”
tsc-rs is a working, drop-in-shaped TypeScript checker, but it is a 0.1.0 release that nobody has reviewed line by line.
The $420,000 vs $24,047 Story: GPT vs Claude Opus 5.5
Here is the build history as the README tells it. Browne first pointed OpenAI models, GPT-5.6 Sol and GPT-6 Astra, at the port. Those runs wrote over 1.3 million lines of Rust, cost more than $400,000 in API-priced tokens and never got past about 84% compatibility.
Claude Opus 5.5 then started from scratch. According to the README it had a working v0 in 10 hours, and the full run took about two weeks and $24,047 in API-equivalent spend, which the README puts at 925% to 983% of a $200 plan’s weekly limits.
Two caveats matter before anyone turns this into a model leaderboard.
First, these are not invoices. The DEV Community caveats write-up points out that Theo’s own chart is labelled “Token spend at API prices” and that the Opus work ran on Claude subscriptions. The dollar figures are usage equivalents and nobody outside Ping Labs has audited them.
Second, the Claude attempt came last. It started fresh, but it started with five months of lessons from the failed runs: which harness setups stalled, which parts of the compiler were hard, what a good test loop looked like. That is not nothing.
Even so, a roughly 17x gap in spend for a better result is too large to explain away with ordering. At Anthropic’s list price of $4 input and $20 output per million tokens, $24,047 is a lot of tokens for one project, and also far less than a single senior engineer-year.
The honest reading is that Claude Opus 5.5 finished a very large, well-specified translation job that GPT-5.6 Sol and GPT-6 Astra did not, for a fraction of the token bill, on one person’s unaudited numbers. If you want the wider benchmark picture between those model families, I compared them in Claude Opus 5.5 vs GPT-6 for coding.
tsc-rs Benchmarks vs TypeScript 7 and bun check
The README benchmarks six real open-source apps on an Apple M4 Pro with 48 GB of RAM, using hyperfine, the median of five runs after one warmup, with --noEmit --incremental false.
| App | Lines | tsc 6 | tsc 7 | tsc-rs |
|---|---|---|---|---|
| VS Code | 3.75M | 54.56 s | 6.84 s | 4.20 s |
| Sentry (frontend) | 2.11M | 58.76 s | 7.90 s | 4.46 s |
| Playwright | 585K | 4.48 s | 0.66 s | 0.34 s |
| Excalidraw | 449K | 5.32 s | 0.80 s | 0.70 s |
| TypeORM | 386K | 3.86 s | 0.55 s | 0.36 s |
| tRPC (server) | 209K | 1.10 s | 0.16 s | 0.09 s |
(Source: pingdotgg/ts-rust README, October 2026. Author-run, not independently reproduced. bun check is omitted from this table because it reported errors no other checker found on Sentry and tRPC.)
- bun check 20.9x
- tsc-rs 0.1.0 11.4x
- tsc 7 (Go) 7.1x
So tsc-rs is 1.61x faster than tsc 7 on this set, and bun check is 2.95x faster than tsc 7.
This is where I would slow down. bun check wins every row on speed, yet it reported three errors on Sentry and two on tRPC that no other checker reported. A type checker that disagrees with tsc is a different product, whatever its speed. tsc-rs’s pitch is that it is faster and gives the same answers, which is a harder and more useful claim.
The scariest-looking number, a 12.5x speedup, deserves a footnote too. It compares tsc-rs with Effect diagnostics built in (11.13 s) against TypeScript 6 with an older Effect plugin (138.63 s) that uses a different rule set. Against TypeScript 7 plus @effect/tsgo (21.07 s), the gain is 1.89x.
The like-for-like claim is a 1.6x to 2.2x speedup over the official Go compiler, which is real but much smaller than the 11x and 12.5x figures circulating on social media.
Why Agentic Coding Worked on a Compiler Port
This is the part I find most interesting, and it is not about which model is smartest.
A compiler port is close to the ideal job for an autonomous coding agent. The specification is executable: there is a reference implementation in Go you can diff against. The oracle is huge: 181,711 ported tests, plus real repositories whose diagnostics must match exactly. And the structure maps cleanly, function by function, from one language to another.
Compare that with the work most of us hand to agents. “Add billing to the dashboard” has no reference implementation, no test oracle until you write one, and a dozen judgment calls nobody wrote down. That is why the same models that port a compiler still ship vibe-coded apps that fall over in production. It is also why, in my long-running Claude Code vs Cursor vs GitHub Copilot comparison, the tool mattered less than how clearly the task was specified.
The lesson I take from tsc-rs is about task design. In my agentic coding guide I argued that you should delegate outcomes and review intent. tsc-rs shows the extreme version: when the outcome is “match this oracle exactly,” you can delegate almost everything, because the tests do the reviewing.
If you want an agent to finish something large, give it a reference to match and a test suite that fails loudly, before you give it a bigger model.
Known Problems and the Never-Read-the-Code Risk
The README is unusually candid about what breaks. The documented issues in 0.1.0 are:
- Monorepos: workspace files reachable through both
node_modulesand direct imports can produce extra output and TS6059 errors tsc -b: a project that imports another’s output without a project reference may read stale or missing output (TS2305/TS2307); adding the reference fixes it- Editor memory: memory grows about 20 MiB per 1,000 edits in long language-server sessions
- Version display:
tsc-rs --versionprints 7.1.0-dev rather than the npm version
The DEV Community review adds one more: the README pins the September 29 upstream revision, while the repo’s UPSTREAM.json manifest names a June revision as its default. That is probably bookkeeping, but it is the kind of mismatch you want resolved before trusting “identical diagnostics.”
The bigger issue is maintenance. A 1.3-million-line codebase that its author has never read can only be maintained by the agent that wrote it. When TypeScript 7.2 lands, someone has to re-port the changes, and that someone is Claude plus a test suite. Theo says four of the first five filed issues reproduced upstream TypeScript behaviour, per AICoder’s write-up, which is a good early sign but a small sample.
There is also a supply chain angle. tsc-rs is a native binary that runs on every file in your repo, and its first npm version appeared on October 3, 2026, with 0.1.0 following on October 7. If your package manager enforces a release-age delay, as I recommended in the post on AI coding agent supply chain attacks, a fresh version will be held back until it ages past your threshold. That is the setting working as intended. Review the release before you override it.
The risk in tsc-rs is less about today’s bugs and more about who can fix tomorrow’s, given that no human has read the code.
Should You Switch to tsc-rs?
For most teams the answer today is no, with one useful exception.
Stay on tsc 7 for your editor and your blocking CI check. It is Microsoft-maintained, it already gives you the 7x to 12x jump over TypeScript 6, and it runs on Windows.
Try tsc-rs as a shadow CI job if you run large TypeScript monorepos on Linux x64 runners. Run it next to tsc, make it non-blocking, and diff the diagnostics. If it matches for a month and saves real minutes per pipeline, you have data to decide with.
Use bun check only if you accept that it may report errors tsc does not.
The broader takeaway is for anyone budgeting agent work. A two-week, roughly $24,000 port of a production compiler is now a public, inspectable data point. It will be cited in every “should we let agents rewrite this service” meeting for the next year, so read the caveats before someone else quotes only the headline.
My bet is that Microsoft’s own team watches this closely. Whether tsc-rs becomes a maintained tool or a remarkable demo depends on the next three upstream releases, not on this one.
