tsrs Claims Up to 8x Faster TypeScript Checks. Here's How to Test It Beside tsc
A faster type check changes how often you can afford to run it. Here's what tsrs claims, what it still lacks, and a safe way to test it this week.
Type checking is the step every TypeScript developer waits on and nobody budgets for. A new Rust port of the TypeScript compiler, tsrs, claims to cut that wait by up to 8x.
On a big codebase it takes long enough that people stop running it locally and let CI catch the errors later. Coding agents make that worse. An agent that edits a file and then wants to know whether it broke anything has two bad choices: wait for the full check every time, or skip it and find out at the end.
So a type checker that is several times faster changes the shape of the work, which matters more than the number on the dashboard. Cloudflare and VoidZero announced tsrs on October 20. The claims are big, the project is young, and the smart move is to try it next to the compiler you already trust rather than in place of it.
What tsrs is
tsrs describes itself as "a drop-in replacement for the TypeScript 7 compiler and language server, written in Rust." In plain terms, it reads the same tsconfig.json, checks the same code and aims to report the same errors as Microsoft's compiler (the one you run as tsc), with a different engine underneath. "Aims" is doing real work in that sentence, as you'll see.
A little context helps. TypeScript 7 is the version where Microsoft moved its own compiler from JavaScript to Go, a project often called tsgo. tsrs ports that compiler to Rust. According to the Cloudflare announcement, the work comes from Cloudflare and VoidZero (the company behind the Vite and Oxc JavaScript tools) together with Max Schwenk of Owner.com, "in close collaboration with the TypeScript team." The post is clear that this is not a fork: the team says it will track upstream behavior and send performance work back to the Go code.
It lives inside the Oxc toolchain, ships under the Apache-2.0 license, and published v0.18.0 on October 19. Even the npm version number tells you what it tracks: 0.18.0-ts7.1.0-dev.20260929, a TypeScript 7.1 development build, not a stable release.
Why it might be faster
The Cloudflare post makes two performance claims. tsrs is "up to 8x faster and uses ~70% less memory compared to TypeScript 7.0 when using the same number of type check workers." And by default it uses an "adaptive configuration dependent on the machine type," which spends more memory to go faster still.
A type check worker is a thread that checks part of your project in parallel. Think of it as how many people you put on proofreading the same book. The "same number of workers" phrasing matters because it means the comparison is engine against engine, not a big machine against a small one.
The project's benchmark notes give one concrete example. On the vscode repository, averaged over 20 runs on a 64-thread machine, tsrs with 8 checkers finished in about 1.5 seconds using about 3.3 GB of memory. TypeScript 7.0.2 at its default settings took about 9.6 seconds and 7.5 GB, and the 7.1 nightly about 8 seconds. Note that those defaults are not the same worker count as tsrs's 8, so read that example as "what you get out of the box," not as the headline 8x. Bun's own bun check ran faster than both in the same table.
Two things keep this honest. These are the team's own benchmarks, measured on their machines with their scripts. And the competition is moving: the post itself says TypeScript 7.1 beta is "up to 2.5x faster than TypeScript 7.0," adding that "Some of these optimizations were upstreamed from tsrs."
What "faithful port" means right now
Speed is easy to measure. Matching TypeScript's behavior exactly is the hard part, because a type checker that is fast but disagrees with tsc on an error is worse than useless.
The project's compatibility notes are refreshingly specific. For plain type checking (--noEmit), tsrs matches the reference on 13,458 of 13,462 error baselines (saved expected outputs from TypeScript's own test suite), and the team attributes the four misses to its test runner. JavaScript and declaration file output, source maps, incremental builds and --build for project references (a way to split a big repo into linked sub-projects) are all supported, with --build passing 189 of 192 scenarios. The README adds: "In our testing on existing projects, we have yet to find a correctness bug in tsrs."
Then the gaps:
- No Windows package through 0.18.0, and no Intel macOS binary.
--init,--showConfigand--generateTraceare not supported, and--localeis ignored (English messages only).- The language server is partial. Editor support (
--lsp -stdio) passes 4,074 of 4,546 test groups, and features like automatic type acquisition (fetching type definitions for plain JavaScript packages) are not ported. - Output order can vary. The README warns that diagnostics can come out in a different order than the Go compiler, and that some races can still vary between runs.
- It targets TypeScript's main branch, not a stable release. The stated goal is a stable version "against TypeScript 7.1 with 100% conformance."
One more practical note: when v0.18.0 shipped, its README said issues and pull requests were both disabled. The README on the main branch now says "The issue tracker is open for bug reports" while "Pull requests remain closed because we don't have the bandwidth to review them." You can report problems. You cannot send fixes yet.
The agent angle, and what the post does not say
The Cloudflare post includes a line that will get quoted a lot: "frontier AI models can now do large-scale ports almost independently in a matter of days." It is worth reading carefully. The post makes that as a general point about ports. It does not say how much of tsrs an AI agent wrote, and the repo credits Max Schwenk for the port. Do not repeat "AI ported TypeScript in a week" based on this post.
Where agents do show up is in maintenance. The team plans to keep tsrs in sync with TypeScript using the process it built for Vinext, its Next.js port, where "Each morning, an agent reviews the changes, fetches diffs, and opens tracking issues." For a port that promises to follow upstream, that daily diff review is the real engineering story. A fast checker that drifts from TypeScript a little more each week would be a trap.
For anyone building with coding agents, the more useful angle is the loop. If a full type check drops from several seconds to around one on a large repo, an agent can afford to check after every edit instead of once at the end. That turns "the agent broke the types three files ago" into "the agent saw the error immediately and fixed it." Whether you get that benefit depends on your repo, so measure it.
Put this into practice
The safe way to try tsrs is to run it beside tsc, compare the results, and only then decide anything. Here is a setup that takes about ten minutes on macOS or Linux.
1. Install it as a dev dependency.
pnpm add -D tsrs
# or: npm install -D tsrs
The Cloudflare post shows npm install tsrs and npx tsrs; the README uses pnpm. Either works for a trial. Windows users will have to wait for a package.
2. Run both checkers on the same project and time them.
time npx tsc --noEmit
time npx tsrs --noEmit
--noEmit means "check types, write no files," which keeps the comparison fair and keeps tsrs away from your build output.
3. Compare the errors, not just the speed. Save both outputs and sort them, since tsrs may print diagnostics in a different order:
npx tsc --noEmit > tsc.txt 2>&1; sort tsc.txt > tsc.sorted
npx tsrs --noEmit > tsrs.txt 2>&1; sort tsrs.txt > tsrs.sorted
diff tsc.sorted tsrs.sorted && echo "same diagnostics"
If the diff is not empty, the README suggests running with --checkerAssignment go --noLazyMembers for the closest match to the Go compiler. Remember that tsrs follows TypeScript's main branch, so a difference against an older stable tsc can be a version difference rather than a bug. If you find a real mismatch, the issue tracker wants a minimal reproduction.
4. Add it to CI as a non-blocking job. Run tsrs in parallel with your existing type check, mark it as allowed to fail, and log its time. After a few weeks you will know whether it ever disagrees with tsc on your code, and how much time it would save.
5. For agent loops, give the agent the fast check and keep the slow one as the gate. In your agent's instructions or hooks, run npx tsrs --noEmit after each edit, and keep tsc as the final check before a commit or pull request. You get the quick feedback without trusting a 0.x tool with your merge.
What to expect: on a small project the difference may be too small to notice, since startup time dominates. The gains the team reports show up on large codebases. If your check already takes under a couple of seconds, tsrs is a curiosity for you, not a fix.
Honest limitations
The numbers are the project's own. The 8x and 70% figures come from the team's benchmarks with its chosen projects and settings. Your repo, your hardware and your tsconfig will give different results, which is why step 2 exists.
It is experimental by its own description. The Node API is marked unstable, the version number starts with zero, and the README frames this release as a way to gather feedback.
The language server is not ready to replace your editor setup. Faster checks mean little if hover info or autocomplete misbehaves in your editor.
Upstream is a moving target. TypeScript 7.1 is getting faster on its own, partly with tsrs's help. That is good for everyone, and it also means the reason to switch could shrink before tsrs reaches a stable release.
And Windows teams are out for now. If half your developers are on Windows, tsrs can only live in Linux CI for the moment.
Where this leaves you
A type checker fast enough to run on every save, and on every agent edit, is worth wanting. tsrs might get there. Today it is a promising second opinion with a well-documented list of what it cannot do yet.
So treat it like one. Install it, run it beside tsc on your largest project, diff the results, and give it a non-blocking CI job. If it agrees with tsc for a month and saves real minutes, you will have the evidence to make the switch when the stable release lands. If it does not, you lost ten minutes and learned something about your build.
Sources: Cloudflare, "Introducing tsrs: a Port of TypeScript to Rust" (Oct 20, 2026) · oxc-project/tsrs README · tsrs COMPATIBILITY.md · tsrs bench/README.md. Reviewed at v0.18.0 (released October 19, 2026).