Quick Answer: The
ts-rust(ortsc-rs) project is an experimental, high-performance Rust TypeScript compiler ported almost entirely by LLMs. It achieves type-checking speeds up to 13x faster than traditional JS-basedtscby porting compiler algorithms to native Rust, while natively integrating Effect diagnostics.
We have all seen the hype around AI-generated code, but porting a massive, highly complex codebase like the TypeScript compiler is a different beast entirely. Enter ts-rust (also known as tsc-rs), an experimental Rust TypeScript compiler that was built using over $420,000 worth of LLM tokens. While the project started as a wild experiment to test the limits of frontier models, it has evolved into a shockingly fast type checker that challenges our assumptions about compiler development. Here is what actually happened behind the scenes.
The $420,000 Slop Line: How LLMs Built a Compiler
The origin story of ts-rust reads like a fever dream of modern software engineering. The project's creator, Theo of ping.gg, set out to answer a simple question: Could LLMs port the TypeScript compiler, checker, and language server protocol (LSP) to Rust?
The initial attempt was a financial black hole. Using OpenAI models (referred to in the project as GPT-5.6 Sol and GPT-6 Astra), the automated loops burned through more than $400,000 in API tokens. These models generated over 1.3 million lines of Rust code over several months, yet they could never push past roughly 84% compatibility with the upstream test suite.
Then came Claude Code and Anthropic's Opus. Starting completely from scratch rather than building on the previous models' work, the system generated a working "v0" prototype in just 10 hours. The total token spend for the successful port was approximately $24,047 over two weeks.
But the most fascinating part of this project is what the creator calls "The Slop Line." Everything below this line in the project's documentation was written entirely by the LLM. And this is where we see the classic failure mode of AI-generated documentation. The LLM confidently claimed that ts-rust is a direct port of "Microsoft's native TypeScript compiler, which is written in Go."
Any frontend engineer worth their salt knows that Microsoft's official TypeScript compiler is written in TypeScript, not Go. The LLM hallucinated this entire architectural history, likely confusing a community-led typescript-go port with Microsoft's official repository. Yet, despite this massive conceptual hallucination in the documentation, the generated Rust code actually works. It passes all 181,711 ported tests.
This brings us to a fascinating realization: an LLM can understand the abstract syntax tree (AST) and type-checking algorithms of a codebase well enough to port them to another language, while remaining completely clueless about the real-world context of the software it is porting.
Here's where it gets interesting...
Performance Benchmarks: Testing the Rust TypeScript Compiler
When we evaluate a Rust TypeScript compiler, performance is the only metric that truly matters. If it isn't significantly faster than standard tsc, there is no reason to accept the compatibility risks of an experimental port.
According to benchmarks run on an Apple M4 Pro (12 cores, 48 GB RAM), the performance gains are staggering. On massive codebases like VS Code (which contains roughly 3.75 million lines of code), standard tsc takes 54.56 seconds to complete a type check. The LLM-ported tsc-rs completes the same check in just 4.20 seconds—a 13x speedup.
Let's look at how tsc-rs stacks up against other modern tools like bun check across several open-source projects. When analyzing a tsc-rs performance benchmark, we must look at both speed and diagnostic accuracy.
| App | Lines Checked | Standard tsc (v6) | tsc-rs (Rust) | Bun Check |
|---|---|---|---|---|
| VS Code | 3.75M | 54.56s | 4.20s (13.0x) | 1.62s (33.7x) |
| Sentry (frontend) | 2.11M | 58.76s | 4.46s (13.2x) | 3.14s (18.7x) |
| Playwright | 585k | 4.48s | 0.34s (13.2x) | 0.18s (25.0x) |
| Excalidraw | 449k | 5.32s | 0.70s (7.6x) | 0.18s (29.0x) |
| TypeORM | 386k | 3.86s | 0.36s (10.7x) | 0.19s (20.0x) |
| tRPC (server) | 209k | 1.10s | 0.09s (12.0x) | 0.12s (9.1x) |
On average, tsc-rs is 1.61x faster than the Go-based compiler it was ported from, and 11.4x faster than standard JS-based tsc. However, bun check remains the speed king, averaging a 20.9x speedup over standard tsc.
That said, there's a real catch here. While bun check is faster, it achieved that speed by cutting corners. During the benchmarks, bun check reported errors on Sentry and tRPC that no other checker reported, indicating potential false positives or compatibility gaps. In contrast, tsc-rs matched the exact error output of typescript@next (TypeScript 7.1.0-dev) line-for-line.
Furthermore, these preview packages of tsc-rs were built in CI without Profile-Guided Optimization (PGO) or BOLT (Binary Optimization and Layout Tool). Once these compiler optimizations are applied, we can expect the Rust binary to run even faster.
This next part trips people up every time...
The Effect Engine: Why Built-In Diagnostics Matter
If bun check is faster than tsc-rs on almost every benchmark, why would anyone choose the Rust port? The answer lies in a specific architectural decision: native integration of Effect language service diagnostics.
For developers working within the Effect-TS ecosystem, type checking is notoriously slow. The standard workflow requires running the TypeScript compiler alongside a heavy JavaScript-based plugin like @effect/language-service to catch domain-specific errors. This dual-pass system destroys developer productivity.
Because tsc-rs has the Effect diagnostics engine built directly into the Rust binary (specifically porting the rules from Effect-TS/tsgo), it can run both standard TypeScript checks and Effect-specific diagnostics in a single pass.
Let's look at the T3 Code benchmark, which heavily utilizes Effect. When running a full type check with Effect diagnostics enabled:
tsc-rs(with built-in Effect diagnostics) takes 11.13 seconds.tsc 7combined with@effect/tsgotakes 21.07 seconds.bun checkfollowed by a separateeffect-tsgopass takes 37.60 seconds.
Because Bun lacks native support for these custom diagnostics, it forces you to run a second tool, which completely erases its raw speed advantage. By consolidating these checks into a single native Rust pass, tsc-rs cuts the total feedback loop time by more than half compared to the standard toolchain.
Most people stop here — don't. We need to look at the structural risks of relying on a codebase generated by an AI.
The Hidden Risks of LLM-Generated Compiler Code
The technical achievement of porting 1.3 million lines of code using Claude is undeniable. However, as senior engineers, we must ask: What are the long-term maintenance implications of maintaining an LLM generated codebase?
When a human team writes a compiler, they build a mental model of the architecture. They understand why certain edge cases in recursive type resolution are handled in specific ways. They know where the "dragons" live in the codebase.
With tsc-rs, the creator openly admits: "I've never read a line of this code."
This introduces a massive, unprecedented risk. If a developer encounters a subtle bug where the compiler silently passes invalid code—a common failure mode in complex type checkers—who fixes it? Debugging a compiler requires deep domain expertise. Debugging a compiler where every line of code was written by an LLM that no longer has context of its previous decisions is a nightmare scenario.
Furthermore, there is a massive architectural mismatch when porting Go to Rust. Go relies on a garbage collector to manage memory. In a compiler, AST nodes and type definitions are highly self-referential, forming complex cyclic graphs.
In Go, you can easily have pointers pointing back and forth because the GC handles cleanup. In Rust, doing this requires either heavy use of reference counting (Rc<RefCell<T>>), which destroys performance, or complex arena allocation. If the LLM resorted to reference counting to bypass Rust's strict borrow checker, it explains why tsc-rs is only 1.61x faster than the Go version, rather than the 5x-10x speedup we usually see when rewriting Go in optimized Rust.
TypeScript is not a static language. Microsoft releases major updates multiple times a year. When new syntax or type-checking behaviors are introduced in the TypeScript Official Repository, how does tsc-rs keep up?
The popular, lazy advice is to simply "run the LLM again on the new diffs." But this assumes that LLM token costs will remain linear and that the model won't introduce regressions. If it cost $24,000 to generate the initial port, keeping it updated with upstream changes could easily cost thousands of dollars per release, requiring constant human auditing to ensure compatibility doesn't slip.
This next part matters more than it looks...
When to Use tsc-rs vs Bun Check
Choosing the right tool for your CI/CD pipeline requires a careful trade-off analysis. There is no one-size-fits-all solution for how to speed up TypeScript type checking.
If your project is a standard React or Node.js application without complex meta-programming or custom compiler plugins, bun check is the obvious choice. It is incredibly fast, lightweight, and easy to integrate.
However, if you are building an enterprise-grade application using Effect-TS, or if you rely on exact compatibility with the latest TypeScript compiler diagnostics, tsc-rs becomes highly compelling.
Let's summarize the key differences in this comparison table:
| Feature / Metric | Standard tsc | bun check | tsc-rs |
|---|---|---|---|
| Type Checking Speed | Baseline (Slow) | Extremely Fast (~20x) | Very Fast (~11x) |
| Effect-TS Support | Via JS Plugin (Slow) | None (Requires 2nd pass) | Native (Built-in) |
| Error Accuracy | 100% (Reference) | High (Some false positives) | 99.9% (Matches upstream) |
| Production Ready | Yes | Yes | No (Experimental) |
While tsc-rs is still in its early experimental stages, it represents a massive shift in how we think about building developer tools. It proves that native-speed type checking is achievable without waiting years for a manual rewrite.
Frequently Asked Questions
What is the fastest Rust TypeScript compiler?
While projects like stc (by the creator of SWC) attempted to build a manual Rust TypeScript compiler, tsc-rs is currently the most complete experimental port, achieving up to 13x speedups over standard tsc. However, for raw speed without custom diagnostics, bun check remains faster.
How does tsc-rs compare to bun check?
In a standard bun check vs tsc comparison, Bun is faster because it skips certain complex diagnostic steps. However, tsc-rs provides 100% diagnostic parity with upstream TypeScript and includes native support for Effect-TS diagnostics, which Bun lacks.
Why does tsc-rs include Effect diagnostics?
The Effect language service diagnostics are built directly into tsc-rs to eliminate the need for a slow, secondary JavaScript-based compiler pass. This allows Effect-TS projects to run type checks and custom rule validations simultaneously at native speeds.
Is tsc-rs ready for production use?
No, tsc-rs is currently an experimental release. While it passes over 181,000 tests, the long-term maintenance of an LLM generated codebase presents risks, and it should only be used to speed up local development feedback loops.
Summary and Next Steps
If you want to speed up your local development loops, testing an experimental Rust TypeScript compiler like tsc-rs is a great way to experience native-speed diagnostics. Try running tsc-rs on your local development branch this week and note the result compared to your standard CI pipeline. For more insights on optimizing your frontend build tools, read our breakdown of modern bundler performance next.