Anthropic ускорила Claude.ai в три раза за двухнедельный спринт

Anthropic за две недели ускорила основной пользовательский опыт claude.ai и десктопного приложения Claude примерно в 3 раза. Об этом компания рассказала в блоге. Пользователи жаловались на медленную работу, и в Anthropic признали, что жалобы были справедливы.

Спринт затронул четыре сценария, которые составляют 95% активности пользователей: запуск приложения, начало разговора, загрузка существующего диалога и отправка сообщения. На 75-м перцентиле время до появления возможности печатать на свежей загрузке claude.ai сократилось с 3,1 до 0,55 секунды. Запуск новой сессии Claude Code ускорился с 0,8 до 0,3 секунды, а загрузка облачной сессии Claude Cowork — с 2,6 до 0,73 секунды. В совокупности это экономит, по оценке компании, десятки тысяч пользовательских часов ожидания ежедневно.

Как работали

Всё управлялось из одного канала в Slack, где в каждой ветке участвовал Claude. Использовалась внутренняя исследовательская модель Claude Tag (бета), примерно сопоставимая с Opus 5.5. Claude находил узкие места, строил бенчмарки, вносил улучшения и следил за каждым деплоем. Люди задавали цели, принимали компромиссные решения и утверждали каждое изменение.

Перед спринтом в канале закрепили инструкцию для Claude: следить за регрессиями производительности при деплоях, оценивать телеметрию, вести дашборды, предлагать решения и общаться с командой. Через Datadog MCP Claude проанализировал данные об использовании и определил четыре самых важных сценария. Между вебом и десктопом, а также между продуктами эти сценарии дали тринадцать отдельных измерений. Чтобы установить базовые значения, команда добавила инструментацию до состояния прямой сопоставимости: каждое измерение начиналось с действия пользователя, заканчивалось отрисовкой результата и разделяло работу клиента и сервера.

Спринт начали с примерно двадцати отобранных вручную проектов, каждый нацелен на конкретный сценарий. Claude оценил влияние каждого проекта в миллисекундах, и эти оценки агрегировали в целевые показатели. Двенадцать из тринадцати целей были достигнуты к третьему дню.

Что именно ускорили

Для быстрой загрузки статический composer встроили прямо в HTML, чтобы пользователь мог печатать во время инициализации React, а также предварительно скомпилировали кэш кода V8, чтобы главный процесс десктопной оболочки не компилировал всё заново. Для ускорения навигации composer оставили смонтированным между разговорами, сессии предзагружались при наведении курсора, а количество повторных рендеров боковой панели сократили на 90%.

Команда также оставила место для инициатив самого Claude. Эти направления быстро выросли в полноценные проекты, которые превысили первоначальные цели. После этого поставили новые цели и занялись поиском новых метрик.

Измерения вместо ожидания

С самого начала команда хотела итерировать быстрее, чем происходит деплой. Claude мог работать асинхронно много часов, в том числе ночью, и нужно было дать ему возможность проверять прототипы без ожидания полевых данных. Для этого искали другие способы измерять производительность в лаборатории.

Первым шагом стало измерение количества инструкций JavaScript. Для чистых JS-путей это буквальный подсчёт инструкций: запуск бенчмарка под Valgrind с node --predictable и сравнение с зафиксированным базовым значением. Для браузерных путей подсчёта инструкций в Chromium нет, но есть другие детерминированные метрики: количество коммитов React за взаимодействие, число вызовов функций из точного покрытия V8, количество пересчётов стилей и мутаций DOM.

Через одиннадцать минут после обсуждения уже работали пять потоков, каждый со своей метрикой. Каждый новый бенчмарк проверяли на скептицизм: он должен был давать метрику, которую Claude может двигать в лаборатории, и служить ограничителем в CI, значение которого может только снижаться. Если бенчмарк оказывался нестабильным или не коррелировал с задержкой у пользователя, его отбрасывали.

Wall-clock время — то, что чувствует пользователь, но оно шумное, и миллисекунды слишком нестабильны для CI-гейта. Количество инструкций было привлекательным из-за детерминированности, но требовалось доказать, что оно отслеживает реальное время. Claude попросили снизить счётчик на двух горячих путях: в процедуре сборки дерева сообщений разговора и в сканере строк состояния в выводе Claude Code. Профилирование под Valgrind показало, что четверть инструкций первого пути — это мегаморфные словарные обращения, трижды разрешающие один и тот же ID сообщения. Через час количество инструкций на обоих путях сократилось на 48% и 31%, а wall-clock время — на 78% и 44%. После этого любой PR, повышающий счётчик инструкций на этих путях, стал проваливать CI, а ежедневная задача снижала потолок при каждом улучшении.

Главный вывод спринта: с Claude измерение делает задачу решаемой. Раньше измерение было нулевым шагом — сначала добавить метрику, дождаться данных, и только потом разбираться в проблеме. Теперь это первый шаг восхождения. Как только у Claude появляется число, которое нужно побить, он может начинать оптимизацию. Поэтому самое эффективное — искать всё новые вещи для измерения.