Two Thousand Agents Rewrote Themselves in Two Weeks: How Prime Agent Moved TypeScript into Rust

An army of two thousand, and not one of them is human

Prime Agent, the coding agent that only launched in August 2026, racked up more than 300,000 downloads and processed over 8 trillion tokens in two months. On October 9, its developer Prime Intellect announced something more eye-catching: the tool had been rewritten by itself. The move from TypeScript to Rust took two weeks, and the ones doing the work were more than two thousand autonomous agents.

This is not the marketing line about "AI helping you write code." Throughout the port, the human team mostly did one thing: build the acceptance criteria so the agents could measure for themselves whether they had done the job right. The remaining orchestration, coding, review, and verification were handed to the machines.

Cost and scale: moving 200 billion tokens

According to the official blog, the rewrite scheduled more than 2,000 agents working in parallel across more than 10,000 Prime sandboxes, consuming over 200 billion tokens from the GLM-5.3 endpoint on Prime Inference. The stage that actually wrote Rust was completed by 1,981 agents, using roughly 192.99 billion tokens; the three-day performance ramp that followed brought in another 228 agents and about 35.7 billion tokens.

Those numbers are themselves a signal. The open model GLM-5.3 acting as the main inference engine for a production-grade agent swarm is not the same thing as "some model scored one point higher on a benchmark." It shows that in engineering settings that are long-running, high-volume, and dependent on stable tool calls, open-weight models are now cost-effective enough for real projects.

Orchestration: the root agent writes no product code

The part most worth copying is not "it used two thousand agents" but how they divided the work. The whole rewrite was directed by a single root agent, which itself wrote not one line of product code. It did only three things: break tasks into a graph with a topological order, track the progress of each task, and merge completed work.

Each task passes through four roles in sequence:

• Planner: writes the specification, the feature design, and the "golden answer," which is taken directly from the existing behavior of the TypeScript version.
• Implementer: writes Rust code in a separate worktree so different features can move forward in parallel.
• Reviewer: switches to a different model and a different context to adversarially hunt for flaws in the change.
• Verifier: compiles the code and runs consistency tests in a fresh sandbox.

If either review or verification fails, the task goes back to the implementer with the findings. Only when both pass is the change allowed to merge. Prime Intellect deliberately separated "generation" from "evaluation," for a blunt reason: let the agent that wrote the code judge its own output, and it will naturally favor itself.

The real guardrails: four kinds of consistency checks

A process alone is not enough; you also need objective standards of right and wrong. The team built four kinds of parity checks, each covering a different side of the same feature:

• TUI differential testing: run the TypeScript and Rust binaries under the same scripted model, comparing the terminal frame by frame, covering startup, menus, tool calls, session resumption, subagents, and crash recovery.
• Harness consistency: compare the session transcripts produced on each side, and the requests each sends to the model provider.
• Protocol consistency: check every message type of the daemon protocol against the TypeScript implementation.
• Feature audit: where scripts cannot reach, agents check component by component and mark each as "consistent," "partially consistent," or "missing."

With these objective rulers in place, agents can judge progress themselves and stop regressions before merging, which lowers the need for human review. The team is candid too: the bugs that slipped through were the ones no test covered, and they only surfaced after daily internal use.

Results: 14x cold start, 80 percent less memory

In the official comparison numbers, the delay from cold start to accepting input dropped from 737.8 milliseconds in the TypeScript version to 55.8 milliseconds, a 14.18x speedup; warm start sped up 13.34x; memory use across the whole process tree fell from 607.4 MB to 106 MB, roughly an 80 percent savings; and the install size shrank from 172.1 MB to 59.6 MB. First visible output landed at 23.6 milliseconds. The ramp stage logged 144 experiments in total and merged 69 valid changes. One caveat: this side-by-side comparison uses the team's own runtime suite, and the team itself notes the lack of a common benchmark, so the numbers should be read with care.

The structural change may outlast the speed. The code was split into nine crates, with dependencies pointing one way and enforced by Cargo; the largest source file shrank from about 15,000 lines to about 2,500, and no file exceeds 5,000 lines anymore. Each session runs in its own worker process, so one crash does not affect the rest. Windows support landed as a side effect of the cleaner platform abstraction, and the model catalog moved to runtime fetching, so new models no longer depend on a release.

Why Rust

The pain points the team listed for TypeScript are concrete: types are optional and vanish at runtime; errors propagate as unchecked exceptions; CPU-heavy work like rendering and parsing large sessions competes with keyboard input for the same event loop; and every process has to carry a JavaScript runtime and garbage collection. For a daemon that stays resident and runs one worker process per session, native code with no GC is the main source of better memory use and startup time.

And when the code is mostly written by agents, the value of "compile-time guarantees" is amplified. Exhaustive enums, ownership and lifetimes, plus Clippy's strict lints, can eliminate a whole class of bugs before the code ever runs. Put another way, the compiler takes over part of the judgment that would otherwise fall to a human reviewer.

What this means for different people

If you lead an engineering team, what you can reuse is not the number "two thousand agents" but the method: first turn acceptance criteria into objective, automatically executable checks, then split generation and evaluation across different models and contexts, and finally let agents push forward on their own inside the guardrails. Primer Intellect is already productizing this four-role pattern into a reusable workflow, on the reasoning that a "well-defined swarm factory" is more reliable than assembling one ad hoc for each project.

If you are just an ordinary user, it explains one thing: tools like Prime Agent will increasingly update in a way that looks less and less like traditional software. When a product can rewrite itself, the meaning of a version number changes. It is also a reminder that when you see conclusions like "refactor gave a 14x speedup," flip to the footnote first and see who measured it and what they compared it to. Agents can write usable code, but they can also write confident self-praise.