Anthropic rewrites Messages API in Rust, cutting CPU use 40-50%

Anthropic has migrated the Messages API behind Claude from Python to Rust in a single wholesale move. Katelyn Lesse, who leads engineering, and Angela Jiang, who leads product, walked through the migration on the Latent Space podcast. After the switch, CPU use fell by about 40% to 50% and response time for the first token improved by roughly 10% to 20%, with larger gains on long-running tasks. According to the guests, the Rust version of the API went fully live the week before the recording.

The Messages API is the main entry point for developers calling Claude. Jiang recalled that when she joined about a year ago, the system was a Python monolith running in just one GCP region.

The bottleneck was CPU

Discussion of large-model companies usually fixates on GPUs, but in this interview the recurring constraint was CPU. As usage grew rapidly, the API service, product backends, code sandboxes and continuous integration all competed for CPU, and the more code got written, the more often CI ran. As the guests described it, the research team and the product sandboxes draw on the same CPU quota, so more use on one side means less on the other. The Python service looked especially expensive in that environment.

Choosing Rust was contested internally, for a simple reason:

“we don't have a single Rust developer in the room.”

The team only later brought in engineers with Rust experience.

Illustration: twin pipes link old and new machines, depicting shadow traffic checks during the Anthropic Rust migration

Humans draw the architecture, Claude writes the implementation

The division of labor went like this: engineers owned the design and verification of the distributed system, while Claude wrote most of the implementation code. Claude was also used to help engineers pick up the Rust knowledge they needed. The guests stressed that planning and verification matter more than the act of writing code.

The verification approach was fairly traditional. The team first built a complete Rust branch of the API and shadow-copied live traffic to it, comparing the outputs of the old and new systems request by request. They then shifted real traffic over bit by bit using feature flags and load balancing. A dedicated group handled the migration while other engineers kept building new features. To keep the two codebases from drifting apart, the team used static analysis to flag features added in Python that had no Rust counterpart yet, and the porting group tried to turn down new requirements during the migration.

The guests estimated that a conventional, piece-by-piece migration could have taken several years, whereas this was a one-shot wholesale port. How long it actually took, and what share of the code Claude generated, were not given in the interview and cannot be checked externally for now.

Seen alongside similar rewrites

Large rewrites in which a model does the bulk of the writing and humans act as the safety net have appeared several times recently. GitHub previously disclosed using Copilot to rewrite its own runtime into roughly 830,000 lines of Rust, and around the release of Opus 5.5 one team used it to move a TypeScript compiler to Rust in two weeks. What these cases share is that Rust was the target language each time, and that verification relied on comparing old and new outputs or on a full test suite.

The difference lies in the cost of getting it wrong. When a compiler or developer tool misbehaves, the impact is mostly on developers' local machines. The Messages API handles all external calls, so any behavioral mismatch lands directly in customers' production systems. Anthropic could attempt a wholesale port on this path because of the old-fashioned combination of shadow traffic and request-by-request comparison; a model that writes fast would not have carried it alone.

For other companies, the transferable part is probably the verification process rather than the choice of language. Without shadow traffic and output comparison, it is hard to tell whether a large batch of code produced by a model in one go behaves the same as the old system.

Next up: conversation state

The team said architecture-level changes will follow, and one direction is storing conversation state on the server so clients no longer have to resend the full history every turn. In long conversations, that could save a great deal of repeated transmission and repeated processing. Anthropic has not announced when the change will ship, or whether it will affect existing interfaces and billing.

Sources: Latent Space podcast interview, CocoLoop, Anthropic developer documentation; the interview was checked for the CPU reduction, the range of first-token latency improvement and the full-rollout status.