tsrs: The Rust Port That Made TypeScript 8x Faster and Got Microsoft to Ship It

Last Updated: 21 October 2026

On 30 September 2026, Max Schwenk, an engineer at Owner.com, asked a coding model whether it could one-shot a port of the TypeScript compiler to Rust. He wrote zero code himself. Twenty days later, Cloudflare announced that it had taken the resulting project, tsrs, into the Oxc toolchain, with benchmarks showing it up to 8x faster than TypeScript 7.0 and using about 70% less memory at the same worker count. The repository's own numbers go further: 11.81x faster on the MUI docs project with four checkers each, and 16.87x at its default settings. In the same week, Microsoft's TypeScript team shipped optimisation work that came out of the port into TypeScript 7.1 beta.

This is the first credible case of an agent-written rewrite of a large production compiler landing in the mainstream toolchain. It says less about Rust than about what a well-instrumented agent loop can do when the target has an executable oracle: a test suite that can tell the agent, precisely and repeatedly, whether it is right.

What is tsrs?

The project began with a memory problem, not a language preference. Owner's backend monolith, Olympus, is about 37,000 TypeScript files typechecked as one Program. On TypeScript 7.0, a single-threaded check needed 19 GiB of memory and 80 seconds of wall time. Running tsgolint alongside it doubled the memory, and adding language and dev servers pushed a basic validation task past 50 GiB. On a 36 GiB laptop, engineers could not run several coding agents in parallel without risking a lockup, and cloud sandboxes meant reserving for peak memory before anyone knew the scope of the work.

Schwenk's approach was deliberately narrow. The ask was a faithful port of TypeScript Go to Rust, scoped to the smallest thing Owner needed: a typechecker that was correct, fast and lighter than Go. No JavaScript emit on day one, no language server on day one. One Rust crate per Go package, with function signatures and contracts written first and implementations mocked out, so that agents could fill them in independently. At peak, more than 20 subagents worked in parallel. The gate was TypeScript's own conformance suite, 15,197 cases, which gave every agent a yes or no answer.

Within three weeks the effort had company. Theo Browne's tsc-rs went public in early October, a separate agent-written port that included the language server. Cloudflare and VoidZero announced on 20 October that they were taking stewardship of tsrs as part of Oxc, and that they are working with Browne to merge tsc-rs and tsrs into a single package covering all of TypeScript's features, including LSP and content mappers. Cloudflare is explicit that this is not a fork and that the TypeScript team should remain in charge of the language: a Rust port that stops following upstream decisions will eventually become incompatible.

How much faster is tsrs, really?

The equal-checker comparison is the one to trust for a language-level claim, because both compilers do the same amount of parallel work. Cloudflare says it worked with the TypeScript team to make sure its benchmarks used the same configuration, after a wave of port benchmarks that used larger machines and non-default options.

The larger headline numbers come from a different mechanism. TypeScript's Go compiler defaults to four checker threads. tsrs defaults to every core up to 16, then half the cores, capped at 32 checkers. On the same 16 vCPU runner, with no thread flags, tsrs typechecks MUI docs in 0.75 seconds against 12.66 seconds for tsgo, which is 16.87x. That is not a fair language comparison, but it is a fair description of what a developer experiences after installing the package.

Memory is the reason the default works. Because each tsrs checker needs a fraction of the memory of its Go equivalent, 16 of them fit in RAM where 4 Go checkers would have been the practical ceiling. The speedup is a compound of two effects: less work per checker, and more checkers running at once because the machine can hold them.

Why Rust, when TypeScript 7.0 is already a Go rewrite?

Cloudflare's post is unusually direct about the WebAssembly point. Compile a Go program to Wasm and you compile Go's garbage collector with it, which adds size and complicates the boundary between guest and host memory. Rust's ownership model lets the guest and host share memory in a straightforward way, which is why Rust plus Wasm has been a strong pairing for a decade. Cloudflare recently added native Rust support in Workers through an Emscripten target for wasm-bindgen, and the company's stated goal is to run entire build and deployment systems in a sandbox, in a browser, or on an embedded device.

There is also an agent angle. Cloudflare says a small memory footprint makes it possible to run a complete development toolchain end to end in a fully sandboxed environment, including on Workers. For teams that want coding agents to validate their own work without giving them a laptop or a large cloud VM, a compiler that fits in a small memory budget is the enabling piece.

But Rust is not the whole story, and Cloudflare does not claim it is. The Oxc team is refactoring the codebase for speed and memory, and some of the wins are algorithmic: allocation strategy, struct layout, arena management. Those wins travel. They are already travelling upstream.

