An update on recent Claude Code quality reports

За последний месяц мы разбирались с сообщениями о том, что ответы Claude стали хуже для части пользователей. Мы свели эти сообщения к трём отдельным изменениям, которые затронули Claude Code, Claude Agent SDK и Claude Cowork. API затронут не был.

Все три проблемы теперь устранены — по состоянию на 20 апреля (v2.1.116).

В этом посте мы рассказываем, что мы обнаружили, что исправили и что будем делать иначе, чтобы вероятность подобных проблем в будущем была существенно ниже.

Мы очень серьёзно относимся к сообщениям о деградации. Мы никогда не ухудшаем наши модели намеренно и сразу смогли подтвердить, что наш API и слой инференса не затронуты.

После расследования мы выявили три разные проблемы:

4 марта мы изменили дефолтный reasoning effort в Claude Code с high на medium, чтобы уменьшить очень большие задержки — настолько долгие, что UI казался зависшим, — которые часть пользователей наблюдала в режиме high. Это был неверный компромисс. Мы откатили это изменение 7 апреля, после того как пользователи сказали нам, что предпочли бы дефолт с более высоким интеллектом и возможность вручную переключаться на меньший effort для простых задач. Затронуты Sonnet 4.6 и Opus 4.6. 26 марта мы выкатили изменение, которое очищало старые размышления Claude из сессий, простаивавших более часа, чтобы уменьшить задержку при возобновлении таких сессий. Из-за бага это срабатывало на каждом ходу до конца сессии, а не один раз, из-за чего Claude казался забывчивым и повторяющимся. Мы исправили это 10 апреля. Затронуты Sonnet 4.6 и Opus 4.6. 16 апреля мы добавили в системный промпт инструкцию для уменьшения многословия. В сочетании с другими изменениями промпта это ухудшило качество кодинга и было откачено 20 апреля. Затронуты Sonnet 4.6, Opus 4.6 и Opus 4.7.

Поскольку каждое изменение затрагивало свой срез трафика и происходило по своему графику, совокупный эффект выглядел как широкая и непоследовательная деградация. Хотя мы начали разбирать сообщения ещё в начале марта, поначалу их было сложно отличить от обычной вариативности в пользовательских отзывах, и ни наше внутреннее использование, ни эвалы изначально не воспроизводили выявленные проблемы.

Это не тот опыт, которого пользователи должны ожидать от Claude Code. С 23 апреля мы сбрасываем лимиты использования для всех подписчиков.

Изменение дефолтного reasoning effort в Claude Code

Когда в феврале мы выпустили Opus 4.6 в Claude Code, мы установили дефолтный reasoning effort на high.

Вскоре мы получили отзывы пользователей, что Claude Opus 4.6 в режиме high effort иногда думает слишком долго, из-за чего UI кажется зависшим и возникают непропорциональные задержки и расход токенов для этих пользователей.

В целом, чем дольше модель думает, тем лучше результат. Уровни effort — это способ, которым Claude Code позволяет пользователю настраивать этот компромисс: больше размышлений против меньшей задержки и меньшего числа упираний в лимиты. При калибровке уровней effort для наших моделей мы учитываем этот компромисс, чтобы выбрать точки на кривой test-time-compute, которые дают людям наилучший диапазон опций. В продуктовом слое мы затем выбираем, какую точку на этой кривой сделать дефолтом — именно это значение мы отправляем в Messages API как параметр effort; остальные варианты мы делаем доступными через /effort.

В наших внутренних эвалах и тестах medium effort давал немного меньший интеллект, но значительно меньшую задержку для большинства задач. Он также не страдал от случайных очень длинных хвостовых задержек при размышлении и помогал максимизировать пользовательские лимиты. В результате мы выкатили изменение, сделав medium дефолтным значением effort, и объяснили причину через внутрипродуктовый диалог.

Вскоре после раскатки пользователи стали сообщать, что Claude Code ощущается менее интеллектуальным. Мы выпустили несколько дизайнерских итераций, чтобы сделать текущую настройку effort более явной и подсказать людям, что дефолт можно изменить (уведомления при запуске, инлайновый селектор effort и возвращение ultrathink), но большинство пользователей оставались на medium по умолчанию.

После получения отзывов от большего числа клиентов мы отменили это решение 7 апреля. Теперь у всех пользователей по умолчанию xhigh effort для Opus 4.7 и high effort для всех остальных моделей.

Оптимизация кеширования, которая отбрасывала предыдущие рассуждения

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

26 марта мы выкатили то, что задумывалось как улучшение эффективности этой функции. Мы используем prompt caching, чтобы сделать последовательные API-вызовы дешевле и быстрее для пользователей. Claude записывает входные токены в кеш при API-запросе, а затем после периода неактивности промпт вытесняется из кеша, освобождая место для других промптов. Использованием кеша мы управляем тщательно (подробнее о нашем подходе).

