An update on recent Claude Code quality reports

Over the past month, we’ve been looking into reports that Claude’s responses have worsened for some users. We’ve traced these reports to three separate changes that affected Claude Code, the Claude Agent SDK, and Claude Cowork. The API was not impacted.

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

All three issues have now been resolved as of April 20 (v2.1.116).

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

In this post, we explain what we found, what we fixed, and what we’ll do differently to ensure similar issues are much less likely to happen again.

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

We take reports about degradation very seriously. We never intentionally degrade our models, and we were able to immediately confirm that our API and inference layer were unaffected.

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

After investigation, we identified three different issues:

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

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.

Because each change affected a different slice of traffic on a different schedule, the aggregate effect looked like broad, inconsistent degradation. While we began investigating reports in early March, they were challenging to distinguish from normal variation in user feedback at first, and neither our internal usage nor evals initially reproduced the issues identified.

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

This isn’t the experience users should expect from Claude Code. As of April 23, we’re resetting usage limits for all subscribers.

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

A change to Claude Code's default reasoning effort

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

When we released Opus 4.6 in Claude Code in February, we set the default reasoning effort to high.

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

Soon after, we received user feedback that Claude Opus 4.6 in high effort mode would occasionally think for too long, causing the UI to appear frozen and leading to disproportionate latency and token usage for those users.

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

In general, the longer the model thinks, the better the output. Effort levels are how Claude Code lets users set that tradeoff—more thinking versus lower latency and fewer usage limit hits. As we calibrate effort levels for our models, we take this tradeoff into account in order to pick points along the test-time-compute curve that give people the best range of options. In the product layer, we then choose which point along this curve we set as our default, and that is the value we send to the Messages API as the effort parameter; we then make the other options available via /effort.

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

In our internal evals and testing, medium effort achieved slightly lower intelligence with significantly less latency for the majority of tasks. It also didn’t suffer from the same issues with occasional very long tail latencies for thinking, and it helped maximize users’ usage limits. As a result, we rolled out a change making medium the default effort, and explained the rationale via in-product dialog.

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

Soon after rolling out, users began reporting that Claude Code felt less intelligent. We shipped a number of design iterations to make the current effort setting clearer in order to alert people they could change the default (notices on startup, an inline effort selector, and bringing back ultrathink), but most users retained the medium effort default.

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

After hearing feedback from more customers, we reversed this decision on April 7. All users now default to xhigh effort for Opus 4.7, and high effort for all other models.

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

A caching optimization that dropped prior reasoning

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

When Claude reasons through a task, that reasoning is normally kept in the conversation history so that on every subsequent turn, Claude can see why it made the edits and tool calls it did.

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

On March 26, we shipped what was meant to be an efficiency improvement to this feature. We use prompt caching to make back-to-back API calls cheaper and faster for users. Claude writes the input tokens to the cache when it makes an API request, then after a period of inactivity the prompt is evicted from cache, making room for other prompts. Cache utilization is something we manage carefully (more on our approach).

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

The design should have been simple: if a session has been idle for more than an hour, we could reduce users’ cost of resuming that session by clearing old thinking sections. Since the request would be a cache miss anyway, we could prune unnecessary messages from the request to reduce the number of uncached tokens sent to the API. We’d then resume sending full reasoning history. To do this we used the clear_thinking_20251015 API header along with keep:1.

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

The implementation had a bug. Instead of clearing thinking history once, it cleared it on every turn for the rest of the session. After a session crossed the idle threshold once, each request for the rest of that process told the API to keep only the most recent block of reasoning and discard everything before it. This compounded: if you sent a follow-up message while Claude was in the middle of a tool use, that started a new turn under the broken flag, so even the reasoning from the current turn was dropped. Claude would continue executing, but increasingly without memory of why it had chosen to do what it was doing. This surfaced as the forgetfulness, repetition, and odd tool choices people reported.

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

Because this would continuously drop thinking blocks from subsequent requests, those requests also resulted in cache misses. We believe this is what drove the separate reports of usage limits draining faster than expected.

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

Two unrelated experiments made it challenging for us to reproduce the issue at first: an internal-only server-side experiment related to message queuing; and an orthogonal change in how we display thinking suppressed this bug in most CLI sessions, so we didn’t catch it even when testing external builds.

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

This bug was at the intersection of Claude Code’s context management, the Anthropic API, and extended thinking. The changes it introduced made it past multiple human and automated code reviews, as well as unit tests, end-to-end tests, automated verification, and dogfooding. Combined with this only happening in a corner case (stale sessions) and the difficulty of reproducing the issue, it took us over a week to discover and confirm the root cause.

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

As part of the investigation, we back-tested Code Review against the offending pull requests using Opus 4.7. When provided the code repositories necessary to gather complete context, Opus 4.7 found the bug, while Opus 4.6 didn't. To prevent this from happening again, we are now landing support for additional repositories as context for code reviews.

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

We fixed this bug on April 10 in v2.1.101.

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

A system prompt change to reduce verbosity

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

Our latest model, Claude Opus 4.7, has a notable behavioral quirk relative to its predecessor: as we wrote about at launch, it tends to be quite verbose. This makes it smarter on hard problems, but it also produces more output tokens.

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

A few weeks before we released Opus 4.7, we started tuning Claude Code in preparation. Each model behaves slightly differently, and we spend time before each release optimizing the harness and product for it.

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

We have a number of tools to reduce verbosity: model training, prompting, and improving thinking UX in the product. Ultimately we used all of these, but one addition to the system prompt caused an outsized effect on intelligence in Claude Code:

У нас есть набор инструментов для уменьшения многословия: обучение модели, 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.”

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

After multiple weeks of internal testing and no regressions in the set of evaluations we ran, we felt confident about the change and shipped it alongside Opus 4.7 on April 16.

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

As part of this investigation, we ran more ablations (removing lines from the system prompt to understand the impact of each line) using a broader set of evaluations. One of these evaluations showed a 3% drop for both Opus 4.6 and 4.7. We immediately reverted the prompt as part of the April 20 release.

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

Going forward

Что дальше

We are going to do several things differently to avoid these issues: we’ll ensure that a larger share of internal staff use the exact public build of Claude Code (as opposed to the version we use to test new features); and we'll make improvements to our Code Review tool that we use internally, and ship this improved version to customers.

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

We’re also adding tighter controls on system prompt changes. We will run a broad suite of per-model evals for every system prompt change to Claude Code, continuing ablations to understand the impact of each line, and we have built new tooling to make prompt changes easier to review and audit. We've additionally added guidance to our CLAUDE.md to ensure model-specific changes are gated to the specific model they're targeting. For any change that could trade off against intelligence, we'll add soak periods, a broader eval suite, and gradual rollouts so we catch issues earlier.

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

We recently created @ClaudeDevs on X to give us the room to explain product decisions and the reasoning behind them in depth. We'll share the same updates in centralized threads on GitHub.

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

Finally, we’d like to thank our users: the people who used the /feedback command to share their issues with us (or who posted specific, reproducible examples online) are the ones who ultimately allowed us to identify and fix these problems. Today we are resetting usage limits for all subscribers.

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

We’re immensely grateful for your feedback and for your patience.

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