2,000 Agents Ported Prime Agent to Rust. A Terminal-Frame Diff Was the Judge Prime Intellect ported its Prime Agent coding agent from TypeScript to Rust using a swarm of more than 2,000 agents across 10,000+ Prime Sandboxes, consuming over 200 billion tokens from its GLM-5.3 endpoint over two weeks. Each task passed through plan, implement, review and verify stages, with failed reviews or verifications returning work to the implementer, and merges gated on parity checks including a terminal-frame diff that ran both binaries against the same scripted model. A follow-up hillclimb by 228 agents merged over 69 changes, cutting cold start from 736.1 ms to 51.9 ms and memory use from 1,130 MB to 237 MB. On October 9, Prime Intellect https://www.primeintellect.ai/blog/prime-agent-rust published how its coding agent, Prime Agent https://github.com/PrimeIntellect-ai/prime-agent , rewrote itself from TypeScript to Rust. Over two weeks, a swarm of more than 2,000 agents ran across 10,000+ Prime Sandboxes and spent over 200 billion tokens from the company's GLM-5.3 endpoint. The agent being rewritten had been downloaded more than 300,000 times since its August launch, according to the same post. The token count is the headline. The part worth copying is smaller: how anyone could tell the Rust binary behaved like the TypeScript one. The answer was a test that runs both programs against the same scripted model and diffs the terminal frames they draw. Every merge had to pass its task's parity check, and for the TUI that check was this frame diff. A root orchestrator split the port into tasks in dependency order. Per the post, "the root agent wrote no product code." It watched tasks, merged finished work, kept the overview and settled priorities with the humans. Each task then went through four agents: A failed review or a failed verification sends the task back to the implementer with the findings. The pull request merges only when both pass. The post gives the reason in one line: "an agent that writes code is biased when evaluating it." That loop is small enough to write down. Here it is as a TypeScript transition function. The stage names are mine, the rules are the post's: type Stage = | "plan" | "implement" | "review" | "verify" | "merged"; interface Result { pass: boolean; findings: string ; } function next stage: Stage, r: Result : Stage { switch stage { case "plan": return "implement"; case "implement": return "review"; case "review": return r.pass ? "verify" : "implement"; case "verify": return r.pass ? "merged" : "implement"; case "merged": return "merged"; } } Look at the two failure edges. They both go back to the implementer, never forward. No agent can vote its own work through, because the review stage never sees the implementer's context and the verify stage doesn't take an opinion at all. "Behaves the same" is vague until you name what gets compared. Prime Intellect compared four things: The scripted model is the trick that makes this work. A real model answers differently every run, so two binaries talking to it would never draw the same screen twice. Replace it with a script that returns the same tokens in the same order, and any difference between the two screens comes from the client. That is a test an agent can't argue with. The core of a frame diff is boring on purpose. Render each binary in a terminal emulator, capture the screen after each step as text, and find the first step where they disagree: // frames i = the full screen text after step i function firstDiff ts: string , rs: string : number { const n = Math.max ts.length, rs.length ; for let i = 0; i < n; i++ { if ts i == rs i return i; } return -1; // identical } You can get a crude version of the capture step with tmux https://man.openbsd.org/tmux.1 : run each program in its own pane and dump the screen text with capture-pane -p after every scripted input. Prime Intellect's post says it drives a real terminal through a screen emulator; it doesn't name the tool. What matters is the shape: same inputs, same fake model, two programs, one equality check. After the port, 228 agents spent three more days on a performance "hillclimb" and merged over 69 changes. The post's table https://www.primeintellect.ai/blog/prime-agent-rust , from a fresh 4-core, 8 GB sandbox per benchmark: | Metric | TypeScript | Rust, first port | Rust, after hillclimb | |---|---|---|---| | Cold start, input-ready | 736.1 ms | 293.3 ms | 51.9 ms | | Warm start, input-ready | 552.3 ms | 276.7 ms | 41.4 ms | | RSS, 10 MiB session | 1,130.0 MB | 554.9 MB | 237.3 MB | | Installed size | 172.1 MB | 206.7 MB | 59.6 MB | | Agents view switch | 78.0 ms | 118.8 ms | 12.8 ms | The first Rust port started about 2.5x faster than TypeScript 293.3 ms vs 736.1 ms . The hillclimb then cut that another 5.6x, to 51.9 ms. The post's headline 14.18x cold-start figure is the port and three days of tuning together, and the tuning is the larger multiplier. And the first port was worse than TypeScript on two rows: a larger install and a slower agents view switch. The rewrite by itself did not win every row. The benchmark drives the binary "against a scripted model, so timings reflect what a user sees and exclude inference." That 51.9 ms is the time until you can type into a client whose model answers instantly. It says nothing about how long a real turn takes, because every real turn also waits on the model, and nothing about the quality of the agent's work. The post also compares against other harnesses. Time to type, cold: 55.8 ms for Rust Prime Agent, 348.4 ms for Claude Code v2.1.289, 324.6 ms for Codex CLI v0.160.0 and 2,094.5 ms for Hermes Agent v0.21.5. The authors add the caveat themselves: "Without a common benchmark standard, comparisons should be interpreted with caution." AlphaSignal https://alphasignal.ai/news/prime-intellect-sent-2-000-agents-to-rewrite-prime-agent-13x-faster-in-rust notes the numbers "have not been independently replicated." That Hermes Agent is not the Hermes IDE I build; Nous Research publishes an agent under that name. Prime Intellect is direct about the gap: "the parity checks only verified the behavior they exercised." Remaining bugs and behavior differences "were largely found through internal use" and through agents reading beta users' logs and traces. Per the post, humans set up the verification, made the priority calls with the root agent and reviewed all results. Users noticed too. A GitHub issue https://github.com/PrimeIntellect-ai/prime-agent/issues/3324 opened on October 2 calls the Rust TUI "nothing but a huge degradation of usability and functionality and consistency," and its author says they keep a fork that fixes several bugs. A bot closed it the same day under the repo's rule that issue reporters must be vouched for, without a technical reply. It is one report. It still shows the boundary: a frame diff proves the scripted flows match. It cannot prove that flows nobody scripted feel right. Keep the diff, and keep a list of what it covers. Each scripted flow is a promise you can check on every merge; anything outside the scripts is back to humans reading the screen. You don't need 10,000 sandboxes to borrow the pattern. You need three things: the implementer works in isolation, the reviewer is a different agent that never saw the implementer's reasoning, and the verifier is a command that passes or fails. I build Hermes IDE https://hermes-ide.com , so weigh this section with that in mind. Hermes runs each agent in a real terminal, with its own interface. ⌘N Ctrl+Shift+N on Windows and Linux starts a task on its own hermes/