What Microsoft is shipping from the port in TypeScript 7.1

"Some speed & memory improvements you'll see with TypeScript 7.1 Beta. We're hoping to land more before RC & stable."

Daniel Rosenwasser, Principal Product Manager for TypeScript, 20 October 2026

This is the part of the story that most coverage misses. The interesting outcome is not that a Rust compiler beat a Go compiler. It is that Microsoft's compiler got faster because of work done in a Rust port. Cloudflare says it will continue to contribute performance improvements back to the TypeScript Go codebase, and that the TypeScript team is experimenting with memory and performance changes for tsc. The published iteration plan for 7.1 targets an RC in mid November and a stable release in late November 2026.

For a team deciding what to do this quarter, that matters more than the port itself. TypeScript 7.1 beta is a supported Microsoft release with a clear path to stable. tsrs is an experimental package with known parity gaps. If your goal is a faster CI typecheck, 7.1 is the low-risk move, and it captures a meaningful share of the same gains.

Can you trust a compiler written by agents?

Differential testing is the right tool here, and it is why this particular port is credible. A compiler has an oracle: give both implementations the same input and compare the diagnostics, the emit, the symbols and the language server responses. That turns "did the agent get it right" into a mechanical question with a pass or fail answer, which is exactly the kind of question an agent can iterate against thousands of times without a human in the loop.

The harness is layered. TypeScript's conformance suite covers the language. A nightly mutation job feeds 200,000 corrupted parser inputs to catch crashes and hangs that fixed tests miss. Miri checks the unsafe Rust in the arena allocator for undefined behaviour, and the job fails if a deliberately broken test slips through, so a silent Miri failure cannot hide. Owner also ran tsrs in shadow mode against real production traffic, comparing its diagnostics with the incumbent compiler's before trusting it. The repository's compatibility document is refreshingly honest about what is not done: diagnostic ordering can differ from upstream, --init and --showConfig are unsupported, content mappers work on the CLI but not in the language server, and a handful of build-mode CLI scenarios fail because the commands were never ported.

Keeping a port alive is the harder problem, and it is where Cloudflare's maintenance model matters. The company already runs this loop for Vinext, its Next.js reimplementation. Each morning an agent reviews upstream changes, fetches diffs and opens tracking issues for anything that could affect the port. Every night the compatibility matrix is regenerated by running the upstream test suite against the port. When a gap appears, agents can locate the change in both codebases, build a reproduction, port the relevant tests and propose a fix. The same loop now applies to TypeScript, with performance fixes flowing back to Microsoft.

What the skeptics get right

The benchmark framing deserves scrutiny. A port that runs 16 checkers against 4 will look dramatically faster even if each checker is only modestly quicker, and benchmark posts in this space have used larger machine types and non-default options. Cloudflare's response was to publish an equal-worker comparison alongside the default-settings table, which is the right disclosure. Read the equal-worker row first, then treat the default row as a user-experience number.

Parity is also version-sensitive. In the repository's own results, tsgo and tsrs report identical errors on 9 of 17 projects. The other 8 differ, but only because TypeScript changed between 7.0.2 and the 7.1 development commit that tsrs tracks: building [email protected] from that commit reproduces tsrs's diagnostics exactly. That is a good sign for the port's fidelity, and a warning for anyone comparing it against a different TypeScript version and concluding it is broken.

Finally, "written entirely by agents" does not mean unreviewed. Schwenk wrote no code, but he designed the port's structure, set the conformance gate, ran shadow mode and decided what landed. The agents supplied volume and iteration speed. The human supplied the definition of correct, which is the part that is hardest to automate and the part that made the project work.

What this means for teams running agents

The Owner story is a memory story before it is a speed story. The reason engineers could not run several agents was that each typecheck consumed 19 GiB and the linter brought another 28 GiB. After the port, typecheck is seven seconds in CI and about twelve on a laptop, and type-aware lint runs on tsrslint at 37.3 seconds against 169.4, peaking at 11.5 GiB against 45.0. Multiple agents can now check their own worktrees on a 36 GiB machine. Owner projects savings in the hundreds of thousands of dollars a year from lower sandbox and CI reservations.

We see the same shape in our own work. On two DGX Spark boxes, each with 128 GB of unified memory, our main model serves about 35 tokens per second on a single stream and 62 tokens per second at four concurrent streams. Throughput scales until each worker's working set stops fitting, and then it falls off a cliff rather than degrading gently. Agent fleets behave the same way: the constraint is memory per worker times workers, not the headline speed of any single run. A tool that halves memory per worker doubles the fleet you can run on the hardware you already own.

