Claude helped make claude.ai 3x faster in two weeks

According to the ClaudeDevs account on X, a two-week sprint made claude.ai 3x faster, and its oddest find was punctuation. An em dash or a curly quote in a reply could freeze the page for about a second while a code block was highlighted, and Claude found that bug itself during a sweep for CPU hitches.

The team used Claude to measure, debug and improve performance. The blog post that goes with the announcement includes the prompts and methods, so you can try the same approach on your own app. The tweet doesn't say which metric got 3x faster. The post does give figures for each user journey.

At a glance

• Anthropic ran the sprint from one Slack channel in August, with Claude in every thread, and says it merged more than three thousand changes without a customer-facing incident or rollback.
• At the 75th percentile, a fresh claude.ai load became typeable in 0.55 seconds instead of 3.1, and loading a Claude Cowork cloud session dropped from 2.6 seconds to 0.73.
• The key move was replacing noisy wall-clock timing with deterministic counts that Claude could push down. Every figure is Anthropic's own, and the work ran on an internal research model.

Users had been telling Anthropic that claude.ai was slow, and the Claude blog on claude.dev says they were right. The team focused on four journeys that make up 95% of user activity: launching the app, starting a conversation, loading an existing conversation and sending a message. Claude picked them by analyzing usage data through the Datadog MCP server.

Twelve of the thirteen targets were hit by day three

Across web and desktop, the four journeys added up to thirteen distinct measurements. The team added instrumentation until the measurements were comparable. Each one started with a user interaction, ended once the result rendered, and kept client work separate from server work. The sprint began with about twenty hand-picked projects. Claude estimated each project's impact in milliseconds, and those estimates set the targets.

The planned work landed early. The team baked a static composer into the HTML so you can type while React is still initializing. A precompiled V8 code cache means the desktop shell's main process no longer recompiles everything from scratch. For navigation, the composer now stays mounted between conversations, sessions are prefetched when you hover over them, and sidebar re-renders dropped by 90%.

At the 75th percentile, starting a new Claude Code session went from 0.8 seconds to 0.3. Anthropic estimates the sprint saves tens of thousands of user-hours of waiting every day. Once the original project list was nearly done, the team asked Claude for new directions and said it was open to wacky ideas.

Two hot paths got 78% and 44% faster by counting instructions

The team wanted to iterate faster than its deploy cadence allowed, because Claude could work for many hours, even overnight. An engineer named Sam asked whether JS instruction counts could replace wall-clock timing. Claude suggested running benchmarks under Valgrind with node --predictable. For the browser, it proposed other exact counts: React commits, V8 function calls, style recalculations and DOM mutations.

Eleven minutes later, five threads were running, one for each measurement. The team kept any benchmark only if Claude could prove it tracked real wall-clock time. In the routine that assembles a conversation's message tree, Claude found that a quarter of the instructions were megamorphic dictionary lookups, which resolved the same message ID three separate times.

An hour later, instructions were down 48% on the message-tree path and 31% on a scanner for status lines in Claude Code output. Wall-clock time on those two paths dropped 78% and 44%.

A custom layout-shift event found movement in 31% of web page loads

Each thread followed the same loop. Someone opened it about a slow stretch, often with a recording. Claude traced the flow, built a benchmark and came back with PRs sized for risk, with anything user-visible behind a flag. After a deploy, Claude read the field data. If performance improved, it tightened the benchmark. If not, it turned the flag off and tried again.

One recording showed sidebar rows popping in after the page loaded. Cumulative Layout Shift scored each shift at about 0.008, well inside the 0.1 threshold for good, so no monitor caught it. Following Issac's idea, Claude used the Layout Instability API to tag each shift by region and phase. Its test failed 20 of 20 runs on main and passed 20 of 20 on the fix.

Field data showed that 31% of web page loads moved something after the page was usable. Claude then fixed the causes one by one: a header row that arrived late, a caret that slid sideways once the user's name loaded, and a list that moved when the scrollbar appeared.

More than a hundred and fifty threads ran at once

Some threads produced fifty or even a hundred optimization PRs, and more and more often Claude opened new threads itself. Shelley, one of the engineers, called the model a numbers demon. A census of React hooks found 6,900 hooks and 900 store subscriptions in the composer's typing path, all re-rendering on every keystroke.

A single :root:has() selector added 24 milliseconds to every DOM change. A leftover location.reload() caused half a million hidden reloads a day. Idle tabs cloned identical cache snapshots into IndexedDB twice a minute on the main thread. The em dash bug came from V8 storing any string with a non-Latin-1 character as UTF-16, which pushed the highlighting regexes onto a slower two-byte path. A twenty-line change fixed it.

On the busiest days, more than two hundred changes landed, and about a third of PRs added telemetry or guardrails. Other teams started bringing their own changes into the channel for a performance review.

Why a count beats a stopwatch

The post's main lesson is that once you can measure something, you can work on it. Measurement used to be step zero: add a metric, then wait for data. With Claude, it becomes step one, because optimization can start as soon as there is a number to beat.

Wall-clock timing is like a bathroom scale that drifts by a kilo between readings, so you can't tell real progress from noise. An instruction count gives the same result on every run. So any PR that raises it fails CI, and a daily job lowers the ceiling whenever the count drops. That one-way limit is what the team calls a ratchet.

Every figure here is Anthropic's own, and the post does not explain how the headline 3x was calculated from the separate journey numbers. The work also ran on Claude Tag (beta), using an internal research model roughly comparable to Opus 5.5. In our view, the ratchet is the part most worth copying, because a CI limit on a deterministic count probably doesn't depend on which model found the fix.

Where the thirteenth target stands

The post says twelve of the thirteen targets were hit by day three. It does not say whether the last one was met later, or whether the ratchets and the Slack channel keep running now that the sprint is over. Claude Tag still carries a beta label, and no date has been given for wider availability or for the internal model behind it.