The rewrite story is really a verifier story.
Prime Intellect reports that Prime Agent coordinated more than 2,000 agents over two weeks to replace its TypeScript product with Rust. The company says the work used more than 10,000 sandboxes and 200 billion tokens. Those are first-party project numbers. They describe scale, not correctness.[1]
The stronger part of the report names four kinds of parity. Scripted terminal sessions compared rendered frames. Harness checks compared transcripts and model-provider requests. Protocol checks covered daemon messages. A component audit marked product features as matching, partial, or missing. Generator, reviewer, and verifier ran in separate agent contexts.[1]
The proof did not come from the number of agents. It came from making disagreements cheap to detect.
Preserve behavior before tuning speed.
A rewrite can get faster by dropping work. That makes performance claims dangerous until parity checks pass. Prime Intellect says its benchmark loop built the baseline and candidate in the same sandbox, alternated their order, checked nearby benchmarks, and required two model reviewers. The company also withheld unstable comparisons.[1]
The published cold-start, memory, and installed-size results come from Prime Intellect's custom harness. The post warns that cross-product comparisons lack a common standard. Read the numbers as vendor measurements under a disclosed setup. Do not treat them as an independent ranking.
The repository carries part of the claim.
The public repository at revision e6ebebebf751bdbdf78935b34a7053977fe863de contains a Rust workspace with nine named crates. The manifest forbids unsafe code across the workspace, enables pedantic linting, and documents release-profile choices. Release v0.10.0 has source, platform archives, SHA-256 sums, manifests, and separate Linux debug files.[2]
That inventory proves that a reviewable Rust release exists. It does not prove feature parity, runtime stability, or the published speed ratios. This dispatch cloned the repository and read its manifest and release metadata. It did not run the installer, launch the agent, connect an account, or replay the company's tests.
Port the tests before the implementation.
Start with observable contracts. Save terminal frames for key flows. Record protocol messages. Capture model requests. List every user-facing feature. Add crash recovery, resume behavior, and cancellation. Give each contract a baseline fixture and a failure report that an implementer can act on.
Then split authorship from judgment. A reviewer should not inherit the implementer's explanations as ground truth. A verifier should run the check in a fresh environment. Human review should focus on missing contracts, changed product intent, security boundaries, and failures the harness cannot express.
Prime Agent's earlier technical report describes a harness built around persistent execution, recovery, verification, and resource accounting. It also attributes benchmark gains to the whole system, not one isolated model call. That matters when a rewrite changes the harness itself.[3]
Keep cost and coverage on the receipt.
The rewrite post gives a total token count but not the input, cache-read, cache-miss, and output split. The Hacker News discussion called out that missing breakdown. The same gap appears in many agent-built migration reports. Total tokens say little about cash cost or reproducibility without provider prices and cache behavior.[4]
Record the model, provider, token classes, retries, sandboxes, elapsed time, human review time, and failed branches. Record test coverage by behavior, not only line coverage. A rewrite can be fast, cheap, or faithful. The receipt should show which claim each number supports.