# Anthropic says its Claude apps got 3x faster. Here is what changed > Anthropic reports a threefold average speedup across 13 Claude app measurements after an August sprint. The engineering account shows the user gains, measurement loop and human release controls behind the claim. By BIG CHANGE Editorial Published: 2026-09-23T22:52:14.043Z Updated: 2026-09-23T22:52:14.043Z Canonical: https://bigchange.ai/blog/anthropic-claude-app-performance-sprint ![A charcoal-and-ink close view of an unbranded desktop monitor with a blank message field and orange text caret.](https://bigchange.ai/api/media/file/claude-performance-composer-hero-v1.png) AI-generated conceptual illustration by BIG CHANGE. Anthropic says a two-week sprint in August made core tasks in claude.ai and the Claude desktop app about three times faster. Its [engineering account, published September 23](https://claude.dev/blog/how-we-made-claude-ai-faster), gives a more useful answer than the headline number alone: it shows which actions sped up, how the team checked its measurements, and where engineers remained responsible for decisions and release. ## The big change - **What changed:** Anthropic reports shorter waits across 13 measurements of common web and desktop actions. Its 3.1x figure is the geometric mean of those improvements, measured at the 75th percentile on August 13 and 27. It is a company result for selected journeys. - **Why it matters:** For Claude users, a fresh web page becoming ready to type in 550 milliseconds rather than 3,085 changes a repeated part of using the product. For engineering teams, this case shows an AI assistant working through measured performance problems while people choose priorities and approve changes. - **What to watch:** Anthropic says the 95th percentile, other journeys and very long conversations still need work. Those measures will show whether its reported gains extend beyond the selected actions and the August comparison. ## What users gained Anthropic identified four journeys that it says account for 95% of user activity: launching the app, starting a conversation, loading a conversation and sending a message. Across web, desktop and its products, those became 13 measurements. Each began with a user action and ended when the result rendered, with client and server work separated. For a fresh claude.ai web load, the 75th-percentile time to a typeable page fell from 3,085 to 550 milliseconds, a 5.6x speedup. A cold desktop app start fell from 6,310 to 3,328 milliseconds, or 1.9x. Loading a Claude Cowork cloud session on desktop fell from 2,566 to 728 milliseconds, or 3.5x. The client-side portion of sending a web chat message fell from 180 to 59 milliseconds, or 3.1x. These are different actions and platforms; the overall 3.1x figure is the geometric mean of all 13 ratios, not the result of any single task. The comparison uses Anthropic's real-user monitoring at the 75th percentile on August 13 and August 27. The post does not publish an independent audit, a 95th-percentile result for these journeys, or a controlled estimate of how much of the gain came from Claude's assistance. Anthropic estimates that the faster actions save tens of thousands of user-hours of waiting daily, but does not show the calculation behind that estimate. ## The measurement loop behind the changes The team started with about 20 projects selected by engineers. Anthropic says it used Claude Tag, a beta agent running an internal research model roughly comparable to Opus 5.5, to find bottlenecks, build benchmarks and propose changes. The team says it reached 12 of its 13 initial targets by day three, then set new targets and looked for problems its existing monitors missed. One example began with a recording of sidebar rows moving after a page loaded. The existing Cumulative Layout Shift measure did not make the issue prominent. An engineer proposed using the underlying Layout Instability API. Claude then added telemetry identifying the affected page region and an integration test that delayed sidebar data. Anthropic reports the test failed on all 20 runs of the original code and passed on all 20 runs of the proposed fix. Once the telemetry was deployed, the company says it found movement after the page became usable on 31% of web loads. This is a documented example from Anthropic's sprint, not a measurement BIG CHANGE reproduced. The team also used lab measures to move faster between releases. For two JavaScript hot paths, it compared deterministic instruction counts with elapsed time on the same benchmarks. Anthropic reports that lowering instruction counts by 48% and 31% accompanied wall-clock reductions of 78% and 44%. The team made those instruction counts limits in continuous integration, then lowered the limits as performance improved. It says it discarded benchmarks that were unreliable or failed to track user latency. That distinction matters: a lab counter helped guide changes, while real-user readings checked whether shipped work helped. ## Where people kept control Anthropic describes a Slack channel with many narrow threads, each centered on a journey or benchmark. Claude traced a problem, proposed a benchmark and pull requests, watched deployments, and read field data. Engineers set the goals, decided which user-visible tradeoffs were acceptable, and approved every change. Each thread had a named human owner. One proposed 900-line change was rejected because engineers judged a two-millisecond saving per message too costly to maintain. The release process had several checks. Anthropic says every pull request received automated review and at least one human approval, with unit tests before optimizations. User-visible changes went behind short-lived feature flags. High-risk changes reached employees first, then 1% of users, then everyone. The team introduced nearly 200 flags during the sprint and says more than half were removed by its end. Anthropic reports merging more than 3,000 changes without a customer-facing incident or rollback. That outcome is the company's account of this sprint; it does not establish the same result for a different team or codebase. The static composer shows why the controls mattered. Anthropic put a typeable composer in the initial HTML while React loaded. To check the handoff, its tests compared the static and React versions at 14 viewport sizes, checked alignment within one pixel and typed through the transition to catch lost or reordered keys. Field telemetry measured movement during the handoff. An employee later spotted a new-tab layout shift that those measures missed; Anthropic traced it to browser resizing during speculative loading and added a test for that path. Anthropic's report supports a specific conclusion: its engineers used Claude to search and improve measured bottlenecks inside a human-directed release process, and selected user journeys were faster at the end of August. It leaves open how the product performs at the slower tail, how durable the gains will be, and how much of the result an independent observer would attribute to the agent rather than the team's instrumentation, engineering and release decisions. ## Sources - [Anthropic engineering: How we made claude.ai 3x faster in two weeks](https://claude.dev/blog/how-we-made-claude-ai-faster) — Anthropic's primary engineering account of its August two-week sprint. It supplies p75 real-user measurements from August 13 and 27, lab benchmark cases, the described human and release controls, and the company's incident claim. No independent audit or causal attribution of the gains to Claude alone is supplied. - [Anthropic: Code review](https://claude.com/blog/code-review) — Anthropic background linked by the sprint post for automated review. The sprint post itself says each PR had automated review and at least one human approval.