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

Anthropic said on September 23, in a ClaudeDevs post on X, that a two-week sprint in August made the core experience of claude.ai and the Claude desktop app about 3x faster. Claude found the bottlenecks, built the benchmarks, shipped the improvements and watched every deploy, while engineers set the goals, made the tradeoffs and approved every change. If your team wants to point an agent at your own app’s speed, the accompanying engineering write-up, prompts included, rests on one rule: a benchmark counted only once it was deterministic and proven to track wall-clock time, and after that it became a CI ceiling that could only move down.

What got 3x faster

The sprint focused on four user journeys that make up 95% of activity: launching the app, starting a conversation, loading an existing one and sending a message. Claude identified them by analyzing usage data through the Datadog MCP server. Across web, desktop and products, those journeys came to thirteen measurements, each instrumented to start at a user interaction, end when the result was rendered, and keep client work separate from server work. At the 75th percentile, time to a typeable page on a fresh load of claude.ai fell from 3.1 seconds to 0.55, starting a new Claude Code session from 0.8 seconds to 0.3, and loading a Claude Cowork cloud session from 2.6 seconds to 0.73.

Anthropic gives the 3x as an “about 3x” for the core experience as a whole and ties it to no single measurement. The three p75 figures it publishes range from under 3x faster for a new Claude Code session to more than 5x for a fresh claude.ai load. In aggregate, Anthropic estimates the changes save tens of thousands of user-hours of waiting every day.

The team started with about twenty hand-picked projects. Claude estimated each one’s impact in milliseconds, and the summed estimates became the sprint targets. Twelve of the thirteen were already met by day three. For launches, the team baked a static composer into the HTML so users can type while React initializes, and precompiled a V8 code cache so the desktop shell’s main process doesn’t recompile from scratch. For navigation, it kept the composer mounted between conversations, prefetched sessions when the user hovered over them, and cut sidebar re-renders by 90%.

Counts instead of milliseconds

The method came from wanting Claude to iterate faster than the deploy cadence, sometimes overnight, without waiting for field data. Wall-clock time is what users feel, but it is noisy, and milliseconds were too flaky to serve as a CI gate. When Sam asked whether Claude could count JavaScript instructions instead, it suggested running pure-JS hot paths under Valgrind with node --predictable and comparing the result against a checked-in baseline: one run, no statistics needed. Chromium has no instruction counting, so for browser paths it offered other deterministic counts: React commits per interaction, function call counts from V8’s precise coverage, layout and style-recalc counts, and DOM mutations. Eleven minutes later, five threads were running, one for each measurement.

Each benchmark had two jobs. It had to be a metric Claude could move in the lab, and it had to work as a CI guardrail whose number could only ratchet down. Any benchmark that was flaky, or didn’t correlate with user latency, was thrown out. The team’s instruction was direct: “please prove that hill climbing against each of these can result in measurable wall clock perf wins.”

Claude tested instruction counts on two hot paths: the routine that assembles a conversation’s message tree, and a scanner for status lines in Claude Code output. On the first path, a quarter of the instructions were megamorphic dictionary lookups, the slow fallback V8 uses when one call site sees many object shapes, and they resolved the same message ID three separate times. An hour later, instructions on the two paths were down 48% and 31%, and wall-clock time was down 78% and 44%. Both paths then got ratchets: any PR that raised their instruction counts failed CI, and a daily job lowered each ceiling whenever the count dropped. Anthropic’s lesson is that once Claude has a number to beat, it can start optimizing right away, so the most valuable thing the humans could do was find more things to measure.

A layout shift no monitor saw

A screen recording showed sidebar rows popping in after the page loaded, with chat and Cowork rows resolving at different times. Cumulative Layout Shift scored each shift at about 0.008, well within the 0.1 “good” threshold, so none of the existing monitors caught it. Issac suggested going straight to the underlying Layout Instability API. Claude built a telemetry event that mapped each shift to a named region, such as the sidebar or the transcript, and to a phase, such as before first paint or after the page became typeable. An integration test held back the sidebar’s data until after first paint and failed on any shift in a named region. It went red in 20 of 20 runs on main and green in 20 of 20 on the fix.

Once the event was deployed, field data showed that 31% of web page loads moved something after the page was usable, without any user interaction. Claude then worked through the causes by name: 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.

The loop and its guardrails

Everything ran from one Slack channel through Claude Tag (beta), on an internal research model that Anthropic describes as roughly comparable to Opus 5.5. The standing brief asked Claude to monitor deploys for regressions, assess the telemetry, maintain dashboards, fix low-hanging fruit and propose projects. It also said that full autonomy “isn’t yet possible.” A typical thread opened when someone flagged a slow stretch of a journey, often with a screenshot or a recording. Claude traced the flow, found or built a benchmark, and came back with PRs sized for risk and review, with anything user-visible behind a flag. After each deploy, it read the field data and either ratcheted the benchmark down or turned the flag off and tried again.

The safety rules were in place before the pace picked up. Every PR went through automated review and needed at least one human approval, and unit tests always came before optimizations. During the sprint, more than 150 threads ran at a time, and a single thread could put up fifty, sometimes a hundred, optimization PRs. On the busiest days, more than two hundred changes landed, and about a third of PRs added telemetry or guardrails. Over time, Claude itself opened more of the new threads, from nightly jobs or side investigations. In total, the team merged more than three thousand changes without a single customer-facing incident or rollback.

What the counts turned up

Shelley, one of the engineers in the channel, 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. Counting style recalculations turned up a single :root:has() selector that added 24 milliseconds to every DOM change. Tracing code after first paint found a leftover location.reload() that caused half a million hidden reloads a day, which none of the load metrics could see. Profiler samples from idle tabs showed identical cache snapshots being cloned into IndexedDB twice a minute, on the main thread.

A sweep for CPU hitches found that highlighting a finished code block could freeze the page for about a second, and the cause was em dashes. If a reply’s markdown contained any non-Latin-1 character, such as an em dash or a curly quote, V8 stored the whole string as UTF-16. That put every syntax-highlighting regex on its slower two-byte path. The fix was a twenty-line change that copies each code block into a one-byte string before highlighting it.