If you want to apply the pattern, the checklist is short:

• Choose a component with an executable oracle. Compilers, parsers, pricing engines, tax calculators and rules engines all qualify, because you can diff outputs at scale.
• Measure before you port. Record wall time, peak memory and the exact diagnostic output on a pinned commit, so every agent iteration is comparable.
• Build the differential harness first. Conformance suites, mutation testing and shadow mode are cheaper than a bad rewrite, and they are what makes agent output reviewable.
• Keep a human on the merge button. Agents can propose thousands of changes a day, but someone has to own the definition of correct.

For Australian teams, the portability angle is worth noting. A compiler that runs in WebAssembly with a small memory footprint can run in your own environment, including on-premises hardware, which matters when source code cannot leave the country. The same property makes it feasible to give each agent a sandbox that is small enough to afford and large enough to finish the job.

Should your team switch to tsrs now?

The decision splits cleanly by use case. For production builds and editor tooling, stay on Microsoft's releases. For a CI experiment on a branch, tsrs is a low-cost test: install the package, run npx tsrs --noEmit against your real repository, and compare the diagnostics and the wall time with your current setup. If the output matches and the time drops, you have a business case to watch the project closely. If it does not, you have learned something about your codebase's reliance on diagnostic ordering.

Three signals are worth watching before any production adoption. First, the 1,000-repository conformance run needs to come back clean, not just the synthetic suite. Second, the project needs a stable release against TypeScript 7.1 with a published support policy. Third, language server parity needs to close the remaining gap from 4,074 of 4,546 fourslash groups, because editor behaviour is where subtle divergence hurts most.

The strategic lesson does not wait for those signals. A large, well-tested codebase with a clear oracle is now a candidate for agent-assisted reimplementation, and the cost is measured in tokens and review time rather than engineer-years. The teams that build the harness first will be the ones who can trust the result.

If you are weighing an agent-assisted rewrite inside your own stack, talk to Flowtivity about scoping the oracle before you scope the port.

Frequently asked questions

What is tsrs?

tsrs is an experimental Rust port of the TypeScript 7 compiler and language server, hosted in the Oxc project and run by Cloudflare and VoidZero with Owner.com's Max Schwenk. It is a drop-in replacement for tsc and the TypeScript language server, tracks the main branch of microsoft/TypeScript, and aims for 100% conformance with much lower memory use.

Is tsrs a fork of TypeScript?

No. Cloudflare states that tsrs is not a fork and that Microsoft's TypeScript team remains in control of the language and its design direction. tsrs follows the upstream implementation closely and targets a stable release against TypeScript 7.1.

How much faster is tsrs than TypeScript 7.0?

At the same four checker threads, tsrs typechecks the MUI docs project in 1.07 seconds against 12.69 seconds for TypeScript 7.0.2, which is 11.81x faster, with peak memory down from 7.61 GiB to 1.05 GiB. At its default 16 checkers against tsgo's default 4, the same project reaches 16.87x. Cloudflare's headline figure is up to 8x at equal worker counts.

Can I use tsrs in production today?

No. tsrs is explicitly experimental and the compatibility report still lists parity gaps, including diagnostic ordering differences and unsupported CLI commands such as --init and --showConfig. Use TypeScript 7.1 beta for production speed gains, and trial tsrs on a branch or in a sandbox.

Why did Cloudflare choose Rust over Go for the port?

Cloudflare's stated reasons are memory and portability. Rust's memory model avoids shipping a garbage collector into WebAssembly, so the compiler can run inside Cloudflare Workers, in a browser, or on small devices. Lower memory per checker also means more checkers fit in the same RAM, which is where the extra parallel speed comes from.

Is TypeScript 7.1 faster because of tsrs?

Partly. Cloudflare says TypeScript 7.1 beta is up to 2.5x faster than 7.0 and that some of those optimisations were upstreamed from tsrs. Microsoft's Daniel Rosenwasser confirmed on 20 October 2026 that 7.1 beta includes speed and memory improvements, with more planned before RC and stable.

Sources

• Cloudflare, "Introducing tsrs: A port of TypeScript to Rust", 20 October 2026
• Owner.com, "tsrs", 19 October 2026
• oxc-project/tsrs on GitHub, including docs/COMPATIBILITY.md and bench/RESULTS.md
• Daniel Rosenwasser on X, 20 October 2026
• TypeScript 7.1 iteration plan, microsoft/TypeScript issue 63703
• pingdotgg/ts-rust (tsc-rs) on GitHub