Rewriting Prime Agent in Rust

來源原標題

Rewriting Prime Agent in Rust

作者

piotrgrabowski

原始標籤

hackernews

來源訊號

HN points 62　HN 留言 20

原始連結

https://www.primeintellect.ai/blog/prime-agent-rust

摘要原文

Rewriting Prime Agent in Rust Since we launched Prime Agent [1] in August, it has been downloaded more than 300,000 times and has processed over 8 trillion tokens. Today, we're excited to ship a faster, cleaner and more reliable Prime Agent, rewritten from the ground up in Rust. Over two weeks, Prime Agent orchestrated a swarm of over 2,000 agents to rewrite itself end to end, operating across 10,000+ Prime Sandboxes with over 200 billion tokens from Prime Inference’s GLM-5.3 endpoint. The Rust rewrite stress-tested Prime Agent’s multi-agent capabilities, including the sandbox and inference infrastructure we’ve been building to power large-scale agent swarms, autonomous research, and reinforcement learning. To ensure feature parity with the TypeScript version, Prime Agent orchestrated subagents to topologically sort dependencies, with finite state machines structuring looped computations and correctness checks. In parallel, we rewrote the code architecture for easier maintenance and development. We then used runtime benchmarks and real Prime Agent traces to hillclimb performance metrics and triage bugs. Now, Prime Agent runs faster and uses fewer resources than most coding agent harnesses. Subagent depth Parent Depth 1 Depth 2 Depth 3 Rust Implementation 192.99B tokens 1,981 agents Performance Hillclimb 35.70B tokens 228 agents Oct 01, 15:59 2,209 agents · 16,758 agent-to-agent messages · 228.70B total tokens Why Rust TypeScript helped us ship Prime Agent quickly, but its types are optional and disappear at runtime, errors travel as unchecked exceptions, CPU-heavy work like rendering and parsing large sessions competes with keyboard input on a single event loop, and every process pays for a JavaScript runtime and garbage collector. We want to keep shipping as fast as we do, while holding the code to a higher standard as it grows, and Rust suits that well: Performance: Prime Agent is a long-running daemon with a worker process per session, and native code without a garbage collector accounts for most of the memory and startup gains we’ve made. Concurrency: one daemon streams model output, runs tool calls, relays messages between agents and serves every attached client at once. Rust's Send and Sync traits let the compiler check which data can move between threads and which can be shared. Compile-time guarantees: exhaustive enums, ownership and lifetimes rule out whole classes of bugs before the code runs, and Clippy's pedantic lints add hundreds more checks, which matters when agents write most of the code. In addition to these clear performance gains, the rewrite gives us the opportunity to rethink our design choices. We have significantly modularized our codebase, and are reaping the rewards of this rewrite, including Windows support, session crash isolation, and a more consistent daemon protocol. How Prime Agent rewrote itself Our goal was for agents to perform the rewrite autonomously with as little human intervention as possible. Thus, the human work required was to setup proper verification to enable autonomous deployment at scale. We followed similar setup to previous work on automatic Rust translation [2] . Each specification covered a different kind of parity: TUI parity: a differential test suite compares the TypeScript and Rust binaries side by side against the same scripted model and diffs the terminal frames each one renders. It covers user flows, including launch, slash menus, tool calls, compaction, agents view, session resume, subagents and crash recovery. Harness parity: the same run diffd session transcripts and the requests each binary sends to the model provider, so both produce the same sessions from the same inputs. Protocol parity: all message types in the daemon protocol are checked against the TypeScript implementation, ensuring our ACP and daemon protocol APIs are consistent. Feature parity: since scripted flows cannot cover an entire interface, agents audited the TypeScript product component by component, classifying each as matching, partial or missing. With an objective check for every kind of parity, the agents could measure their own progress and catch regressions before changes merged, which let us cut back on human review. Remaining bugs and behavior differences were largely found through internal use, which guided our follow-up work on missing features, reliability and interface polish. We ran all orchestrators and their agents on two 8-core on-demand CPU nodes, each supporting over 100 concurrent subagents and their respective CPython kernels. Additionally, since compilation, type-checking and diffing would saturate any single machine when dozens of agents are running at once, we built out utilities for our agents to outsource heavy work to Prime Sandboxes, allowing us to heavily parallelize our port. An objective TUI parity verifier compares terminal frames from the TypeScript and Rust versions and highlights differences. Orchestration of Finite State Machines A single root agent orchestrated the rewrite and divided the work into a topological ordering of tasks. The root agent wrote no product code, keeping it free to monitor every task, merge finished work, and maintain an overview of the rewrite while working with us on priorities and decisions. We also kept generation and verification in separate agents, since an agent that writes code is biased when evaluating it. Therefore, each task assigned by the orchestrator moved through four agents: Planner: creates overall machine specification, including the feature design, ground-truth TypeScript behavior, and verifier (parity check) Implementer: writes the Rust code in a dedicated worktree so features can develop in parallel. Reviewer: inspects the pull request adversarially, using a different model and in a separate context from the implementer, looking for reasons the change is wrong. Verifier: compiles and runs the feature's parity checks and tests in a fresh Prime Sandbox. A failed review or verification sends the feature back to the implementer with the findings, and the PR merges once both pass. We are building this pattern into Prime Agent to orchestrate a factory of finite state machines, so workflows like this one can be defined once, reused, and updated. Architecture re-design Porting to Rust also gave us a chance to restructure the codebase. This is where much of the long-term benefit comes from: Modularity: the code is split into nine crates with a one-way dependency graph that Cargo enforces, and the TUI’s only internal dependency is the shared types crate. The largest source file is now ~2,500 lines, down from ~15,000 in TypeScript, with no files over 5,000 lines compared with four in TypeScript. Isolation: each session runs in its own worker process under a small supervisor, so a failure in one session leaves the others running, and sessions persist on disk so clients can reattach after a restart. Platform abstraction: transport, process control and file locking sit behind platform-specific interfaces, so something like Windows support came down to implementing those traits rather than rewiring the daemon. One protocol definition: the client, the daemon and every worker compile against the same message types in the shared types crate, so a change to the protocol is checked everywhere it is used. Catalog-driven models: ported our model and MCP lists to a separate catalog fetched at runtime, allowing us to ship new models and plugins without a Prime Agent release. Refining the work While the autonomous workflow went further than we expected, the parity checks only verified the behavior they exercised. Once parity on the main RLM loop was achieved, we moved all our rewrite agents onto Rust, allowing us to dogfood the Rust version at scale (and now Prime Agent Rust was recursively improving itself!). Later, we moved our internal team onto the Rust build for daily use, which exposed bugs and missing behavior outside the coverage of the differential tests. (62 points, 20 comments on Hacker News)