Три бага в Claude Code: почему ИИ "глупел" и как Anthropic это исправила
Anthropic официально признала: ухудшение качества ответов в Claude Code в марте-апреле было вызвано не моделью, а ошибками в обвязке CLI. Внутренние языковые модели работали корректно, но три бага в harness - слое, который подготавливает контекст перед отправкой в Messages API, - по-разному ломали поведение Claude.
К 20 апреля все проблемы исправили в релизе Claude Code v2.1.116, а 23 апреля подписчикам обнулили usage limits, компенсируя лишние траты. Если вы работаете через CLI - в первую очередь стоит проверить версию клиента.
Где жили баги и почему их не увидели сразу
Anthropic отдельно подчёркивает:
- сами модели они сознательно не деградируют;
- инфраструктура инференса и API прошла внеочередную проверку и оказалась чистой;
- все три бага были исключительно в harness-уровне Claude Code.
Ошибки раскатились на разных пользователей в разные даты, поэтому снаружи всё выглядело как "рандомная тупость" Claude: в одних задачах он блестяще справлялся, в других - начинал путаться, забывать контекст, выдавать поверхностные ответы.
Внутренние сотрудники и автоматические evals сначала проблему почти не воспроизводили:
- часть сценариев не попадала в те самые corner-кейсы;
- шум в качестве сложно было отличить от естественной статистической вариативности.
Первые внятные сигналы о деградации качества начали поступать в начале марта, но связать всё воедино и воспроизвести ошибку системно удалось лишь спустя больше недели.
---
Баг №1: понижение reasoning effort по умолчанию
Когда в феврале в Claude Code завезли Opus 4.6, режим по умолчанию для него был выставлен на high reasoning effort. Это значит, что модель тратит больше вычислительных ресурсов и токенов на внутренние рассуждения, выдавая более продуманные решения сложных задач.
Однако довольно быстро начали появляться жалобы:
- CLI "подвисает", пока модель "думает";
- токены и лимиты тратятся заметно быстрее;
- для быстрой работы с простыми задачами это казалось избыточным.
4 марта Anthropic решила пойти на компромисс и перевела дефолтный режим с high на medium. По внутренним metrikaм:
- качество reasoning падало лишь немного;
- задержка и расход лимитов становились более предсказуемыми.
Позже в компании признали этот компромисс стратегически неверным: для большинства пользователей важнее максимальное качество ответа "из коробки", а не экономия токенов. Удобнее, чтобы полный reasoning был включён по умолчанию, а снижать effort через `/effort` или аналогичные настройки - уже под задачи, где оправдана скорость и экономия.
7 апреля решение откатили:
- Opus 4.7 теперь работает по умолчанию в режиме xhigh (внутреннее обозначение - "extra high");
- остальные модели вернули на high.
Эта ошибка затронула пользователей Sonnet 4.6 и Opus 4.6, которые в марте могли ощущать, что Claude стал "чуть глупее" и менее глубок в анализе, хотя сами модели не менялись.
---
Баг №2: кэш-оптимизация, которая стирала thinking-блоки
Второй баг оказался самым коварным и сложным для отладки. Он был связан с тем, как Claude Code управляет историей рассуждений (thinking / reasoning blocks) внутри сессии.
Когда модель решает сложную задачу, она не только отвечает пользователю, но и ведёт внутренний лог рассуждений. Эта информация сохраняется в истории сессии и нужна затем, чтобы:
- помнить, зачем выполнялись предыдущие шаги;
- корректно продолжать цепочку инструментальных вызовов;
- не терять нить в длинных многошаговых задачах.
26 марта разработчики выкатили оптимизацию:
- если сессия простаивает больше часа без активности,
- при возобновлении можно один раз выкинуть старые thinking-блоки,
- потому что всё равно будет cache miss по prompt cache, и префикс придётся отправлять заново.
Реализация опиралась на API-хедер `clear_thinking_20251015` в связке с `keep:1` - то есть нужно было сохранить только один последний блок reasoning, а остальное сбросить при первом же продолжении старой сессии.
Баг заключался в логике применения:
- очистка должна была происходить один раз при пробуждении "застоявшейся" сессии;
- на деле флаг срабатывал на каждом последующем запросе до конца процесса.
Фактически каждый новый запрос говорил API:
> "Сохрани только самый последний блок reasoning, всё остальное выкинь".
Ситуацию усугублял ещё один сценарий:
- если пользователь отправлял follow-up прямо во время вызова инструмента,
- это порождало новый ход с уже сломанным флагом,
- и в результате могли выбрасываться даже рассуждения текущего шага.
Claude продолжал что-то делать, но всё хуже помнил:
- зачем начал задачу;
- какие были предыдущие предположения;
- какие инструменты он уже вызывал и почему.
Снаружи это выглядело так:
- модель повторяет уже сказанное;
- внезапно забывает детали, обсуждавшиеся несколько шагов назад;
- делает странный выбор инструментов;
- сбивается в многошаговых задачах.
Дополнительный побочный эффект - постоянные cache miss:
- контекст приходилось переотправлять;
- это ускоряло расход usage limits;
- отсюда пошла волна жалоб в духе "лимиты тают быстрее обычного".
Почему тесты и ревью не поймали баг сразу
Этот баг прошёл через всё:
- несколько человеческих code review;
- автоматические code review;
- unit-тесты;
- end-to-end тесты;
- автоматическую верификацию;
- внутреннее использование разработчиками.
Anthropic объясняет, что его маскировали два не связанных между собой эксперимента:
1. Внутренний серверный тест очередей сообщений.
2. Поправки в отображении thinking-блоков для сотрудников.
В результате в CLI-сценариях, которыми пользовались сами разработчики, некорректное поведение выглядело сглаженным и неявным. Баг проявлялся только на стыке трёх слоёв:
- контекст-менеджмента в Claude Code;
- Anthropic API;
- режима extended thinking.
Критичный corner-кейс - возобновление устаревшей сессии с пересечением по времени с инструментальными вызовами. Воспроизведение этой точной комбинации заняло больше недели.
Как Anthropic использовала ИИ для поиска собственного бага
Во время разбора инцидента компания задействовала внутренний инструмент Code Review, который сам ревьюит код с помощью Claude. На проблемные pull request-ы с багом запустили анализ:
- сначала с Opus 4.7;
- затем с Opus 4.6;
- при этом каждому движку дали полный контекст соответствующих репозиториев.
Результат:
- Opus 4.7 успешно обнаружил баг;
- Opus 4.6 - нет.
Вывод Anthropic:
- внутренний Code Review нужно доучить подтягивать связанные репозитории как контекст по умолчанию;
- улучшенная версия этого инструмента со временем придёт и к конечным пользователям.
Фикс второго бага вошёл в релиз Claude Code v2.1.101 от 10 апреля.
---
Баг №3: system prompt, режущий ответы до 100 слов
Третья проблема была связана с тем, как настроен system prompt для Opus 4.7.
Новая версия Opus на старте показала ярко выраженную особенность - модель стала заметно многословнее предшественников. Это плюс на сложных задачах:
- больше пояснений;
- яснее логика рассуждений;
- подробные пошаговые инструкции.
Но одновременно это вело к взрывному росту длины ответов:
- переполнению контекста при длинных сессиях;
- увеличению расходов токенов;
- замедлению работы CLI.
В попытке укоротить ответы разработчики добавили в system prompt ограничение на длину - жёсткую рамку в районе 100 слов. Ошибка заключалась не в самом факте ограничения, а в слишком агрессивной его формулировке и применении поверх сложных сценариев работы через CLI.
Для пользователя это проявлялось как:
- странно короткие и поверхностные ответы там, где раньше Claude выдавал развёрнутые объяснения;
- обрезанные инструкции без достаточного числа примеров;
- ощущение, что ИИ "стал ленивым" и "отвечает лишь в общих чертах".
Проблему усугубляло сочетание с другими багами:
- пониженный reasoning effort;
- потеря части thinking-блоков;
- плюс жёсткий лимит на длину вывода.
Вместе это давало эффект резкой деградации качества, хотя ни одна из моделей не была намеренно ослаблена.
Исправление включало:
- пересмотр system prompt-а для Opus 4.7;
- смягчение и контекстное применение ограничений по длине;
- настройку поведения так, чтобы на сложных задачах модель не резала критически важные детали ради формального лимита слов.
Этот фикс также вошёл в обновления, которые суммарно сформировали стабильный релиз Claude Code v2.1.116.
---
Что уже изменили Anthropic
По итогам инцидента компания не только закрыла конкретные баги, но и анонсировала ряд инфраструктурных и процессных изменений:
1. Приоритизация качества reasoning по умолчанию
- Возврат к high/xhigh effort для продвинутых моделей.
- Рекомендация: снижение effort - сознательный выбор под конкретную задачу, а не дефолт.
2. Усиление тестов на контекст и долговременные сессии
- Добавление сценариев с "проспавшими" сессиями и возобновлением после простоя.
- Проверка, что thinking-блоки корректно сохраняются, очищаются и переиспользуются.
3. Улучшение Code Review с участием ИИ
- Расширение контекста анализа: связанные репозитории, смежные модули.
- Применение более сильных моделей (Opus 4.7 и выше) как стандарт для критичных участков.
4. Баланс между длиной ответа и полезностью
- Менее жёсткие лимиты в системных промптах.
- Контекстно-зависимое управление многословностью вместо глобальных "ножниц на 100 слов".
5. Мониторинг "качества глазами пользователя"
- Больше внимания к "размытым" сигналам деградации, а не только к формальным метрикам.
- Анализ паттернов: забывчивость, повторения, странный выбор инструментов, внезапная поверхностность.
---
Что делать пользователям Claude Code прямо сейчас
Чтобы убедиться, что вы больше не упираетесь в эти баги, стоит:
1. Проверить версию Claude Code
- Убедитесь, что у вас установлена как минимум v2.1.116.
- Если клиент старый - обновите его перед серьёзной работой.
2. Осознанно управлять reasoning effort
- Для сложных задач (архитектура, отладка, длинные рефакторинги) оставляйте high/xhigh.
- Понижайте effort только там, где действительно важнее скорость и экономия лимитов.
3. Следить за поведением в долгих сессиях
- Если вы продолжаете одну и ту же задачу спустя много часов или дней, лучше явно переформулировать контекст или подытожить его в свежем запросе.
- Это не обязательно, но помогает сделать сессию более устойчивой.
4. Обращать внимание на сигналы деградации
- Модель внезапно стала забывчивой, повторяется, обрывает мысли?
- Проверяйте настройки, версию клиента и при необходимости перезапускайте рабочую сессию, кратко пересобрав контекст.
5. Использовать внутренний контроль качества
- Для критичного кода или инфраструктурных изменений стоит прогонять свои PR через ИИ-кодревью, особенно если вы уже пользуетесь подобным инструментом на базе Claude.
- Инцидент показал: хорошо настроенный ИИ может поймать тонкие баги, которые проходят мимо человеческих ревьюеров.
---
Какие выводы можно сделать разработчикам и тимлидам
История с тремя багами в Claude Code - показательна не только для Anthropic, но и для любой команды, которая строит инструменты вокруг LLM:
- Ошибки часто живут в обвязке, а не в моделях.
Даже идеальная модель не спасёт, если контекст режется, кеш ведёт себя неправильно, а системные промпты конфликтуют с реальными задачами пользователей.
- Автоматические evals и dogfooding не гарантируют, что вы поймаете редкий corner-кейс.
Особенно если баг проявляется только на стыке нескольких подсистем или в состояниях "устаревшей" сессии.
- ИИ-кодревью - не просто модный инструмент, а реальная страховка.
Модели нового поколения уже умеют находить логические изъяны в коде, которые ускользают от человеческого взгляда, особенно в сложных, многослойных системах.
- Компромиссы по умолчанию нужно делать в пользу качества, а не производительности.
Пользователь почти всегда предпочитает более умный и надёжный ответ, чем более быстрый, но поверхностный.
- Системные ограничения (по длине ответа, по частоте, по памяти) должны быть "умными".
Жёсткие глобальные лимиты в духе "100 слов максимум" рано или поздно ломают ценные сценарии использования.
---
Итог
Деградация качества Claude Code в марте-апреле была следствием трёх конкретных ошибок в harness-слое, а не результатом ослабления моделей.
- Reasoning effort по умолчанию понизили слишком сильно.
- Оптимизация кеша стирала критически важные thinking-блоки в долгих и возобновляемых сессиях.
- System prompt для Opus 4.7 чрезмерно резал длину ответов.
Все эти баги исправлены к версии Claude Code v2.1.116, лимиты пользователям компенсировали. Если в последние месяцы вам казалось, что Claude стал "глупее", - дело было не в нейросети как таковой. Сейчас, при обновлённой обвязке и возвращённом высоком effort, качество reasoning должно соответствовать возможностям моделей четвёртого поколения.
