Prime Agent's 2,000-agent swarm rewrote its own harness in Rust: 14.18× faster startup, gated by four differential parity checks

On October 9, Prime Intellect shipped a from-scratch Rust rewrite of Prime Agent, its open-source coding-agent harness. The company says the port was executed end to end by a swarm of more than 2,000 Prime Agent instances over two weeks. The part worth studying is not the swarm count, which is unverifiable, but the verification design that made the autonomy safe enough to try.

What shipped

Prime Agent is Prime Intellect's open-source, long-running coding-agent harness, launched in August 2026. The company says it has since been downloaded more than 300,000 times and processed over 8 trillion tokens. The Rust rewrite (repo, MIT license) was merged as PR 2524 on September 30 with 520 commits and released on October 9.

The company's benchmark table (TypeScript → Rust, after the optimization loop) reports:

• Cold start to input-ready: 736.1 ms → 51.9 ms, 14.18× faster
• Warm start: 552.3 ms → 41.4 ms, 13.34× faster
• Large-session memory (10 MiB session, process-tree RSS): 1,130.0 MB → 237.3 MB, 4.76× smaller
• Installed size: 172.1 MB → 59.6 MB, 2.89× smaller
• Agents-view switch: 78.0 ms → 12.8 ms, 6.09× faster

A second table compares against other harnesses, measured on a fresh 4-core, 8 GB sandbox with a scripted model and timings that exclude inference. First paint: 23.6 ms vs Claude Code v2.1.289 at 264.6 ms, Codex CLI v0.160.0 at 296.8 ms, Pi v1.0.3 at 306.3 ms, and Hermes Agent v0.21.5 at 1,715.3 ms. Post-startup memory: 106.0 MB vs Claude Code's 226.9 MB and Codex CLI's 344.4 MB. The company cautions that without a common benchmark standard, cross-harness comparisons are hard to interpret.

The codebase went from TypeScript to nine Rust crates with a one-way dependency graph that Cargo enforces. The largest source file is now ~2,500 lines, down from ~15,000, and the four files over 5,000 lines are gone. Each session runs in its own worker process under a small supervisor, so one crashing session leaves the others running. The release adds native Windows support (beta) and Homebrew installation.

The verification design

The company says Prime Agent ported itself: 2,209 agents (1,981 on the Rust implementation, 228 on a performance loop), 16,758 agent-to-agent messages, 228.70B tokens from the GLM-5.3 endpoint of Prime Inference, across 10,000+ sandboxes, in two weeks. None of that is independently verifiable — more below. What is documented, in the PR and the blog, is the structure that made the attempt safe.

A single root agent divided the work into a dependency order and wrote no product code; it monitored tasks and merged finished work. Each task passed through four agents:

• a planner writing the specification and verification criteria,
• an implementer writing Rust code in a dedicated worktree,
• a reviewer inspecting the change adversarially, using a different model in a separate context from the implementer,
• a verifier compiling and running the parity checks in a fresh sandbox.

"An agent that writes code is biased when evaluating it," the company writes, explaining why generation and verification were split. The orchestrators ran on two 8-core CPU nodes, each hosting more than 100 concurrent subagents.

The human work was building four parity checks in advance:

1. TUI parity — run both binaries against the same scripted model and diff the terminal frames each renders, covering launch, slash menus, tool calls, compaction, agents view, session resume, subagents, and crash recovery.
2. Harness parity — the same inputs must produce identical session transcripts and identical requests to the model provider.
3. Protocol parity — every message type in the daemon protocol checked against the TypeScript implementation.
4. Feature parity — agents audited the TypeScript product component by component, classifying each as matching, partial, or missing.

Objective checks let agents measure their own progress and catch regressions before merging, which let the company cut back on human review. After parity was reached, a second orchestrator ran a three-day hillclimbing loop: more than 144 experiment and audit records, more than 69 merged changes, and deliberately no numeric targets — "a fixed threshold tends to become a stopping point."

Each change merged only after two reviewer agents, each on a different frontier model, confirmed behavior still matched the TypeScript version. Most gains came from three change classes: moving work off the startup and render paths, replacing polling loops with event-driven waits, and releasing memory as soon as large sessions finished loading.

Why it matters

The transferable ordering is: humans built the checks first, then let the swarm run against them. Three of the four checks are differential — they diff terminal frames, session transcripts, and protocol messages against the TypeScript build — and the fourth is a component-by-component audit. Together they pin the new implementation to the old one's observable behavior rather than to a spec that can be interpreted loosely. The adversarial reviewer on a different model and the fresh-sandbox verifier are cheap structural guarantees that do not depend on the implementing model being honest about its own work.

The target-free hillclimb loop is a smaller but notable pattern: by refusing to set numeric targets, the loop avoided the failure mode where an optimizer converges to the threshold instead of the optimum.

For an organization considering handing a large migration to an agent swarm, this case reframes the question from "can the agents do it" to "what checks do the agents get to grade themselves with." Prime Intellect says it is building the finite-state-machine orchestration pattern into Prime Agent so workflows like this one can be defined once, reused, and updated.

Caveats

• Every performance number above is vendor-reported. No independent benchmark of the Rust vs TypeScript builds exists yet.
• The 2,000-agent figure is claimed, not verified: explainx searched the repository, the pull request, the issue tracker, the launch article on X, and the paper and found no agent count anywhere. The blog's own graphic (2,209 agents, 16,758 messages, 228.70B tokens) is the only record.
• The blog concedes the autonomous phase did not produce the release: "Bringing the rewrite to release quality took follow-up work over the following weeks," with humans finding problems, directing changes, and reviewing all results — and "the parity checks only verified the behavior they exercised."
• Two different tables in the same post produce the headline split between "14× faster" (the hillclimb table) and "13× faster" (the comparison table), and between 79% and 82.5% memory reduction; outlets picked different rows.
• The port was not universally welcomed: GitHub issue #3324 called the rewrite "a huge degradation of usability and functionality and consistency" and was closed as "not planned" by a bot with no maintainer reply.
• The 200B+ token total is not broken down into input vs output, so the actual compute bill is hard to estimate.

Sources

• Prime Intellect — Rewriting Prime Agent in Rust
• Prime Agent repository (GitHub)
• PR 2524 — Port Prime Agent to Rust
• METAL — Prime Intellect Releases Prime Agent Rust Version
• explainx — Prime Agent Rust Port: 2,000-Agent Swarm Claim Checked
• Superpower Daily — Prime Intellect ships a Rust rewrite of Prime Agent
• AICoder — Prime Agent's 2,209-agent swarm rewrite