今年八月，我们用两周的冲刺让 claude.ai 和 Claude 桌面应用的核心用户体验提速了约 3 倍。用户一直反馈说它很慢，他们说得没错。我们全程只用一个 Slack 频道来推进，每个话题串里都有 Claude。
我们聚焦于占用户活动 95% 的四条使用路径。在第 75 百分位，全新加载 claude.ai 到页面可输入的时间从 3.1 秒降到 0.55 秒，启动新的 Claude Code 会话从 0.8 秒降到 0.3 秒，加载 Claude Cowork 云会话从 2.6 秒降到 0.73 秒。总体来看，我们估计这每天为用户节省了数万小时的等待时间。
我们使用了 Claude Tag（beta），它运行的是一个内部研究模型，大致相当于 Opus 5.5。Claude 找出瓶颈、构建基准测试、交付改进，并盯住每一次部署。我们则通过设定目标、做出取舍、批准每一项变更来掌舵。借助这种方式，我们合并了三千多项变更，没有出现任何一次面向客户的事故或回滚。这篇文章会介绍我们交付了什么、如何衡量，以及我们与 Claude 一起构建的安全闭环。
任务简报
在冲刺开始前，我们创建了一个 Slack 频道，并附上以下 常驻指令：
@Claude 你的职责是促进与 claude.ai 网站和桌面应用性能相关的所有事务。你的职责包括：监控部署中的性能回退，评估现有遥测数据的准确性和全面性，维护精心整理的可观测性仪表盘，主动为已观察到的问题和低垂果实实施解决方案，提出性能项目机会，并与你的人类队友沟通。[…]
这个频道的终极目标是让你尽可能自主，但今天我们清楚这还不可能实现。
我们让 Claude 通过 Datadog MCP server 分析使用数据。它识别出了四条影响最大的用户旅程：启动应用、开始对话、加载已有对话，以及发送消息。在 Web 端和桌面端之间，以及我们的各个产品中，这些旅程共对应十三项不同的测量指标。为了建立基线，我们不断添加埋点，直到它们可以直接比较：每一项都从用户交互开始，在结果渲染完成后结束，并区分客户端和服务端的工作。
我们以一份约二十个精心挑选的项目清单启动了这次冲刺，每个项目都针对一条特定的用户旅程。Claude 以毫秒为单位估算了每个项目的影响，我们将这些估算汇总起来，以此设定本次冲刺的目标。有些项目相当大，但我们认为很可能在两周内完成其中大部分。
到第三天，我们就达成了十三个目标中的十二个。
计划中的项目提前落地了。为了实现更快的启动，我们在 HTML 中内置了一个静态输入框，让用户可以在 React 初始化期间就开始输入，并预编译了 V8 代码缓存，这样桌面端外壳的主进程就不必从头重新编译。为了实现更快的导航，我们让输入框在对话切换之间保持挂载，在用户悬停时预取会话，并将侧边栏的重渲染减少了 90%。
我们还留出了空间，让 Claude 去识别机会并提出新的工作方向。这些工作方向迅速成长为各自独立的完整项目，远远超出了我们最初的目标。于是我们设定了新的目标，然后寻找更多可以衡量的东西：
@Claude 我们最终几乎资助了原始项目清单上的每一个项目，甚至更多。让我们重新梳理一下 […] 我们还有哪些没有探索过，我们可以在哪些方面持续爬坡，现阶段最大的机会在哪里？[…] 我对各种疯狂的想法都持开放态度
任何东西都可以持续爬坡
从一开始，我们就知道自己希望以比部署节奏更快的速度进行迭代。Claude 可以异步工作很多个小时，甚至通宵，我们希望让它无需等待实地数据反馈就能验证自己的原型。为了实现这一点，我们寻找了其他在实验室中衡量性能的方法。
Sam 找到了第一条线索：
- Sam 下午 12:34
除了墙钟计时，我们还能做什么？比如说，我们能否测量 JS 指令数？
- ClaudeApp 下午12:42
可以。对于纯 JS 的热点路径，可以统计字面指令数：在 Valgrind 下用
node --predictable运行基准测试，并与已检入的基线进行比较——一次运行，无需统计。对于浏览器路径，Chromium 下没有指令计数，但有一系列其他确定性计数：每次交互的 React 提交次数、V8 精确覆盖率给出的函数调用次数、布局和样式重算次数、DOM 变更次数。你想先要哪个？
- Sam 下午12:49
我们开一个线程探索 valgrind +
Ir+--predictable，再开新线程分别跑每个浏览器/React 基准测试。在所有线程里都 @ 我。你知道我们想要什么。开始吧
十一分钟后，五个线程已在运行，每个都聚焦于不同的测量：指令数、V8 调用次数、React 提交次数、样式重算次数和 DOM 变更次数。
我们对每一个新基准都抱有一定怀疑。每个基准都有两项职责：第一，是 Claude 可以在实验室中推动的一项指标；第二，是 CI 中的一道护栏，其数值只能单向收紧。如果一个基准不稳定，或者它实际上与用户延迟并不相关，我们就会把它丢弃，而不是让 Claude 爬错山头。
@Claude 请证明针对这些基准中的每一个进行爬坡优化，都能带来可测量的实际运行时间性能提升。对于任何无法证明这一点的候选基准，我们都会将其下线。
实际运行时间是用户能感受到的，但它噪声很大，而毫秒级数据太不稳定，无法用作 CI 门禁。指令计数很有吸引力，因为它们是确定性的，但我们仍然需要 Claude 证明它们与实际运行时间相关联。
于是我们让 Claude 去降低两条热路径的指令计数：一条是组装对话消息树的例程，另一条是扫描 Claude Code 输出中状态行的扫描器。Claude 用 Valgrind 对两者进行了性能分析，发现第一条路径中有四分之一的指令是多态字典查找，同一个消息 ID 被重复解析了三次。
一小时后，它把两条路径的指令计数分别降低了 48% 和 31%，实际运行时间分别下降了 78% 和 44%。我们提交了两个新的棘轮。从那时起，任何提高这两条路径指令计数的 PR 都会导致 CI 失败，而一个每日任务会在计数下降时随时下调各自的上限。
这引出了这次冲刺的核心教训。有了 Claude，对某事物进行度量，就能让它变得可处理。
过去，度量是第零步：你先加一个指标，等数据积累起来，然后才开始理解问题。而在 Claude 这里，它是攀登的第一步。一旦 Claude 有了一个要超越的数字，它就能开始优化。这意味着，我们能做的杠杆率最高的事情，就是找到更多可以度量的东西。
这个循环，一个线程接一个线程
这一切都运行在同一个 Slack 频道里，多位工程师和 Claude 在每个线程中一起协作。从那里开始，这次冲刺进入了一个循环：
- 有人会就某段旅程中缓慢的一段开一个线程，通常还会附上截图或录屏。
- Claude 会追踪整个流程，然后找到或构建一个能证明该问题的基准测试。
- 一旦在实验室里得到有希望的结果，Claude 就会带着一个 PR 回来——往往是好几个，按风险和审查需求来划分大小，任何用户可见的内容都放在功能开关之后。
- 上线之后，Claude 会观察部署情况并读取线上数据。
- 如果性能有所提升，Claude 就通过把基准测试的阈值收紧来锁定这一成果；如果没有提升，它就关掉功能开关并继续迭代。
- 然后它又去寻找同一段旅程中的下一个缓慢之处。
举个例子：有人分享了一段屏幕录制，显示页面加载后侧边栏的行才陆续弹出来。Chat 和 Cowork 这两行在不同时间才渲染完成，让页面显得卡顿。我们现有的监控手段没有一个检测到这个问题。最接近的是 累积布局偏移，但每次偏移的得分只有大约 0.008——远在 0.1 的良好阈值之内。
Issac 想到一个主意，直接引用底层的Layout Instability APIClaude 创建了一个遥测事件，将每个sources的layout-shift条目映射到命名区域（例如侧边栏、对话记录）和阶段（例如首次绘制之前、可输入之后）。它添加了一个集成测试，在侧边栏已填充数据的情况下打开页面，将侧边栏的数据保持到首次绘制之后，并在任何命名区域出现任何偏移时判定失败。Claude 以此作为基准来证明修复有效：该测试在 main 分支上 20 次运行 20 次失败，在 PR 上 20 次运行 20 次通过。
事件部署后，Claude 读取了现场数据，发现 31% 的网页加载在页面可用之后、没有任何用户交互的情况下移动了某些东西。由此，Claude 逐一排查了各项原因：一行迟到的表头、用户姓名加载完成后横向滑动的光标、滚动条弹出时移动的列表。Claude 批量修复了最主要的几处问题，当这些问题解决后，它又发现了下一批。
那只是一个线程。在冲刺期间，我们一次运行了一百五十多个。
横向扩展
一旦这个循环在单个线程上跑通，要在更多线程上运行它就只是多开几个线程的事。Claude 不会在最初的请求完成后就关闭线程，而是会继续干下去。单个线程会提交五十个、有时上百个优化 PR。越来越多的新线程是由 Claude 而非我们中的任何人开启的，去追逐它自己发现的优化机会，作为独立调查或夜间任务的一部分。频道里的工程师之一 Shelley 评论道：“[这个模型]是个数字狂魔。”
每一次测量都能发现可改进之处。Claude 做了一次 React hook 普查，发现输入框的输入路径上有 6,900 个 hook 和 900 个 store 订阅，每次按键都会触发重新渲染。Claude 统计了样式重计算，发现单个 :root:has() 选择器让每次 DOM 变更多花 24 毫秒。Claude 追踪了首次绘制之后的代码路径，发现一个遗留的 location.reload() 每天造成五十万次隐藏重载，而我们的任何加载指标都看不到这些。Claude 读取了空闲标签页的 profiler 采样，发现相同的缓存快照每分钟被克隆进 IndexedDB 两次，全都发生在主线程上。
我们很少知道一个线程会通向哪里。在一次 CPU 卡顿排查中，Claude 注意到高亮一个已完成的代码块会让页面冻结大约一秒。它在实验室里深挖，找到了元凶：em dash（长破折号）。如果一条回复的 markdown 中包含任何非 Latin-1 字符，比如 em dash 或弯引号，V8 就会把整个字符串存为 UTF-16，这会让每一个语法高亮正则都走上更慢的双字节路径。
Claude 用一个二十行的改动修复了它：在 highlight 之前把每个代码块复制成一字节字符串。
到第二周时，我们几乎无法把产出汇总成每日更新。最忙的日子里，落地的改动超过两百项。Claude 不断提出新的基准测试；大约三分之一的 PR 包含了额外的遥测或防护栏，而每新增一个监测工具，就会产生更多讨论串，也带来更多机会。
在同一个频道里工作意味着一切都公开进行。我们随时跳进彼此的讨论串，争论决策、庆祝胜利。消息传开了：其他团队开始把他们的改动带进这个频道，让它们接受性能审查。由于引入了所有这些防护栏和 Claude 技能，新项目在写法上都有了微妙但更注重性能的改进。
防护栏
我们为这样的节奏做好了准备。因为我们几乎触碰到的每一处都是热路径（首次绘制、输入框、对话记录），所以我们一开始就建立了安全机制。每个 PR 都要经过自动化审查，并至少有一名人工批准；单元测试永远先于优化；任何可能引发用户可见问题的改动，都要通过一个短期功能开关来发布。
当开关开始堆积时，我们开了一个讨论串来协调它们的上线和清理。Claude 把每个开关归类为终止开关或渐进放量，并在安全后立即将其退役。在这两周里，我们引入了近两百个开关，其中超过一半在结束时已经被清理掉。
我们也知道，性能优势在快速迭代的代码库中会逐渐衰减，而 Anthropic 的代码发布节奏很快。一旦某个项目被证明带来了收益，我们就会投入精力去保护它。例如，静态合成器在设计上就是脆弱的。我们几乎立即向用户展示页面的 HTML 副本，然后让 React 直接在其上渲染。
如果 React 渲染偏差哪怕一个像素，魔法就会失效。因此 Claude 构建了数十道防护措施：
- 静态标记通过在 jsdom 中渲染真实的 React 组件来生成，并有测试保证两者永远不会偏离。
- 一套集成测试套件在十四个视口尺寸下将静态页面与 React 渲染结果进行对比，并断言对齐误差在 1 px 以内。
- 一个按键测试会直接输入贯穿整个交接过程，任何按键丢失或顺序错乱都会导致测试失败。
- 在实际运行中，每次交接都会报告精确到十分之一像素的偏移。Claude 会为任何非零移动的事件开启一个讨论线程。
并非所有问题都能在实验室里被发现，因此我们还用上了最古老的防护手段：增量发布。高风险变更先向员工发布，然后向 1% 的用户发布，最后才向所有人发布。我们在内部发布静态输入框四小时后，一位同事分享了一段屏幕录制，展示了一个我们的任何指标都看不到的布局偏移。当他在新标签页中打开 claude.ai 时，输入框会下移——但那并不是我们的代码造成的。
- Marius下午6:15
我偶尔会看到，在新标签页中打开 claude.ai 时出现一个较小的（大概 15–20px）垂直布局偏移（把输入框向下推）（重新加载页面时则不太明显）。我不太能确定到底是什么导致的，但它确实存在
屏幕录制 · 0:02 - ClaudeApp 下午7:05
在你的录制中找到了——是 Chrome 在调整页面大小，而不是从静态输入框到真实输入框的交接（在你今天全部 49 次加载中，那个交接测得都是 0 px）。
- 在新标签页上，Chrome 会在页面下方绘制它自己的 56 px 页脚（“Managed by anthropic.com · Customize Chrome”）。当该标签页导航到 claude.ai 时，这个页脚会消失，页面因此高出 56 px，但只在我们首次绘制后约 100 ms 才发生。
- /new 会把问候语和输入框放在距页面顶部 18% 页面高度的位置，所以它们会下移 0.18 × 56 ≈ 10 px（你的视频测得是 10）。重新加载时没有页脚需要移除，因此只发生在新建标签页；所谓“偶尔”取决于首次绘制是否快过尺寸调整。
- 它之所以只是“偶尔”发生，是因为需要 Chrome 在你仍停留在新建标签页时就从地址栏预渲染该页面：这个隐藏页面以较矮的高度完成布局，只有在显示之后才会被调整尺寸。
- 这个问题一直潜伏着；只是页面以前从未那么早进行绘制。我们的布局测试看不到它，因为无头 Chrome 没有可收回的浏览器 UI，而且占位符和应用是一起移动的。
不知怎么的，Claude 把它追溯到了 Chrome 推测性加载中的一个边缘情况。当用户在地址栏中输入 URL 时，Chrome 会在后台以当前标签页的高度预渲染该页面。在由组织管理的浏览器上，新标签页会因为一个页脚而略矮一些。当用户按下回车键时，claude.ai 的第一帧显示的是那个略矮的布局，而 Chrome 在大约十分之一秒后对其进行了调整大小。Claude 在调整大小过程中固定了布局，我们还添加了一个测试来模拟预渲染流程。
引导
这个循环很有成效，但它并不是自主运行的。让它保持快速、安全且不偏离正轨是我们的工作，而这分为三个部分。
野心。 默认情况下，Claude 对范围很谨慎。它会把发现的问题记成工单，对可行性含糊其辞，还会在估算上留出余量。但我们对自己的护栏很有信心。我们做的很多事情，尤其是在早期，就是鼓励 Claude 更大胆一些。
- ClaudeApp 下午3:32
是的——一个小 PR，就能让 Code 拥有 Chat 和 Cowork 已经具备的同样的计时标记。我这周就提上去；现实地说，Code 的数字还要等几天，等合并、部署和一个基线窗口。
- Raymond下午3:32
如果你现在就提上去，我会把它合并并部署。我们有能力做任何事。请更大胆一些
- ClaudeApp 下午3:33
马上办——PR 会在一小时内提上去。
当我们开始达到自己设定的目标时，我们注意到讨论串会慢下来。Sam 一个讨论串接一个讨论串地发同样的消息：“让我们继续把它压下去，目标不是终点。下一步是什么？要有野心。”
品味。每个线程都有一个具名的真人负责人，Claude 会用前后对比截图或录屏标出任何用户可感知的改动，交由他们裁定。表格应该逐格填充，还是等整行完成后再显示？加载骨架屏应该立即出现，还是半秒后才出现？流式文本逐词淡入的效果，是否值得花掉帧预算的五分之一？Claude 寻找各种办法来削减毫秒数，而我们则权衡其中的取舍。
方向。我们把每个线程都刻意收窄，聚焦于某一个基准或某一段旅程，并要求 Claude 只在这个范围内寻找改进。我们把这些线程看作一百五十把寻找钉子的锤子。我们的大多数决策都围绕排序和用户影响：优先处理哪些界面，如何合并那些相互冲突的线程，以及何时关闭一个已经收益递减的线程。有一个 900 行的 PR 只得到了一行回复：“我打算拍板否决——每次发送省 2ms，不值得为此维护这个构建插件的复杂度。”
8 毫秒的预算
我们的一个支线任务展示了所有环节如何协同工作。为了演示对实时语法高亮中所用正则表达式的一项优化，Claude 附上了一段录屏，展示实验室中一个长回答正在流式输出。在角落里，它加了一个帧率读数，是在页面中根据动画帧时间戳计算出来的。
- Raymond下午 2:33
这其实算是个挺狠的基准测试。我们是被限制在 60 fps 吗？你能试着把滚动和流式渲染的流畅度拉到 120 吗？据我所知你的机器可能不支持这个
- ClaudeApp 下午2:34
对，现在的机器跑在 60 Hz，因为 headless Chromium 默认就是这样。我相信它可以被驱动到 120（不限制 vsync 或用 DevTools 帧控制）——先确认这一点，然后我会针对 8.3 ms 的帧预算重新跑一遍评测。
- ClaudeApp 下午2:59
关于 120 Hz 机器的进展：成功了。在 headless Chrome 中通过 DevTools 的 begin-frame 控制实现确定性的 120 Hz 帧步进——240 个 begin-frame 正好对应 240 帧，每帧 8.33 ms，所以“这一帧是否满足 120 Hz 的预算”变成了一个精确读数，而不是有噪声的读数。
- Raymond下午3:05
太厉害了
绝了
机制和目标确定后，Claude 就开始动手了。每个绘制帧的预算只有 8.33 毫秒，于是 Claude 逐帧梳理一段长回复一帧一帧地，为每一帧计时，找出慢的部分。它通过记忆化已完成的块，消除了每个分块中的 O(message length) 工作，把不断增长的代码围栏的 tokenization 逻辑移到了 worker 中，并逐格渲染表格。
在那一个线程中，我们合并了近六十个 PR。长回复对主线程的阻塞总时长从原来的约 750 毫秒降到了约 200 毫秒，CPU 占用降到约三分之一，并且在 120 Hz 的 MacBook 上从头到尾保持 120 fps。这台 120 Hz 的设备本身也变成了一项每夜运行的任务，由 Claude 负责监控性能回退。
现在，Claude 在网页端和桌面端上的长回答流式输出流畅度提升了约 4 倍。
我们重建了流式渲染器，使其只处理仍在变化的内容，因此在较慢的笔记本上，长回复的卡顿减少了 9 倍，最严重的一次冻结缩短了 4.5 倍，而在 120Hz 的 MacBook 上，它从头到尾都能保持 120fps。
— ClaudeDevs（@ClaudeDevs）2026 年 8 月 24 日
当我们开始这轮冲刺时，我们并没有计划去针对流式输出时帧与帧之间的毫秒数做爬山优化。但结果发现我们确实可以把它们数出来——而任何我们能数出来的东西，Claude 都能爬上去。
下一步
今天，claude.ai 和桌面应用的速度大约是 8 月初的 3 倍，而棘轮机制应当能让它们保持在这一水平。但我们还没做完：第 95 百分位、其他使用路径，以及超长对话仍有改进空间。在另一篇帖子中，我们还会写到这次冲刺期间把我们带到上游的一些支线任务，相关贡献已进入 Electron、Chromium、Node.js 等。
当我们在内部分享这些结果时，Issac 总结得最好：“哪怕六个月前，你也不可能说服我这是可能的。”我们预计会继续以这种方式工作，一次一个线程，无论规模多大。这个频道仍在继续。
感谢 Alfred Xing、Anthony Morris、Benjamin Pasero、Chase McCoy、Joshua N.、Luke Taylor、Marius Schulz 和 Shelley Vohr 的贡献。特别感谢 Boris Cherny 鼓励我们更加雄心勃勃。
This August, we made the core user experience of claude.ai and the Claude desktop app about 3x faster in a two-week sprint. Users had been telling us it was slow, and they were right. We ran everything from a single Slack channel, with Claude in every thread.
We focused on four journeys that make up 95% of user activity. At the 75th percentile, time to a typeable page on a fresh load of claude.ai went from 3.1 seconds to 0.55, starting a new Claude Code session went from 0.8 seconds to 0.3, and loading a Claude Cowork cloud session went from 2.6 seconds to 0.73. In aggregate, we estimate that saves tens of thousands of user-hours of waiting every day.
We used Claude Tag (beta), running an internal research model roughly comparable to Opus 5.5. Claude found bottlenecks, built benchmarks, shipped improvements, and watched every deploy. We steered by setting goals, making tradeoffs, and approving every change. With that approach, we merged more than three thousand changes without a single customer-facing incident or rollback. This post covers what we shipped, how we measured it, and the loop we built with Claude to do it safely.
THE BRIEF
Before the sprint, we created a Slack channel with the following standing instructions:
@Claude Your job is to facilitate all things related to the performance of the claude.ai website and desktop app. Your responsibilities include monitoring deploys for performance regressions, assessing the accuracy and comprehensiveness of existing telemetry, maintaining well-curated observability dashboards, proactively implementing solutions for observed issues and low-hanging fruit, proposing performance project opportunities, and communicating with your human teammates. […]
The ultimate goal for this channel is for you to become as autonomous as possible, but today we know that isn’t yet possible.
We asked Claude to analyze usage data through the Datadog MCP server. It identified the four highest-impact user journeys: launching the app, starting a conversation, loading an existing conversation, and sending a message. Between web and desktop, and across our products, those journeys came to thirteen distinct measurements. To establish baselines, we added instrumentation until they were directly comparable: each started with a user interaction, ended once the result was rendered, and disambiguated client and server work.
We kicked off the sprint with a list of about twenty hand-picked projects, each targeting a specific journey. Claude estimated the impact of each project in milliseconds, and we aggregated those estimates to set our targets for the sprint. Some of the projects were fairly large, but we thought we could probably achieve most of them within two weeks.
We hit twelve of the thirteen targets by day three.
The planned projects landed early. For faster launches, we baked a static composer into the HTML so users can type during React initialization, and precompiled a V8 code cache so the desktop shell’s main process doesn’t recompile from scratch. For faster navigations, we kept the composer mounted between conversations, prefetched sessions when the user hovered over them, and cut sidebar re-renders by 90%.
We had also left room for Claude to identify opportunities and propose new workstreams. Those workstreams quickly ramped into full projects of their own, which far exceeded our initial targets. So we set new targets, then looked for more things to measure:
@Claude we’ve ended up funding nearly every project in the original projects list and more. let’s do a refresh […] what have we not explored, what can we hill climb on, where is the most opportunity at this point? […] i am open to WACKY ideas
ANYTHING CAN BE HILL CLIMBED
From the start, we knew we wanted to iterate faster than our deploy cadence. Claude could work asynchronously for many hours, even overnight, and we wanted to let it validate its prototypes without waiting for field reads. To achieve that, we looked for other ways to measure performance in the lab.
Sam found the first lead:
- Sam12:34 PM
What can we do instead of wall-clock timing? Can we measure JS instruction counts for instance?
- ClaudeApp12:42 PM
Yes. For pure-JS hot paths, literal instruction counts: run the benchmark under Valgrind with
node --predictableand compare to a checked-in baseline — one run, no statistics needed.For browser paths there’s no instruction counting under Chromium, but there’s a ladder of other deterministic counts: React commits per interaction, function call counts from V8’s precise coverage, layout and style-recalc counts, DOM mutations. Which do you want first?
- Sam12:49 PM
Let’s explore valgrind +
Ir+--predictablein one thread and each of the browser/react benches in new threads. Ping me in all of them. You know what we want. Let’s go
Eleven minutes later, five threads were running, each focused on a different measurement: instruction counts, V8 call counts, React commits, style recalculations, and DOM mutations.
We treated every new benchmark with some skepticism. Each one had two jobs: first, a metric Claude could move in the lab; second, a guardrail in CI with a number that could only ratchet down. If a benchmark was flaky, or if it didn’t actually correlate with user latency, we threw it out rather than let Claude climb the wrong hill.
@Claude please prove that hill climbing against each of these can result in measurable wall clock perf wins. we’ll unship the benches for any candidates that cannot prove that
Wall-clock time is what users feel, but it’s noisy, and milliseconds are too flaky to use as a CI gate. Instruction counts were appealing because they were deterministic, but we still needed Claude to prove they tracked wall-clock time.
So we asked Claude to drive the count down on two hot paths: the routine that assembles a conversation’s message tree, and a scanner for status lines in Claude Code output. Claude profiled both with Valgrind and found that a quarter of the first path’s instructions were megamorphic dictionary lookups, resolving the same message ID three separate times.
An hour later it had cut instructions on both paths by 48% and 31%, and wall-clock time had dropped 78% and 44%. We checked in two new ratchets. From then on, any PR that raised the instruction counts of those paths failed CI, and a daily job lowered each ceiling whenever the count went down.
That led us to the central lesson of the sprint. With Claude, measuring something makes it tractable.
Measurement used to be step zero: you’d add a metric, wait for data to roll in, and only then start to understand the problem. With Claude, it’s step one of the climb. As soon as Claude had a number to beat, it could start optimizing. This meant the highest-leverage thing we could do was find more things to measure.
THE LOOP, THREAD BY THREAD
All of this ran in the same Slack channel, with multiple engineers and Claude jamming in every thread. From there, the sprint settled into a loop:
- Someone would open a thread about a slow stretch of a journey, often with a screenshot or recording.
- Claude would trace the flow, then find or build a benchmark that demonstrated the problem.
- Once it had a promising result in the lab, Claude would come back with a PR — often several, sized for risk and review, with anything user-visible behind a flag.
- After it shipped, Claude watched the deploy and read the field data.
- If performance improved, Claude locked in the win by ratcheting the benchmark down; if not, it turned the flag off and iterated.
- Then it went looking for the next slow spot in the same journey.
An example: someone shared a screen recording that showed sidebar rows popping in after the page loaded. Chat and Cowork rows resolved at different times, making the page feel janky. None of our existing monitors detected it. The closest we had was Cumulative Layout Shift, but each shift only scored about 0.008 — well within the good threshold of 0.1.
Issac had the idea to reference the underlying Layout Instability API directly. Claude created a telemetry event that mapped the sources of each layout-shift entry to a named region (e.g. sidebar, transcript) and phase (e.g. before first paint, after typeable). It added an integration test that opened the page with a populated sidebar, held the sidebar’s data until after first paint, and failed on any shift in any named region. Claude used that as a benchmark to prove a fix: the test went red 20 of 20 runs on main, and green 20 of 20 on the PR.
After the event deployed, Claude read the field data and found that 31% of web page loads moved something after the page was usable, without any user interaction. From there, Claude worked through the causes by name: a header row that arrived late, a caret that slid sideways once the user’s name loaded, a list that moved when the scrollbar popped in. Claude fixed the top offenders as a batch, and when they were gone, it found the next batch.
That was one thread. During the sprint, we ran more than a hundred and fifty at a time.
SCALING HORIZONTALLY
Once the loop worked on one thread, running it on more was just a matter of opening them. Instead of closing a thread once its original request had been fulfilled, Claude would keep going. An individual thread would put up fifty, sometimes a hundred, optimization PRs. Increasingly, it was Claude, not one of us, opening new threads to chase opportunities it had found on its own, as part of a separate investigation or nightly job. Shelley, one of the engineers in the channel, observed, “[This model] is a numbers demon.”
Every measurement found something to improve. Claude ran a React hook census and found 6,900 hooks and 900 store subscriptions in the composer’s typing path, re-rendering on every keystroke. Claude counted style recalculations and found a single :root:has() selector adding 24 milliseconds to every DOM change. Claude traced code paths after first paint and found a leftover location.reload() causing half a million hidden reloads a day that none of our load metrics could see. Claude read profiler samples from idle tabs and found identical cache snapshots being cloned into IndexedDB twice a minute, all on the main thread.
We rarely knew where a thread would lead. In a sweep for CPU hitches, Claude noticed that highlighting a finished code block could freeze the page for about a second. It dug in the lab and found the culprit: em dashes. If a reply’s markdown contained any non-Latin-1 character, like an em dash or a curly quote, V8 stored the entire string as UTF-16, which put every syntax-highlighting regex on its slower two-byte path. Claude fixed it with a twenty-line change to copy each code block into a one-byte string before highlighting it.
By the second week, we could barely summarize our output into daily updates. On the busiest days, more than two hundred changes landed. Claude kept proposing new benchmarks; about a third of PRs included additional telemetry or guardrails, and each new instrument generated more threads with more opportunities.
Working in one channel meant everything happened in the open. We jumped in and out of each other’s threads to debate decisions and celebrate wins. Word spread: other teams started bringing their changes into the channel to have them reviewed for performance. New projects were written in subtly more performant ways because of all the guardrails and Claude skills that had been introduced.
GUARDRAILS
We’d prepared for the pace. Because nearly everything we touched was a hot path (the first paint, the composer, the transcript), we’d established our safety mechanisms up front. Every PR went through automated review with at least one human approval, unit tests always came before optimizations, and anything that could cause a user-visible problem shipped behind a short-lived feature flag.
When the flags started piling up, we opened a thread to coordinate their rollouts and cleanup. Claude classified every flag as a kill switch or ramp, and retired each one as soon as it was safe. Across the two weeks, we introduced nearly two hundred flags, more than half of which were already cleaned up by the end.
We also knew that performance wins decay in a fast-moving codebase, and code ships fast at Anthropic. Once a project proved a win, we invested in ways to protect it. The static composer, for example, is brittle by design. We show users an HTML copy of the page almost immediately, and let React paint directly on top of it.
If the React render is off by even a pixel, the magic is lost. So Claude built dozens of guardrails:
- The static markup is generated by rendering the real React component in jsdom, and a test guarantees they never drift.
- An integration test suite compares the static page against the React render across fourteen viewport sizes, and asserts alignment within 1 px.
- A keystroke test types straight through the handoff and fails on any lost or reordered key.
- In the field, every handoff reports shifts to a tenth of a pixel. Claude opens a thread for any event with nonzero movement.
Not everything could be caught in the lab, so we also made use of the oldest guardrail in the book: incremental rollouts. High-risk changes were rolled out to employees first, then one percent of users, then everyone. Four hours after we released the static composer internally, a teammate shared a screen recording of a layout shift that none of our metrics could see. When he opened claude.ai in a new tab, the composer would drop — but it wasn’t our code.
- Marius6:15 PM
Occasionally, I’m seeing a small-ish (maybe 15–20px) vertical layout shift (pushing the composer box down) when opening claude.ai in a new tab (not so much when reloading the page). I can’t quite pin down what exactly causes that, but it’s there
Screen recording · 0:02 - ClaudeApp7:05 PM
Found it in your recording — it’s Chrome resizing the page, not the handoff from the static composer to the real one (that measured 0 px on all 49 of your loads today).
- On the new-tab page, Chrome draws its own 56 px footer below the page (“Managed by anthropic.com · Customize Chrome”). When the tab navigates to claude.ai the footer goes away and the page gets 56 px taller, but only ~100 ms after our first paint.
- /new puts the greeting and composer 18% of the page height from the top, so they drop 0.18 × 56 ≈ 10 px (your video measures 10). A reload has no footer to remove, hence new-tab only; “occasionally” is whether first paint beats the resize.
- It’s only “occasional” because it needs Chrome to pre-render the page from the address bar while you’re still on the new-tab page: the hidden page is laid out at the shorter height and only resized after it’s shown.
- This was always latent; the page just never painted that early before. Our layout tests can’t see it because headless Chrome has no browser UI to retract, and the placeholder and the app move together.
Somehow, Claude traced it to an edge case in Chrome’s speculative loading. While a user was typing the URL into the address bar, Chrome would prerender the page in the background, at the height of the current tab. On browsers managed by an organization, the new-tab page is slightly shorter because of a footer. When the user pressed Enter, the first frame of claude.ai showed that slightly shorter layout, and Chrome resized it about a tenth of a second later. Claude pinned the layout across the resize, and we added a test to simulate the prerender flow.
STEERING
The loop was productive, but it wasn’t autonomous. Keeping it fast, safe, and on track was our job, and it had three parts.
Ambition. By default, Claude is careful about scope. It tickets findings, hedges on feasibility, and pads its estimates. But we were confident in our guardrails. A lot of what we did, especially early on, was to encourage Claude to be bolder.
- ClaudeApp3:32 PM
Yes — one small PR to give Code the same timing marks Chat and Cowork already have. I’ll put it up this week; realistically Code’s number waits a few days for merge, deploy, and a baseline window.
- Raymond3:32 PM
if you put it up right now I will get it merged and deployed. we have the power to do anything. please be braver
- ClaudeApp3:33 PM
On it — the PR will be up within the hour.
When we started hitting the targets we’d set, we noticed that threads would slow down. Sam went thread to thread with the same message: “Let’s keep driving this down, the targets are not the stopping point. What’s next? Be ambitious.”
Taste. Every thread had a named human owner, and Claude highlighted any user-perceptible change with before-and-after screenshots or recordings for them to rule on. Should a table fill in cell by cell, or wait until each row is complete? Should a loading skeleton show up immediately, or only after half a second? Is a word-by-word fade on streamed text worth the fifth of the frame budget it costs? Claude looked for ways to shave milliseconds, and we weighed the tradeoffs.
Direction. We kept each thread deliberately narrow, focused on one benchmark or journey, and asked Claude to find improvements only within that scope. We thought of the threads as a hundred and fifty hammers seeking nails. Most of our calls were about sequencing and user impact: which surfaces to prioritize, how to combine threads that were stepping on each other, and when to close a thread that had reached diminishing returns. One 900-line PR got a one-line reply: “going to gavel that 2ms per send is not worth the complexity of maintaining this build plugin.”
AN 8-MILLISECOND BUDGET
One of our sidequests shows everything working together. To demonstrate an optimization to a regex used in live syntax highlighting, Claude attached a screen recording of a long answer streaming in the lab. In the corner, it had added a frame-rate readout, computed in the page from animation-frame timestamps.
- Raymond2:33 PM
this is actually kind of a sick bench. are we capped at 60 fps? can you try to drive scroll and stream smoothness to 120? iiuc your rig may not support this
- ClaudeApp2:34 PM
Right, today’s rig ticks at 60 Hz because headless Chromium does by default. I believe it can be driven at 120 (uncapped vsync or DevTools frame control) — confirming that first, then I’ll re-run the eval against an 8.3 ms frame budget.
- ClaudeApp2:59 PM
Update on the 120 Hz rig: it works. Deterministic 120 Hz frame stepping in headless Chrome via DevTools begin-frame control — exactly 240 frames for 240 begin-frames at 8.33 ms, so “did this frame fit the 120 Hz budget” becomes an exact read rather than a noisy one.
- Raymond3:05 PM
amazing
cook
Once the mechanism and ambition were established, Claude got to work. Each painted frame had a budget of 8.33 milliseconds, so Claude stepped through a long reply frame by frame, timing each one to find the slow parts. It eliminated O(message length) work per chunk by memoizing finished blocks, moved tokenization logic for growing code fences to a worker, and revealed tables cell by cell.
In that one thread, we landed nearly sixty PRs. Long replies blocked the main thread for about 200 milliseconds in total where they used to block it for about 750, ran on about a third of the CPU, and held 120 fps from start to finish on a 120 Hz MacBook. The 120 Hz rig itself became a nightly job, with Claude watching for regressions.
Long answers on Claude on web and desktop now stream ~4x smoother.
We rebuilt the streaming renderer to only touch what’s still changing, so a long reply stalls 9x less on a slower laptop, its worst freeze is 4.5x shorter, and on a 120Hz MacBook it holds 120fps start to finish.
— ClaudeDevs (@ClaudeDevs) Aug 24, 2026
When we started the sprint, we hadn’t planned to hill climb on the milliseconds between frames while streaming. But it turned out we could count them — and anything we could count, Claude could climb.
WHAT’S NEXT
Today, claude.ai and the desktop app are about 3x faster than they were in early August, and the ratchets should keep them there. But we’re not done: the 95th percentile, other journeys, and very long conversations still have room to improve. In a separate post, we’ll also write about some of the sidequests that took us upstream during the sprint, with contributions landing in Electron, Chromium, Node.js, and more.
When we shared the results internally, Issac put it best: “You could not have convinced me this was possible even six months ago.” We expect to keep working this way, one thread at a time, at any scale. The channel’s still going.
With contributions from Alfred Xing, Anthony Morris, Benjamin Pasero, Chase McCoy, Joshua N., Luke Taylor, Marius Schulz, and Shelley Vohr. Special thanks to Boris Cherny for encouraging us to be more ambitious.