ts-rust: An LLM-Written Rust Port of the TypeScript Compiler, Tested

A team under the pingdotgg GitHub organization has published ts-rust, a Rust port of the TypeScript compiler written almost entirely by large language models. Its first line says it plainly: "I wanted to see if LLMs could port the TypeScript compiler, checker and lsp to Rust. Turns out they can."

The repo appeared on October 7, 2026 and reached the front page of Hacker News the same week. This post covers what the README claims, how the port was built, the numbers, the criticism, and what the project says about AI-written large codebases. We read the repo README, the project's history file and the Hacker News thread.

What is ts-rust, in one table?

The README also draws a line it calls "The Slop Line." Everything above that heading was written by the author. Everything below it was written by the author's LLMs. That convention drew praise in the discussion, as we show below.

How was it built, and what did it cost?

The README tells a two-act story, and the repo's docs/history.md adds a third angle.

Act one: OpenAI models. The author used OpenAI models, named in the README as GPT-5.6 Sol and GPT 6 Astra. In total they spent "over $400,000 in API priced tokens" (the section headline says over $420,000). The models "wrote over 1.3m lines of Rust over multiple months of /goal loops and never got past like 84% compat."

Act two: Opus 5.5. The author then noticed how little of their Claude Code limits the work was burning and tried Opus 5.5. It "had a working v0 in 10 hours." The author assumed it reused the Codex code. It did not. In the README's words, "Opus 5.5 started from scratch. It got further than Astra in 1/10th the time." Total spend was "~$24,047 of API spend over 2 weeks," which the author says came to between 925 and 983 percent of their $200 plan's weekly limits. They add that a repeat could probably be done for about $20,000.

The history file. docs/history.md records earlier work in June and July 2026. It shows three Codex goal runs with about 216 million goal-accounted tokens in total. It says a first broad prototype had 70 failing tests and ran 2.6 to 3.4 times slower than Go, and that a later checker run "never demonstrated full tsgo parity." It also warns that the log labels most early turns as an earlier model, so the code is "the starting artifact" for the experiment and not proof that one named model wrote every line.

Read together, the numbers mean three things:

1. The money figures are API list prices. The author paid with subscriptions for part of it.
2. The cost gap between the two acts is about 17 to 1 (roughly $420,000 against $24,047) by the README's own headline numbers.
3. The README credits a model switch and a restart, not a better prompt. We cannot verify that claim from outside the repo.

What does the port actually do?

ts-rust is a direct port, not a redesign. The README says it "keeps Go's algorithms and behavior and has the same command line (tsc), language server and API." It runs in the same way as tsc, with the same options.

Some other features and facts from the README:

• Effect diagnostics are built in. The compiler includes the Effect language-service diagnostics (codes 377xxx), so an Effect project does not need a second compiler pass. The rules are a port of Effect-TS/tsgo 0.46.1. Editor features such as quick fixes and hover are not ported.
• Pinned upstream. To compare results, use typescript@7.1.0-dev.20260929.1, not 7.0.x. A difference that the upstream build also shows is upstream behavior.
• WASM crate. crates/ts_wasm is a WebAssembly build.
• Dev layout. crates/ts_goport is the compiler. Code generators produce the AST data and the diagnostics catalog. The repo includes porting rules, measurement scripts and an AGENTS.md with typechecker work rules.

What do the benchmarks claim?

The README is specific about method. Machine: Apple M4 Pro, 12 cores, 48 GB, macOS 26.5.1. Tool: hyperfine, median of five runs after one warm-up, --noEmit --incremental false.

On correctness, it reports:

• TanStack Query core and Hono check with diagnostics identical to Go's.
• All 181,711 ported Go tests pass.
• Language server and API answers match Go on the oracle test sets.
• On 120 open-source repos, command-line output differs from Go only in the known problems, and where Go's own output changes from run to run.

On speed, for six real apps:

Against tsc 7, tsc-rs is 1.61x faster by geometric mean. bun check is 2.95x faster and is quickest everywhere except tRPC. The README notes bun check reports a few errors no other checker reports (3 on Sentry and 2 on tRPC).

On the author's T3 Code benchmark, tsc-rs took 7.25 seconds without Effect diagnostics, against 16.10 for tsc 7 and 62.63 for tsc 6. With Effect diagnostics, tsc-rs took 11.13 seconds against 21.07 for tsc 7 with @effect/tsgo.

Treat all of this as vendor-style evidence. It is one machine, run by the author, and tsc-rs was a "measured build" with PGO and BOLT optimization, while the preview npm packages are built in CI without them and are slower. For context on how much speed LLM-driven rewrites can buy, see our coverage of OpenAI's Python-to-Rust Habitat rewrite and GitHub Copilot's Rust runtime migration.

What are the known problems?

The README lists them without softening. They are the best part of the document.

• Monorepo rootDir errors. In some monorepos, tsc-rs can emit output for more files than tsc does and report TS6059. It gives the same result every run, the result of TypeScript 6. tsc itself decides this by timing.
• tsc -b without references. When one project imports another project's output without a project reference, tsc-rs can read old or missing output (TS2305 or TS2307) in a few cases. Add the reference to fix it.
• Editor memory growth. Memory grows about 20 MiB per 1,000 edits. It starts 12 to 24 percent above tsc and, from about edit 20, stays below it in the measured sessions (up to 2,190 edits).
• Version string. tsc-rs --version prints the TypeScript version it ports (7.1.0-dev), not the npm version.
• Tweaks to the test apps. Four of the six apps needed config changes to check with zero errors under tsc 7 (for example, removing baseUrl in Excalidraw and changing moduleResolution in TypeORM).

