Anthropic Says Claude Helped Make Its Apps 3.1x Faster in a Two-Week Sprint

Anthropic has published the results of a two-week sprint in which Claude helped find and fix slow spots in its web and desktop apps. The company says 13 measured interactions became 3.1 times faster on average. The more revealing detail is how the work was divided: Claude could pursue a bottleneck from test to deployment, but engineers decided what was worth measuring and approved every change.

Where the waiting fell

The comparison uses real-user measurements from August 13 and August 27. Anthropic tracked four journeys it says account for 95% of user activity: opening the app, starting a conversation, loading one and sending a message. Across web and desktop products, those journeys yielded 13 separate measurements. The reported 3.1x gain is their geometric mean at the 75th percentile; it does not describe the speed of every task or every user’s experience.

A fresh claude.ai web page became ready for typing much sooner in Anthropic’s comparison. Loading a Claude Cowork cloud session also got faster, as did starting a Claude Code desktop session. Those are different actions, so the before-and-after times are more useful than applying the overall average to any one of them.

An agent with a benchmark, not a blank check

The team started with roughly 20 hand-picked projects and targets for particular delays. It says it reached 12 of 13 initial targets by day three, then looked for more opportunities. One planned fix placed a basic message box directly in the page’s HTML, so people could start typing while the rest of the interface loaded. Other work reduced desktop startup work and fetched conversations in advance when a user hovered over them.

Claude’s role went beyond suggesting code. Using an internal research model called Claude Tag, the team had it examine usage data, build tests for slow paths, submit proposed fixes and watch deployments. An engineer could flag a problem in a shared Slack channel; Claude would trace it, test a candidate change and return with code for review. Engineers set goals, weighed tradeoffs and approved changes. Anthropic says it merged more than 3,000 changes without a customer-facing incident or rollback.

A faster test can measure the wrong thing

The team wanted Claude to check improvements without waiting for each deployment, but a convenient lab score was not enough. Anthropic says it discarded tests that were unreliable or failed to track the delay people actually felt. For two frequently run pieces of JavaScript code, Claude cut instruction counts by 48% and 31%. Measured running time fell by 78% and 44%, respectively. The team then made increases in those instruction counts fail automated code checks.

A screen recording exposed the opposite problem: a page could score well on an existing measure yet still feel unsettled. Sidebar rows appeared and shifted after the page loaded, without triggering a useful warning. The team added a test for movement in named parts of the page. Once it could see the problem in real-user data, Claude found that 31% of web page loads moved something after the page became usable, without a user action, and worked through the causes.

What the sprint can show

Anthropic estimates that the changes save tens of thousands of user-hours of waiting each day. Its published figures give a narrower, more concrete result: company-reported before-and-after timings for selected interactions. The account shows how Claude and engineers pursued those gains together; it does not show whether faster apps changed how often people use them. For this sprint, the choice of what to measure shaped both the work Claude did and the result Anthropic can claim.