Anthropic says a two-week sprint improved 13 performance measurements across claude.ai and the Claude desktop app, with engineers setting targets and steering the work.
By [RuntimeWire Staff](https://runtimewire.com/author/runtimewire-staff)
· Published
Primary source: [Anthropic](https://claude.dev/blog/how-we-made-claude-ai-faster/)
Why it matters #
Anthropic's account gives a concrete example of a coding agent helping engineers search for performance fixes when each change is tied to a benchmark and checked after deployment. The 3.1x result is company-reported and does not establish whether faster interactions changed retention or revenue.
Anthropic says a two-week sprint in August made claude.ai and the Claude desktop app 3.1x faster on average by giving Claude a steady stream of performance measurements to improve. Anthropic's engineering post compares real-user measurements from August 13th and August 27th across four journeys Anthropic says account for 95% of activity.
The project offers a detailed look at a change in the engineers' working rhythm. Claude analyzed usage data, built benchmarks, proposed and shipped code changes, then watched deployments for regressions. Human engineers chose the targets, weighed tradeoffs and approved the work.
Anthropic reports that the 75th-percentile time to a typeable page on a fresh claude.ai load fell from 3,085 milliseconds to 550 milliseconds. Claude Cowork cloud-session fell from 2,566 milliseconds to 728 milliseconds, while starting a Claude Code desktop session fell from 837 milliseconds to 347 milliseconds. Across 13 measurements, Anthropic says the geometric-mean improvement was 3.1x. That average combines distinct tasks and products; it does not mean every interaction became three times faster.
Measurement became the work
Anthropic's engineers began with about 20 projects aimed at specific performance targets. Claude estimated each project's expected savings in milliseconds. Anthropic says it reached 12 of 13 initial targets by day three, then moved on to opportunities the original plan had not covered.
Some early changes were direct engineering work: a static composer embedded in the HTML let users type before React finished initializing; a precompiled V8 code cache reduced desktop startup work; session prefetching began when a user hovered over a conversation; and Anthropic's engineers cut sidebar re-renders by 90%.
The next step was to let Claude search for new measurements, not just optimize the ones in the initial plan. Working through a Claude Tag beta channel in Slack, the model analyzed data through Datadog's MCP server and explored measures such as JavaScript instruction counts, V8 function calls, React commits, style recalculations and DOM mutations. Anthropic says it kept a benchmark only when it could be moved in a test environment and shown to track real wall-clock performance. Anthropic discarded measures that were flaky or did not correspond to user latency.
One example shows the distinction between a convenient metric and a useful one. Claude found that a routine assembling a conversation's message tree spent a quarter of its instructions on repeated lookups. After an optimization, instruction counts on two hot paths fell 48% and 31%; measured wall-clock time fell 78% and 44%, respectively, according to Anthropic's engineering post. Anthropic's engineers added CI checks that failed when those instruction counts rose, then lowered the thresholds when further improvements landed.
A screen recording showed sidebar rows appearing after the page loaded. Chat and Cowork rows resolved at different times, making the page feel janky, Anthropic says. Existing monitors did not detect the problem. The closest measure was Cumulative Layout Shift, but each shift scored about 0.008, below the 0.1 threshold Google classifies as good.
Faster output, with human gates
Anthropic says more than 3,000 changes were merged during the sprint without a customer-facing incident or rollback. That figure comes from the company's account; the post does not provide the traffic sample size or an independent audit of the before-and-after comparison.
A July 21st, 2026, Anthropic post on its review policy describes a risk-tiered process: multiple agents automatically review pull requests, while human approval is reserved for regulated or truly critical code.
The static composer illustrates the product tradeoff. It brought an input field forward while the full React page was still , reducing the time before a user could start typing.
Anthropic's account describes an engineering loop built around benchmarks: Claude reproduces a problem in the lab, proposes code changes, and checks performance after deployment. Engineers decide which targets are worth pursuing and whether the measured change benefits users. Anthropic's estimate that the work saves "tens of thousands of user-hours" of waiting each day is not independently verifiable from the post, which does not publish the traffic volumes or calculation behind it.
The sprint's broader bet is that a coding agent can expand the amount of engineering work a team attempts when its work is bounded by measurable goals and reviewable changes. Anthropic's account includes Claude opening optimization threads and producing code, while engineers retained responsibility for deciding what counted as a worthwhile user-facing improvement. The speed figures support a narrower conclusion: on the 13 measurements Anthropic selected, its products got faster over the two-week comparison. Whether that translates into stronger retention or revenue is not established by the post.