On 7 October a repository called ts-rust appeared on GitHub. It is a Rust port of the TypeScript compiler, pinned to a commit of Microsoft’s TypeScript repository, and it was written, in the author’s words, by LLMs. The README is the interesting part. Under its Warnings heading it makes the strongest claim, “It has 100% compatibility in every real world project we have tested,” and a few lines later the author adds, “I’ve never read a line of this code.”
The first is a claim a reader can test, and the second is a self-report that cannot be checked. Most of what follows is about the first.
Three dollar figures
The README gives three numbers for what the port cost. They are worth setting side by side.
The introduction says: “It cost over $420,000 in tokens to do it, but you could probably have done it for ~$20k (see below)”.
The history section says the author “did over $400,000 in API priced tokens with GPT-5.6 Sol and GPT 6 Astra,” and that those models “wrote over 1.3m lines of Rust over multiple months of /goal loops and never got past like 84% compat.”
Later, for a second phase on Claude, it says: “Total token spend was ~$24,047 of API spend over 2 weeks.” The author was using Claude accounts for that phase, and the spend “worked out to somewhere between 925% and 983% of my $200 plan weekly limits.”
Add the two stated phases and you get about $424,000. That fits the headline loosely, and “over” is doing most of the reconciling in both places. The reader cannot tell whether the headline counts only the first phase, both, or some other sum. Nor can the reader tell what the $20,000 estimate assumes. The README says only “(see below)”, and the nearest figure below is the $24,047 Claude phase, but it does not say that is the basis.
The units differ too. The first figure is priced tokens. The second is described as API spend but was run against a $200 plan, which the author converts into a percentage of a weekly limit. Both can be true, but they are not the same kind of number as a bill.
The lines belong to a version Opus did not build on
“They wrote over 1.3m lines of Rust.” The sentence is attached to the Codex phase, and the README is explicit about what happened next: “I assumed it kept using the code the Codex models wrote. I was wrong. Opus 5.5 started from scratch. It got further than Astra in 1/10th the time.”
So the line count and the $400,000 describe an attempt that the later phase did not build on. By the README’s account, Opus 5.5 started from scratch rather than building on the Codex code, and the roughly $24,000 phase is the one that produced the current work. The README does not say how much, if any, of the earlier code remains. On my reading, the headline cost includes the cost of the attempt that stalled at about 84%, and the README does not separate the two.
I cannot check the line count from the repository either. GitHub’s language statistics report about 31 MB of Rust, but they measure bytes rather than lines, so I have not treated them as a line count.
What “100%” is measured against
The compatibility claim rests on a short list of checks: “TanStack Query core and Hono check with diagnostics identical to Go’s. All 181,711 ported Go tests pass.” The oracle, in other words, is a Go implementation of the same compiler. The port is judged on whether its output matches that implementation.
Agreement with a reference is a real test, and for a compiler it is a strong one. It is also a narrow one. It cannot show that the output is correct TypeScript, and any behavior that the Go code gets wrong is a behaviour the port will reproduce faithfully. The count of 181,711 does not say whether those are test cases, assertions, or files. A test suite that a port passes says the port agrees with its oracle on that suite.
The claim, narrowed
The useful thing about the README is that its compatibility line appears in three places, and each one is more qualified than the last.
The first line is the one that gets quoted, and it is the one with no qualifier. The status section, lower down, reports a narrower measurement: 120 open-source repositories. It also allows two kinds of difference: the ones listed as known problems, and cases where “Go’s own output changes from run to run.” That second clause concedes the reference is not always stable. I read that measurement as the working scope of the 100% line. A reader should know that before trusting a port that matches it.
The known problems list shows the gap. It includes mismatches in how tsc-rs reports TS6059 and TS2305/TS2307 in monorepos and project references, and editor memory that starts 12 to 24% above tsc’s, though the README says it stays below tsc’s from about edit 20 in the sessions it measured. For TS6059, the README says tsc’s own result changes between runs. A port with listed differences from its oracle is not 100% compatible with that oracle in the plain sense, whatever the first line says.
The part that cannot be checked
The sentence I cannot check is the one the author wrote about their own role, “I’ve never read a line of this code.” It may be true. It is also the sentence that changes how much weight a reader should give to the rest. If nobody has read the code, the people who can vouch for it are the tests, and the tests agree with one implementation. The README is a record of a process, and the process is what the numbers are about.
This is the same problem I wrote about with the OpenAI mathematics release, where a machine check certified a statement and the statement still had to be right, in the statement is still on you. Here the statement is “the port matches the compiler,” and the checker is a second compiler written in Go. Agreement between two implementations is evidence. It is not the same as the thing the port says it is.
If I were evaluating the next port of a large compiler, I would ask three questions before the cost. What is the oracle, and is it the same program written again in another language? Which numbers were measured, and which were estimated or inherited from another phase? And which of the claims in the Warnings section survive the qualifiers in the Status and Known problems sections?
References
- pingdotgg (2026). ts-rust, README. GitHub repository, read 8 October 2026. Quoted passages: lines 5, 16 to 20, 33, 37, 39, 94 to 101, and the Known problems section from line 198.
- microsoft/TypeScript (2026). Commit 673a5f17d713. The revision the port pins to, as linked from the README.