What did Hacker News say?

The thread (item 50000676) had about 110 points and 207 comments when we read it. These are reports of what commenters wrote, not verified facts.

• The Slop Line. User fwlr wrote that they "really appreciate this convention," and thrance echoed the thanks. Several others focused on how the README separates human and machine text.
• A TypeScript team reply. DanRosenwasser, who identified as a TypeScript team member, wrote that the work is impressive and "it's honestly crazy that 3 of these ports have popped up in the last week." He said the team would have more to say soon.
• Cost shock. ingen0s and Thaxll both reacted to the $400,000 figure. mkesper asked how many kWh that burned. benrutter noted you could hire a human for that money and found it odd that fewer people would pay a human than would spend it on an LLM.
• Maintainability. anonymous908213 argued that models fix compile errors in a loop against a huge test suite, leaving "a codebase no one has read." They compared it to a Bun rewrite that, they said, needed three months of human work to fix issues. yoyohello13 asked what the project teaches and whether anyone would use a less maintained implementation. bitpush replied from the other side: it will probably not be maintained, but it shows what is possible, like porting Doom to a microwave.
• Hidden test gaps. pvillano wondered whether LLM ports checked against years of human tests will have holes where the original authors thought tests were unnecessary.
• Unsafe and idiom. elcritch asked how much unsafe the port uses and whether it is idiomatic Rust. gavinray reported that performance is limited because the port reimplements Go-style strings and part of the Go standard library to keep Go semantics. (The README says the port keeps Go's algorithms.)
• Perspective on Go. pmkary argued the result shows Go is fine, since Rust gave only a modest gain. hannibalhorn pointed out the real-world gains over tsc 7 were one to three seconds in absolute terms.
• Better tooling? spankalee suggested deterministic translators for 90 percent of the job, with agents only handling decisions.

You will notice that "slop" appears mostly as the author's own word. The harshest criticism in the thread is about ownership: who maintains code no person has read.

What does ts-rust mean for AI-written large codebases?

Four lessons come out of the repo and the thread.

1. A giant test suite is the real enabler. The port exists because Go's tests could be ported too, and 181,711 of them pass. The model loop was: write code, run oracle tests, fix. The same pattern appears in our guides on goal mode for AI agents and in agent harness engineering on Terminal-Bench. Where no test oracle exists, expect this approach to work much less well.

2. Model and harness choice dominated cost. The README's headline is not "LLMs can port a compiler." It is that one model needed over $400,000 and months and stalled at about 84 percent, and another model, starting over, finished in two weeks for about $24,000. If the claim holds, the lesson for teams is to re-run big agentic jobs across models before you commit budget. See our look at Opus 5.5 task cost in Claude Code and the reaction to GPT-6 Sol Codex usage limits.

3. Review debt is the new cost. The author says no human read the code. The repo adds accountability documents, state files and rules, which is a sign the team knows. Policy is also tightening elsewhere: see System76's COSMIC ban on AI-generated code.

4. Speed gains are real but modest against the Go baseline. A 1.61x speedup over tsc 7 is useful, but the Go compiler is already a native rewrite of an older JavaScript one. Most of the 7x gain over tsc 6 came from the Go port, not from this one.

How can you try it safely?

1. Install it as a dev dependency: npm install -D tsc-rs.
2. Run npx tsc-rs -p tsconfig.json --noEmit next to your normal tsc step in CI.
3. Diff the diagnostics. Any difference is a bug in one of them or a known problem above.
4. Keep your normal checker as the gate. Use tsc-rs as a second opinion until the diffs are empty for weeks.
5. If you use Effect, add the language-service plugin to your tsconfig as the README shows.
6. Skip the editor server for important work until the memory behavior is clearer.

A note on commands: the README uses npm. If your project uses Bun, replace it with the equivalent bun add -d tsc-rs. We have not tested that path.

Bottom line

ts-rust is not a replacement for the TypeScript compiler. It is a proof point with a price tag: an LLM-written port of a very large Go codebase can match a huge test suite, run faster, and ship in weeks. It also shows what the ledger looks like when it works: hundreds of thousands of dollars of tokens on a failed route, tens of thousands on the successful one, and no human reader at the end. Use it as a second checker, read its known problems, and copy the Slop Line.

Related reading

• OpenAI Habitat: Python to Rust rewrite by two engineers
• GitHub Copilot runtime Rust migration
• NVIDIA CUDA Rust GPU kernels
• Goal mode for AI agents
• Opus 5.5 task cost in Claude Code
• COSMIC bans AI-generated code
• What is an agent harness?

Sources

• pingdotgg/ts-rust README and docs/history.md
• Hacker News thread: Port of the TypeScript compiler, checker and lsp to Rust, by LLM

Numbers and claims are from the README and the Hacker News thread as read on October 9, 2026. The benchmarks are the author's and have not been reproduced by explainx.ai. The project is early, so check the repo before you depend on it.