Time to first token on a fresh Claude load fell from 3.1 seconds to 0.55 seconds at the 75th percentile during Anthropic Claude performance sprint. The two-week effort, described in the company's August 2026 engineering write-up, merged more than 3,000 changes and turned measurement into the core of how AI-assisted optimization works.
What the Claude performance sprint actually changed
Anthropic Claude performance sprint, run in August 2026, cut the core user experience of Claude and the Claude Desktop app to roughly three times faster, according to the company's own engineering write-up. The team focused on four journeys that made up 95 percent of user activity: launching the app, starting conversations, loading existing conversations, and sending messages. Those journeys broke down into 13 distinct measurements, each instrumented to start at a user interaction, end once the result rendered, and separate client work from server work.
The reported numbers, all Anthropic-reported and measured at the 75th percentile unless noted:
| Journey | Before | After |
|---|---|---|
| Fresh-load time to first token, web | 3.1 s | 0.55 s |
| Starting a new Claude Code session | 0.8 s | 0.3 s |
| Loading a Claude Code co-work session | ~3 s | <1 s |
| Sending a message, web | 1 s | 48 ms |
| Sending a message, desktop | 250 ms | 52 ms |
| Desktop app launch | >6 s | just over 3 s |
Anthropic merged more than 3,000 changes during the sprint and reports no customer-facing incident or rollback. Twelve of the 13 initial targets were hit by day three, and the team kept setting new targets afterward. Anthropic estimates the aggregate gains save tens of thousands of user hours of waiting per day. These are first-party figures from the vendor, not independent measurements.
How the sprint ran inside a Slack channel
The whole sprint ran in a single Slack channel where multiple engineers and an internal Claude setup worked in shared threads. Anthropic describes the model as an internal research setup roughly comparable to Opus 5.5, running with fewer guardrails than usual because the team deliberately wanted it to push further. A standing instruction defined the channel's job: monitor deploys for performance regressions, audit telemetry, maintain observability dashboards, fix observed issues, propose projects, and communicate with human teammates.
The loop settled into a repeatable pattern. Someone opened a thread about a slow stretch of a journey, often with a screenshot. Claude traced the flow, built or found benchmarks that demonstrated the problem, then returned with one or more pull requests sized for risk. Anything user-visible shipped behind a short-lived feature flag. After deploy, Claude read the field data, locked in wins by tightening benchmark ceilings, and moved to the next slow spot in the same journey.
Threads did not close when the original request was fulfilled. Individual threads produced 50 or sometimes 100 optimization pull requests, and Claude itself opened new threads to chase opportunities found during nightly jobs. By the second week, more than 200 changes landed on the busiest days, and other Anthropic teams started bringing their own changes into the channel for performance review.
Why measurement, not coding, was the hard part
The central lesson of the sprint, in Anthropic words, is that measuring something makes it tractable. Once Claude a number it could beat, optimization became climbable. The highest-leverage work was finding new things to measure, not writing patches.
Wall-clock milliseconds were too noisy for CI gates, so the team explored deterministic proxies. For pure JavaScript hot paths, that meant instruction counts under Valgrind with Node's predictable mode, compared against a checked-in baseline. For browser paths, where Chromium offers no instruction counting, the team used a ladder of deterministic counts: React commits per interaction, function call counts from V8 coverage, layout and style recalculations, and DOM mutations.
Two examples show the payoff. On the routine that assembles a conversation's message tree, Claude profiled with Valgrind and found a quarter of its instructions were megamorphic dictionary lookups resolving the same message ID three times. An hour later, instruction counts on the two hot paths had dropped 48 percent and 31 percent, with wall-clock time down 78 percent and 44 percent. Elsewhere, a census of the composer's typing path found 6,900 React hooks and 900 store subscriptions rerendering on every keystroke, plus a single root CSS selector adding 24 milliseconds to every DOM change.
Every new benchmark had two jobs: a metric Claude could move in the lab, and a CI guardrail that could only ratchet downward. Benchmarks that were flaky, or that failed to correlate with real user latency, were discarded rather than letting the model climb the wrong hill.
Guardrails, flags, and the Chrome prerender mystery
Every pull request went through automated review plus at least one human approval, unit tests preceded optimizations, and risky changes shipped behind flags. Around 200 flags were introduced across the sprint, and more than half were already retired by the end, with Claude classifying each as a kill switch or a ramp.
The static composer feature needed the heaviest protection, since it renders an HTML copy of the page immediately and lets React paint on top afterward. Claude built guardrails that render the real React component in JSDOM, compare the static page against the React render across 14 viewport sizes with one-pixel tolerance, and type through the handoff to catch lost keystrokes. High-risk changes rolled out to employees first, then 1 percent of users, then everyone.
One bug survived all of that. After the static composer shipped internally, a teammate recorded a layout shift on new-tab navigation that no metric caught. The cause was Chromium speculative prerendering: while a user typed the URL, Chrome pre-rendered the page in the background at the current tab's height, which included Chrome's own 56-pixel footer, so the page was 56 pixels taller at first paint than after navigation completed. Fixing it required understanding the browser, not just the app.
The regressions the sprint's own metrics hid
In his October 2026 review, developer Theo Browne, who builds the T3 Code coding agent, tested the updated Claude and found that the sidebar cache had become aggressively stale. Deleting threads in a second browser did not invalidate the sidebar, and threads created right before a refresh could fail to persist to the recent list at all. He argued the sprint's metrics encouraged this: counting and minimizing network requests rewards cutting the sidebar sync calls that keep cached data honest.
His broader point is one the sprint itself partially acknowledges. Instruction counts and request counts do not show whether a page stays correct, and agents optimizing those numbers can quietly trade reliability for speed. He contrasts this with his own approach on T3 Chat, where cached sidebar data renders immediately but a faded state signals when server data has not yet confirmed it, and with Convex, the reactive backend whose live-sync model removes most of these invalidation problems by design.
The honest read is that both things are true. Anthropic first-party numbers show large, real speedups. The data-layer regressions show why a human still needs to test flows the metrics never thought to measure.
Prompting lessons: ambition, wacky ideas, and taste
The sprint's steering had three parts: ambition, direction, and taste. Claude is careful about scope by default, so early prompting focused on making it bolder. One engineer replied to a hesitant proposal with "If you put it up right now, I will get it merged and deployed. We have the power to do anything. Please be braver." The pull request arrived within the hour.
The most quoted prompt fragment is small: "I am open to wacky ideas." Anthropic credits that line with unlocking the deepest work streams, and Theo reports the same effect on his own project, where a similar prompt led to a custom V8-based runtime and a 2 to 4x improvement on his own workload. Models follow safe paths when told to fix a metric; unusual words pull them toward the ideas they are trained to propose less often.
Direction stayed human. Each thread was deliberately narrow, and most human calls were about sequencing: what to prioritize, how to combine threads that stepped on each other, and when a thread hit diminishing returns. One 900-line pull request that shaved 2 milliseconds off message sends was rejected with a one-line reply about complexity not being worth it.
Taste was also human. Named owners ruled on questions no benchmark answers, like whether tables should fill cell by cell or wait for complete rows, and whether word-by-word fades on streamed text justify their frame budget.
Frequently asked questions
- How much faster did Claude actually get? Anthropic reports roughly a 3x improvement across the core experience of Claude and the Claude Desktop app after the August 2026 sprint. The headline figure is fresh-load time to first token at the 75th percentile, which went from 3.1 seconds to 0.55 seconds. All figures are vendor-reported.
- Did Claude do the work without human engineers? No. Anthropic explicit that the loop was productive but not autonomous. Humans set goals, made trade-off calls, ruled on taste decisions, and approved every pull request, while Claude traced flows, built benchmarks, wrote patches, and watched deploys.
- Why instruction counts instead of milliseconds? Wall-clock time is what users feel but is too noisy to use as a CI gate. Deterministic counts such as Valgrind instruction totals, React commits, and style recalculations are stable, and Anthropic required each one to be proven to track wall-clock improvements before becoming a ratchet.
- Were there any downsides? Yes. Reviewers found stale-cache regressions in the Claude sidebar after the sprint, where deleted threads lingered and fresh threads could fail to persist. The incident illustrates the sprint's own caveat: metrics that reward fewer network requests can quietly discourage the sync that keeps cached data accurate.
Turn your own deep dives into writing
The most valuable part of this sprint was not any single patch. It was a two-hour video's worth of reasoning about measurement, caching, and guardrails, the kind of knowledge that usually stays trapped in a recording. If you have the same kind of thinking sitting in your own YouTube videos, Skalablog can turn it into a written article: paste the URL at skalablog.com, the video gets transcribed, and you get a structured draft you can edit and publish.
For developers documenting benchmarks, postmortems, or tooling lessons, the video-to-article path preserves the causal chain that makes the content worth reading in the first place.
If you build in TypeScript and want a deeper stack to practice these data-loading and caching patterns on, CrazyStack Typescript is a solid place to start.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits