Anthropic rewrote the Messages API in Rust using Claude, cutting CPU load by 40–50%

Anthropic has rewritten the Messages API, the interface developers use to call Claude, in Rust. According to Katelyn Lesse of Anthropic, who spoke about it on the Latent Space podcast, none of the project's participants was a Rust developer. Claude wrote the code itself. Humans drew up the plan and checked whether the old and new implementations behaved the same on real traffic. The result, as X user Somi retold it: CPU load fell by 40–50%. The post drew more than 182 thousand views because it hits one of the industry's most persistent dogmas: "never rewrite everything from scratch."

Who did what: the model writes, humans accept the work

The division of labor matters more here than the language. Claude was responsible for writing the code. The engineers were responsible for two things: the rewrite plan and the acceptance criterion. The criterion was a comparison of the old and new versions on real requests. If both services produce equivalent results on the same traffic, the new implementation counts as working. You don't need to understand Rust idioms for this. You only need to describe precisely what the service must do and check it against data.

That explains why "zero Rust developers" doesn't look insane. The main barrier to switching languages used to be a shortage of people who could write and review the code. Here the barrier shifts from writing to verification. The team has a reference in the form of a working production system, and the new version must behave identically to it. This setup suits models: the task is clearly defined, and the result can be checked automatically.

What the 40–50% CPU figure means

For an API that serves a huge number of requests, CPU time translates directly into infrastructure costs. If a service uses half as much CPU under the same load, then either you need fewer servers or the same fleet can handle more traffic. That is our inference from the number, not a statement from Anthropic: the retelling does not say how much money the company saved.

Something else stands out. The technique of rewriting a hot service in a compiled language with strict memory control has been known for a long time. It used to cost months of specialists' work, and most teams passed on it. If a model writes most of the code, the cost of the experiment falls and the payoff calculation looks different. Somi's verdict, "the advice not to do a big rewrite is dead," sounds bold, but a single case does not disprove the rule. It only shows the conditions under which the rule stops applying.

What the retelling leaves out

The source here is a short post linking to a podcast, not a technical report. Several important things are unclear from it:

• which part of the Messages API was rewritten: the entire stack or individual components;
• how latency and throughput changed, not just CPU load;
• how long the work took and how many iterations Claude needed;
• what discrepancies between the old and new versions turned up during comparison and how they were resolved;
• how the team will maintain code in a language none of them knows.

The last point is the most uncomfortable. Code that no human has read in depth will still have to be maintained, debugged for rare errors, and extended with new features. As long as Claude stays at hand, that is manageable. But the long-term cost of this approach can't be judged from a single case.

Practical takeaway

The recipe you can borrow doesn't depend on Rust. First, pin down the behavior of the existing service: collect real requests and responses and set up a comparison of the two implementations. Then humans keep the plan and the acceptance, and the model takes the rough work. The better your test harness and shadow traffic replay, the safer such a rewrite is. Without them, the model will simply generate a lot of unverified code quickly. Before repeating Anthropic's experiment, it is worth waiting for the full version of the story and seeing how the team handled the questions the retelling doesn't cover.