PHP, TypeScript, vibe coded and public. One ran up over $420k in API-priced tokens. Here’s what I found poking at php-rust.
There’s a new genre of open-source project: take a whole programming language, rebuild it in Rust, and let AI agents write nearly all of it. The TypeScript compiler has one. PHP has one. More keep showing up. They’re public, they’re huge, and at least one of them is actually fast.
I spent a day reading about them and I still can’t work out what they’re for. So this is me thinking out loud.
How I got pulled in
It started with this post from @rustaceans_rs. I clicked. Then I kept clicking. TypeScript in Rust. PHP in Rust. Other “X, but Rust” projects. As far as I can tell, all vibe coded: the humans steer, the agents type. The ts-rust README says it with a straight face: “I’ve never read a line of this code.”
The receipts
ts-rust is Theo’s port of Microsoft’s native TypeScript compiler (the Go one) to Rust. From its README:
- 1. Over $400,000 in API-priced OpenAI tokens and 1.3 million lines of Rust, and it “never got past like 84% compat”.
- 2. Then Claude Opus 5.5 started from scratch, had a working v0 in 10 hours, and “got further than Astra in 1/10th the time”.
- 3. Claude’s bill: about $24,000 at API prices, over two weeks.
His verdict: “Expensive, for sure, but not that bad considering how much work has gone into typescript-go.”
php-rust didn’t publish a bill that I could find. The only clue I have is its commit history: 18 of the latest 20 commits are co-authored by Claude Fable 5.1. So, how much? No idea. I’d love to know, and I suspect the answer has more zeros than I’m comfortable with.
OK, but is it real?
I went in expecting a toy. php-rust isn’t one.
php-rust (site) rebuilds PHP 8.5 from scratch, about 155K lines of Rust (still in progress). The approach is clever: instead of copying how the real engine works inside, match real PHP’s output on PHP’s own official test files. Its COVERAGE.md (measured 16 September 2026) says these run with the same results as real PHP:
- WordPress’s full core test suite: 30,472 tests
- Composer and PHPUnit
- Doctrine
- Symfony http-kernel
It also has fibers, property hooks, lazy objects, Reflection good enough for frameworks, and a garbage collector. A lot of the scary parts are already there.
Side quest: I tried Laravel
Being a PHP person, I had to. I asked Claude to spin up a Laravel test against it.
Short version: it looks like it won’t even start. php-rust has 1 of PHP’s 64 openssl_* functions, and Laravel encrypts its session and XSRF-TOKEN cookies on the very first response. So the welcome page would die on openssl_encrypt() before anything else runs. (According to the author, Laravel is on the roadmap.)
To be clear, that’s what the code says will happen. Claude read the source and the coverage page; nobody built or ran anything.
I find that funny. Fibers, done. Garbage collector, done. The boring extension every framework assumes is there? Not yet.
And the “faster” part?
The two projects split here. ts-rust is genuinely fast: its README says type checking takes about half of Go’s time across 60 open-source projects. php-rust, by its own author’s benchmarks, is slower than real PHP right now: 2.4× to 4.6× the CPU time depending on the workload, and 1.77× on the full WordPress suite.
So “rewrite it in Rust” doesn’t automatically mean faster, at least not on day one.
So what’s the point?
For ts-rust, Theo actually wrote the goals down:
Test model capabilities
Make a fast TypeScript type checker
Make a ts checker that can work in WASM with high performance
Memes
I respect “Memes” being on the list. php-rust’s README doesn’t spell out a goal the same way, as far as I saw.
Maybe I’m being shallow, or I just don’t have the experience yet to see it, but apart from showing what AI can do, I’m not sure what the end goal is. Is anyone going to run production PHP on this?
If you know what these projects are actually for, tell me. I’m genuinely asking. Leave your thoughts on the comments.
Top comments (2)
The Laravel example is a useful reminder that language-level compatibility and ecosystem compatibility are different test targets. One nuance: a function-count metric can hide the exact blocker—Laravel's default encrypter depends on the OpenSSL extension/API and compatible cipher, key, IV, and tag behavior. A small framework-boot smoke test plus encrypt/decrypt vectors would make that gap concrete, even before broader Laravel support.
Matching real PHP's output on PHP's own test files instead of copying the engine internals is the clever bit, because the test suite becomes the spec and the agents have something hard to aim at. 30,472 WordPress core tests with the same results is a much stronger claim than it compiles. The open question for me is behaviour the official tests don't cover, since nobody has read the code to know. Does COVERAGE.md list any known differences outside the test files?