How we made claude.ai 3x faster in two weeks
Anthropic made claude.ai 3x faster in two weeks by using Claude itself to find and fix performance bottlenecks—shipping 3,000+ changes across 150+ parallel optimization threads with zero rollbacks, all coordinated from a single Slack channel.
Read Original Summary used for search
TLDR
• The key insight: "measuring something makes it tractable"—once Claude had a number to beat (instruction counts, layout shifts, frame budgets), it could immediately start optimizing, turning measurement from step zero into step one of the climb
• They ran 150+ simultaneous optimization threads, each focused on one narrow benchmark, with Claude autonomously proposing PRs, watching deploys, and opening new threads when it found opportunities
• Instruction counts proved more useful than wall-clock time for CI gates—deterministic and correlating well with user-perceived latency (48% fewer instructions = 78% faster wall-clock time)
• Human role shifted to setting ambition ("the targets are not the stopping point"), taste (ruling on UX tradeoffs), and direction (which surfaces to prioritize)—while Claude handled the optimization work
• Specific wins: eliminated em dashes causing 1-second freezes, found :root:has() selector adding 24ms to every DOM change, caught 500k hidden reloads/day that metrics couldn't see
In Detail
Anthropic achieved 3x performance improvements across claude.ai in a two-week sprint by using Claude itself as the optimization engine. They ran everything from a single Slack channel with Claude in every thread, focusing on four journeys representing 95% of user activity. The results: fresh page loads dropped from 3.1s to 0.55s, new Claude Code sessions from 0.8s to 0.3s, saving tens of thousands of user-hours daily. They shipped over 3,000 changes with zero customer-facing incidents.
The breakthrough was their "loop" framework: someone opens a thread about a slow journey → Claude builds a benchmark to reproduce it → Claude ships PRs behind feature flags → Claude watches the deploy and reads field data → if it worked, ratchet the benchmark down as a CI gate; if not, turn off the flag and iterate. This ran across 150+ parallel threads simultaneously. The central lesson: measuring something makes it tractable. With Claude, you don't need to understand the problem before optimizing—as soon as there's a number to beat, Claude can start climbing. Instruction counts became more valuable than wall-clock time because they were deterministic enough for CI gates while still correlating strongly with user-perceived latency (one hot path: 48% fewer instructions = 78% faster wall-clock).
The human role evolved into three parts: ambition (pushing Claude to be bolder than its default caution), taste (ruling on UX tradeoffs like whether tables should fill cell-by-cell or wait for complete rows), and direction (sequencing threads and deciding when diminishing returns had been reached). Claude found issues no existing metrics could see: em dashes forcing syntax highlighting onto slower UTF-16 paths (1-second freezes), a single :root:has() selector adding 24ms to every DOM change, 500k hidden reloads per day from a leftover location.reload(). The limiting factor became finding things to measure, not finding optimizations—anything they could count, Claude could climb.