Anthropic says it moved the Messages API, the endpoint behind every Claude API call, from a Python monolith to Rust, and that Claude wrote most of the code even though nobody on the team knew Rust. The source is Katelyn Lesse, who runs platform engineering at Anthropic, on the Latent Space podcast published October 27, 2026. The figures she gave are about 40 to 50 percent less CPU and 10 to 20 percent faster time to first token. As of October 31, we found no Anthropic engineering post or changelog entry that repeats them, so treat the numbers as an executive's account, not a published measurement.
This post lays out what is claimed, what we could confirm, what is still secondhand, and what a team can copy from the method regardless of the exact percentages.
TL;DR: claimed vs verified
| Question | Answer | Status |
|---|---|---|
| Does the interview exist? | Yes. Latent Space published a 107-minute episode with Lesse and Angela Jiang on October 27, with a timestamped segment "Rebuilding the Messages API in Rust" at 56:05 | Confirmed |
| Was the API ported from Python to Rust? | Lesse says the Python monolith was reimplemented in Rust | Her statement, relayed by InfoQ |
| Did the team start with no Rust developers? | Yes, at the start. Later the team hired several people with Rust experience | Her statement |
| Did Claude write the code? | Claude did most of the implementation; humans did architecture, plan and verification | Her statement |
| CPU down 40 to 50 percent? | Her figure, for the API service layer | Unverified by a third party |
| Time to first token down 10 to 20 percent? | Her figure | Unverified by a third party |
| Anthropic engineering post with data? | Not found | Missing |
What exactly was said, and where
The episode page for How Anthropic ships the #1 LLM in the World safely lists show notes and timestamps. Two of them matter here: "CPU constraints and scaling" at 53:25 and "Rebuilding the Messages API in Rust" at 56:05. That confirms the topic was discussed on the record by a named Anthropic leader. The page we could read does not include the transcript text, so we did not read her words in the original.
The detailed account we could read comes from a Chinese-language InfoQ interview with Lesse, republished in English by 36Kr on October 29. In it, Lesse is quoted saying that CPU capacity now has to be planned in advance, where it used to be something you could scale on demand. She says the system running at the time was a Python monolith with very low CPU efficiency, that the team decided on Rust, and that there was not a single Rust developer on it. She says the plan was to let Claude write the code while humans designed the system, "after all, it is essentially still a set of distributed system architecture." She also says the Rust version of the Messages API had just completed its full launch.
That is a translation of a translation of a conversation, so exact wording may differ from the audio. The substance is consistent across the sources we found, including a summary from Scuttlebutt that headlines the same 40 to 50 percent CPU figure and says the move took roughly a year. That summary is paywalled, so we only saw its opening.
The viral version of the story, an X post claiming "Zero Rust devs on the team" and ending "never do the big rewrite is dead advice," is a reading of the interview, not a quote from it. The closing opinion belongs to the poster.
What the reports do not say
Several details get lost when the story is compressed into a post.
"Zero Rust devs" is a starting condition. Lesse said that now the team members probably all consider themselves Rust engineers, and that Anthropic also recruited several engineers with more Rust experience along the way. A fair summary is: a team without Rust experience started the port with Claude, learned the language on the job, and added some experienced hires.
The numbers are about the API layer. The Messages API is the service that authenticates requests, validates them, routes them, handles streaming and tool-call plumbing, and talks to the inference fleet. CPU savings there lower the cost and the capacity planning burden of serving the API. They say nothing about how fast the model itself generates tokens. The 10 to 20 percent time-to-first-token improvement is plausible for a service that adds overhead before inference starts, but it is also a smaller effect than the CPU number, and we have no latency distribution, percentile, or workload description.
"Claude wrote it" does not mean "Claude translated it." Lesse stressed that the two most important parts of the project were the implementation plan and the verification of the final result. That is the opposite of pasting Python into a chat window.
It was a port, not a redesign. Lesse said the team deliberately held back the urge to add features, and preferred to call it a port. A small dedicated team did the work while other teams kept shipping features to the Python API. The port team used static analysis so that when engineers added a feature in Python, someone had to consider the Rust equivalent.
How the migration worked
Taking Lesse's account at face value, the method is the part worth studying.
- Plan first. Humans decided the architecture and the migration strategy.2. Build the full replacement. The team built a complete Messages API in Rust rather than migrating endpoint by endpoint.
- Shadow traffic. Production requests were mirrored to the new system, and the outputs of the Python and Rust implementations were compared for consistency.
- Gradual cutover. Real traffic moved over in steps as the comparison held up.
- Keep the old system in sync. Static analysis flagged feature changes made in Python so the port did not drift.
This is differential testing at production scale. If you have read our guide to proving an AI-made port is equivalent with differential testing, it is the same idea: when the old system is the specification, the strongest check is running both on identical inputs and diffing the results. The AI is allowed to be fast and a little unreliable because the harness is strict.
Stopwatch with speed lines illustrating Messages API time to first token improvements
Why Anthropic cared about CPU
Lesse framed CPU as a planning constraint that has become strategic. Usage of Claude has grown quickly, and an API that spends CPU on every request becomes a line item and a capacity risk. The same interview, according to the episode title and a third-party summary, also covers how Anthropic separates the "brain" of an agent from the "hands" that execute code, and the platform work around the Claude Opus 5.5 launch. In other words, the Rust port is one piece of a platform story about reliability and scale under rapidly growing demand.
That fits what we have seen elsewhere in the stack. Developers have been shaving overhead off the path between a prompt and the first token, as in our explainer on gzip and faster first-token times in Claude Code. And as agents multiply, the infrastructure around them gets stressed first, a theme in Lesse's own post covered in Multiagent Systems Need Four Engineering Fixes.
Is Rust the reason, or is it the rewrite?
A caution: a 40 to 50 percent CPU reduction does not prove that Rust was the cause. A Python monolith that Lesse herself describes as having very low CPU efficiency probably had room for gains from simply being restructured. Rust's lack of a garbage collector, cheaper concurrency, and tighter memory layout help, and independent projects report similar directions. For example, LiteLLM's documentation on its Rust migration says it is porting its request and response translation layer to Rust to cut latency, and shows stage timings in a chart rather than a single percentage. Our coverage of Respan Gateway shows the same pattern: AI gateways are moving to Rust because they sit on the hot path of every request.
But those are different codebases with different baselines. Without a published breakdown, we cannot say how much of Anthropic's gain came from the language and how much from a clean-sheet design.
The "never rewrite" rule and what changed
The old engineering advice, popularized by Joel Spolsky in 2000, was to never rewrite working software from scratch, because a rewrite takes longer than expected and throws away years of bug fixes. The Anthropic account weakens one reason behind that rule: the cost of producing code. If a model can write the bulk of the new implementation, typing time stops being the bottleneck.
It does not weaken the other reasons. The hard parts, per Lesse, were the plan and the verification. The Python API accumulated behavior over years, and every edge case has to match. That is why shadow traffic matters: it finds the behaviors nobody documented. A team that skips that step because "the AI is good now" is the team that discovers the difference in production.
We saw a smaller version of the same pattern in the community's Rust port of the TypeScript compiler, where the test suite was the thing that made an LLM-written port believable.
What you can copy
If you maintain a service you want to move to a faster language, the Anthropic account suggests a few concrete practices, whatever the final numbers turn out to be:
- Write the plan before the prompt. Architecture, scope, and a definition of equivalence come from humans.
- Declare it a port. Freeze behavior changes in the new code so differences are bugs, not features.
- Mirror real traffic. Compare outputs on production-shaped inputs, not only unit tests.
- Cut over gradually. Keep the old path alive until the diff is boring.
- Guard against drift. If the old system keeps changing, automate a check that tells the port team.
- Budget for learning. Anthropic's team started without Rust experience and later hired some, so plan for at least a few experienced reviewers.
Related: the Claude Managed Agents story is another place where Anthropic describes its platform engineering choices.
What to watch next
Three things would turn this from an interview claim into a verified result. First, an Anthropic engineering post with methodology, workload mix, and before and after charts. Second, API behavior changes: if the port changed any edge-case behavior, developers would notice in error messages, headers, or streaming. The Messages API reference is the contract to watch. Third, pricing or limit changes that reflect lower serving cost, which we have not seen announced.
We will update this post if Anthropic publishes details or the full transcript surfaces.
Related reading
- Claude Opus 5.5 launch: benchmarks and pricing
- Claude Opus 5.5 vs Sonnet 5.5
- Multiagent systems need four engineering fixes
- Prove an AI-made port equivalent with differential testing
- LLM-written Rust port of the TypeScript compiler
- Respan Gateway: open-source Rust AI gateway
- Claude Managed Agents and dynamic workflows
Figures and quotes are as reported on October 31, 2026, from a podcast listing and a secondhand English translation of an interview; they may change as Anthropic or Latent Space publish more.