Дизайн должен был быть простым: если сессия простаивает больше часа, мы могли бы снизить пользователю стоимость её возобновления, очистив старые секции рассуждений. Поскольку запрос всё равно был бы cache miss, мы могли убрать из него ненужные сообщения, чтобы уменьшить число некешированных токенов, отправляемых в API. Затем мы возобновили бы отправку полной истории рассуждений. Для этого мы использовали API-заголовок clear_thinking_20251015 вместе с keep:1.

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

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

Воспроизвести проблему нам поначалу мешали два не связанных между собой эксперимента: внутренний серверный эксперимент по очередям сообщений и ортогональное изменение в том, как мы отображаем размышления, которое подавляло этот баг в большинстве CLI-сессий, — поэтому мы не поймали его даже при тестировании внешних сборок.

Этот баг находился на пересечении управления контекстом в Claude Code, Anthropic API и расширенного мышления. Внесённые им изменения прошли несколько ручных и автоматизированных код-ревью, а также юнит-тесты, end-to-end тесты, автоматизированную верификацию и догфудинг. В сочетании с тем, что это происходило только в краевом случае (несвежие сессии), и сложностью воспроизведения нам понадобилось больше недели, чтобы обнаружить и подтвердить корневую причину.

В рамках расследования мы прогнали Code Review по проблемным pull request'ам с использованием Opus 4.7. Когда ему предоставили репозитории кода, необходимые для сбора полного контекста, Opus 4.7 нашёл баг, а Opus 4.6 — нет. Чтобы предотвратить повторение, мы сейчас добавляем поддержку дополнительных репозиториев в качестве контекста для код-ревью.

Мы исправили этот баг 10 апреля в v2.1.101.

Изменение системного промпта для уменьшения многословия

У нашей последней модели, Claude Opus 4.7, есть заметная поведенческая особенность по сравнению с предшественником: как мы писали на запуске, она склонна быть довольно многословной. Это делает её умнее на сложных задачах, но также увеличивает число выходных токенов.

За несколько недель до выпуска Opus 4.7 мы начали тюнить Claude Code в рамках подготовки. Каждая модель ведёт себя немного по-разному, и перед каждым релизом мы тратим время на оптимизацию harness и продукта под неё.

У нас есть набор инструментов для уменьшения многословия: обучение модели, prompting и улучшение UX размышлений в продукте. В итоге мы использовали все эти инструменты, но одно дополнение к системному промпту дало непропорциональный эффект на интеллект в Claude Code:

«Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.»

После нескольких недель внутреннего тестирования и отсутствия регрессий в наборе эвалов, которые мы прогоняли, мы были уверены в этом изменении и выпустили его вместе с Opus 4.7 16 апреля.

В рамках расследования мы прогнали больше ablation-тестов (удаляя строки из системного промпта, чтобы понять влияние каждой строки) на более широком наборе эвалов. Один из этих эвалов показал падение на 3% как для Opus 4.6, так и для 4.7. Мы немедленно откатили промпт в релизе 20 апреля.

Что дальше

Чтобы избежать таких проблем в будущем, мы будем делать ряд вещей иначе: обеспечим, чтобы большая доля внутренних сотрудников использовала именно публичную сборку Claude Code (а не ту версию, которую мы используем для тестирования новых функций); внесём улучшения в наш инструмент Code Review, которым пользуемся внутри компании, и выкатим эту улучшенную версию клиентам.

Мы также вводим более жёсткий контроль изменений системного промпта. Мы будем прогонять широкий набор per-model эвалов для каждого изменения системного промпта в Claude Code, продолжая ablation-тесты для понимания вклада каждой строки, и мы построили новый инструментарий, чтобы изменения промпта было легче ревьюить и аудировать. Кроме того, мы добавили рекомендации в наш CLAUDE.md, чтобы model-specific изменения были привязаны именно к той модели, на которую они нацелены. Для любого изменения, которое потенциально может повлиять на интеллект, мы добавим soak-периоды, более широкий набор эвалов и постепенные раскатки, чтобы ловить проблемы раньше.

Недавно мы создали @ClaudeDevs в X, чтобы у нас было пространство подробно объяснять продуктовые решения и логику за ними. Те же обновления мы будем публиковать в централизованных тредах на GitHub.

Наконец, мы хотим поблагодарить наших пользователей: именно люди, использовавшие команду /feedback, чтобы рассказать нам о проблемах (или публиковавшие конкретные воспроизводимые примеры онлайн), и позволили нам в итоге выявить и исправить эти проблемы. Сегодня мы сбрасываем лимиты использования для всех подписчиков.

Мы безмерно благодарны вам за обратную связь и за терпение.