How we made claude.ai 3x faster in two weeks

I now have enough detail from the source article to write the piece. Here is the article:

Anthropic's engineering team cut the core load times of claude.ai and the Claude desktop app by roughly 3x in a two-week sprint this August, responding to user complaints that the product was slow. The project ran out of a single Slack channel, used Claude Tag — an internal research model comparable to Opus 5.5 — in every thread, and closed with more than three thousand merged pull requests and no customer-facing incidents or rollbacks.

This piece unpacks how Anthropic's engineers structured the sprint, what technical changes produced the largest gains, and what the approach means for teams building on Claude or integrating agentic workflows into their own CI pipelines. Developers who care about frontend performance, real-user monitoring, or AI-assisted refactoring will find the most to take away.

We made claude.ai 3x faster in two weeks: what actually changed

Anthropic engineers identified four user journeys that together account for 95 percent of activity on the product: launching the app, starting a conversation, loading an existing conversation, and sending a message. Before the sprint, fresh page load on claude.ai registered 3,085 ms at the 75th percentile; after two weeks it was 550 ms — a 5.6x improvement. Desktop cold start fell from 6,310 ms to 3,328 ms. Loading a Claude Cowork cloud session went from 2,566 ms to 728 ms. Across all thirteen measurements and four journeys, the geometric mean speedup was 3.1x. The team estimates the aggregate savings at tens of thousands of user-hours of waiting every day.

The first wave of improvements landed inside three days. Engineers baked a static HTML composer into the page so users can type before React finishes initializing, and precompiled a V8 code cache so the desktop shell's main process skips recompilation on cold start. Between conversations, the composer stayed mounted rather than being torn down and rebuilt. Sessions were prefetched on sidebar hover. Sidebar re-renders were cut by 90 percent.

We made claude.ai 3x faster in two weeks: how it works

Once the planned twenty projects were mostly done by day three, the team kept going by finding new things to measure. Claude Tag was given standing instructions to monitor deploys for regressions, assess telemetry coverage, build benchmarks, and propose new opportunities. Each performance thread followed a fixed loop: a human opened a Slack thread with a screen recording or description of a slow stretch; Claude traced the path and reproduced the problem in the lab; Claude opened a batch of pull requests sized for review, with anything user-visible behind a short-lived feature flag; after deployment, Claude read real-user monitoring data by build and platform; if the metric improved, Claude ratcheted down a CI ceiling to lock in the win; if not, the flag was turned off and Claude iterated.

CPU instruction counts under Valgrind with node --predictable became a key lab signal. When applied to message-tree assembly — where a quarter of instructions were megamorphic dictionary lookups resolving the same message ID three times — Claude cut instructions by 48 percent, and wall-clock time fell 78 percent. A status-line scanner in Claude Code dropped 31 percent in instructions and 44 percent in wall-clock time. Both paths got ratchets in CI: any PR that raised the count above the current floor fails the build.

We made claude.ai 3x faster in two weeks: why it matters now

The sprint is a demonstration that agentic loops, when instrumented with deterministic benchmarks and incremental rollouts, can safely drive high-volume refactoring at a pace that manual review alone would not sustain. The team ran more than 150 Slack threads concurrently at peak. On the busiest days, more than 200 changes landed. Claude Tag proposed roughly a third of PRs and included additional telemetry or guardrails in many of them. The ratchets it checked in automatically lower each ceiling when a metric improves, so the nightly CI baseline only ever moves forward.

One thread illustrates the full dynamic. Claude noticed that highlighting a finished code block could freeze the main thread for about a second when a reply contained an em dash or any non-Latin-1 character. V8 stores such strings as UTF-16, putting every syntax-highlighting regex on its slower two-byte path. A 20-line fix that copies each code block into a one-byte string before highlighting brought the first TypeScript block on a page from 1.0 s to 0.35 s, and each later pass on the same block from 100 ms to 40 ms. That fix came from an unsolicited investigation Claude opened on its own, not from any human-assigned thread.

We made claude.ai 3x faster in two weeks: who is affected

Every user of claude.ai on the web, the Claude desktop app, Claude Code, and Claude Cowork benefits directly. Claude Cowork users saw the sharpest single gain: sending a message in a cloud session dropped from 928 ms to 48 ms — a 95 percent reduction. Claude Code on desktop saw message send times fall from 250 ms to 52 ms, and the streaming renderer was rebuilt so long replies stall the main thread 9x less on slower hardware, with the worst single-frame freeze 4.5x shorter. On a 120 Hz MacBook, the renderer now holds 120 fps from start to finish during a long streaming reply.

Developers integrating Claude Tag or building their own agentic coding loops will also want to study the guardrail setup. Nearly 200 feature flags were introduced over the two weeks; more than half were already cleaned up by the end of the sprint. An integration test suite compares the static HTML composer against the live React render across 14 viewport sizes and asserts pixel-level alignment. A keystroke test types straight through the React handoff and fails on any lost or reordered key. In field monitoring, every handoff reports layout shift to a tenth of a pixel and Claude opens a thread for any nonzero reading.

We made claude.ai 3x faster in two weeks: what to watch

Anthropic noted that the 95th percentile, additional user journeys, and very long conversations still have room to improve, and the performance channel is still active. A follow-up post is planned covering contributions that went upstream during the sprint into Electron, Chromium, Node.js, and other open-source projects. Builders should watch for those disclosures, which may surface fixes applicable outside the Claude product stack.

For teams considering a similar approach, the pattern worth verifying is the benchmark-to-CI-ratchet pipeline rather than the total change count. Wall-clock timing alone is too noisy to gate on; the sprint worked because each new metric had to prove it tracked real latency before it was allowed to drive Claude's optimization loop. Any benchmark Claude could not validate against wall-clock improvement was discarded rather than allowed to become a false target. That discipline — measure first, trust the count only after it correlates with the clock — is the constraint that let more than 3,000 changes ship without a rollback.