
Rewriting Prime Agent in Rust
Prime Intellect describes rewriting its open-source Prime Agent coding-agent harness from TypeScript to Rust. Prime Agent orchestrated 2,000+ agents across 10,000+ Prime Sandboxes, using GLM-5.3 inference, to do the rewrite. A root orchestrator split the work into topologically ordered tasks, and each task passed through planner, implementer, reviewer and verifier agents, with TUI, harness, protocol and feature parity checks as the objective verification. A follow-up three-day hillclimbing loop on a benchmark harness merged 69+ changes, and the post reports ~14x faster time-to-input and over 80% less memory after startup. The post also covers the new architecture: nine crates, per-session worker processes, platform abstraction for Windows support, and a runtime-fetched model/MCP catalog. Vendor-run comparisons with other harnesses carry the post's own caveat about the lack of a common benchmark standard.
What it claims
Prime Agent, Prime Intellect's open-source coding-agent harness, is now a Rust binary. The company says the agent did most of the port itself over two weeks, using more than 2,000 agents, more than 10,000 Prime Sandboxes and more than 200B tokens from its GLM-5.3 endpoint. The headline outcome is time-to-input about 14x faster than the TypeScript version and over 80% less memory after startup. Native Windows support (beta) and Homebrew installation ship with it. The process matters to anyone planning a large agent-driven port, because the human work went almost entirely into building verification, not into writing code.
How it works
Verification. The page describes four kinds of parity check:
- TUI parity. Both binaries run against the same scripted model, and the rendered terminal frames are diffed. Covered flows include launch, slash menus, tool calls, compaction, agents view, session resume, subagents and crash recovery.
- Harness parity. Session transcripts and outgoing model-provider requests are diffed.
- Protocol parity. Every daemon and ACP message type is checked against the TypeScript implementation.
- Feature parity. Scripts cannot cover the whole interface, so agents audited the TypeScript product component by component and marked each one matching, partial or missing.
Orchestration. A root agent writes no code. It topologically orders the tasks, monitors them and merges finished work. Each task runs through a finite state machine:
flowchart LR P[Planner: spec + TS behavior + parity check] --> I[Implementer in own worktree] I --> R[Reviewer: different model, separate context] R -->|fail| I R -->|pass| V[Verifier: fresh sandbox, run parity checks] V -->|fail| I V -->|pass| M[Merge]
Generation and review are kept in separate agents, and the reviewer runs on a different model from the implementer.
Compute. All orchestrators and agents ran on two 8-core on-demand CPU nodes, each holding more than 100 concurrent subagents. Compilation, type-checking and diffing were offloaded to sandboxes.
Hillclimbing. A second orchestrator ran for three days with no numeric target. The authors argue a fixed threshold tends to become a stopping point. Each experiment went through these steps:
- Agents profile the benchmarks and turn the costs they find into hypotheses.
- Workers build the baseline and the candidate on the same sandbox and run them in alternating order, along with neighbouring benchmarks to catch regressions elsewhere.
- Two reviewers, each on a different frontier model, check TypeScript parity, byte-identical output where the change claims it, and the model-facing surface.
- The change merges, and the next experiment measures from the new baseline.
This produced more than 144 experiment and audit records and more than 69 merged changes. Most of the gains came from three kinds of change:
- moving work off the startup and render paths
- replacing polling loops with event-driven waits
- freeing memory as soon as a large session finishes loading
Architecture.
- Nine crates with a one-way dependency graph enforced by Cargo. The TUI depends only on the shared types crate.
- The largest file is about 2,500 lines, down from about 15,000 in TypeScript.
- Each session runs in its own worker process under a supervisor. Sessions persist on disk so clients can reattach after a restart.
- Transport, process control and file locking sit behind platform traits, which is how Windows support was added.
- One protocol type definition is shared by client, daemon and workers.
Evidence
The benchmark runs each harness on a fresh 4-core, 8 GB sandbox. Each harness drives a real terminal through a screen emulator against a scripted model, so the timings exclude inference. Results too noisy to compare are withheld.
Metrics charted:
- cold-start and warm-start input-ready latency
- process-tree RSS on a 10 MiB session
- installed size
- agents-view switch latency
The page's text states only two numbers: about 14x faster time-to-input and more than 80% less memory after startup, both against the TypeScript version. The per-chart figures do not appear in the text.
How to use it
curl -fsSL https://app.primeintellect.ai/prime-agent/install.sh | shWindows:
irm https://app.primeintellect.ai/prime-agent/install.ps1 | iexHomebrew installation is also mentioned, but the page gives no formula name. The model and MCP lists are fetched at runtime, so new models and plugins arrive without a new release.
Limits
- Parity coverage. The checks only verify the behaviour they exercise. Internal dogfooding surfaced bugs and missing behaviour outside the differential tests.
- Human involvement. Reaching release quality took further weeks of work. Humans found problems, directed changes and reviewed all results, so "autonomous" applies mainly to the initial port.
- Comparisons. Results against other harnesses come from the vendor's own suite. The authors say that, with no common standard, these comparisons should be interpreted with caution.
- Windows. Windows support is beta.
- Unpublished parts. The FSM workflow factory is described as something still being built into the product, not yet available.
Organisations named here
- Prime Intellect
Technologies named here
- Prime Agent
- GLM-5.3
- Prime Sandboxes
- Prime Inference
- Rust
- Cargo
- Clippy
- ACP
- MCP
- Homebrew
- CPython kernels
- TypeScript
- GLM
- Model Context Protocol
- Python
Techniques named here
- Differential parity testing
- Orchestrated finite-state-machine agent workflow
- Agent performance hillclimbing
- Dogfooding with automated trace review
Related in coding-agents
