Anthropic признала, что жалобы на качество Claude Code, тянувшиеся шесть недель, были не «субъективным ощущением пользователей», а результатом сразу трех пересекающихся изменений в продукте. Для разработчиков и команд, которые уже встраивают ИИ-ассистентов в повседневную работу и CI-процессы, история неприятно полезная: деградация может приехать не вместе с новой моделью, а вместе с seemingly harmless настройками вокруг нее.
Как пишет InfoQ, сами веса модели и API при этом не менялись. Проблемы жили уровнем выше: в дефолтной настройке reasoning effort, в баге кеширования, который постепенно стирал ход рассуждений модели, и в системном промпте, где Anthropic попыталась приучить Claude Code говорить короче. Все три проблемы, по данным компании, были устранены к 20 апреля в версии 2.1.116, а подписчикам сбросили лимиты использования.
Три изменения, одна длинная полоса жалоб
Первая проблема появилась 4 марта. Anthropic перевела дефолтный reasoning effort в Claude Code с high на medium, чтобы уменьшить задержки интерфейса: во время длинных фаз «размышления» продукт выглядел подвисшим. Компания в постмортеме прямо назвала это неверным компромиссом. Пользователи быстро заметили, что ассистент стал слабее в задачах, где нужен длинный контекст, проверка гипотез и аккуратное планирование шагов. Формально настройку сделали более заметной в интерфейсе, но большинство людей, что неудивительно, оставались на дефолтном значении. Откатили изменение только 7 апреля. Сейчас, по словам Anthropic, модели по умолчанию используют high или xhigh.
Вторая проблема оказалась техничнее и от этого опаснее. 26 марта компания выкатилa оптимизацию для сессий, которые простаивали больше часа. Логика была такой: если после долгого простоя все равно происходит полный cache miss, старые thinking-блоки можно очистить, чтобы не тащить лишнее. Ошибка была в том, что очистка срабатывала не один раз после простоя, а на каждом следующем ходе до конца сессии. Внешне Claude Code продолжал работать, но все хуже помнил, почему вообще выбрал текущий подход. Для пользователя это выглядело особенно раздражающе: ассистент как будто терял нить, начинал дергаться между вариантами и охотнее лез в редактирование, чем в повторную проверку контекста.
Представитель команды Claude Code Борис Черны объяснял на Hacker News, что в крайнем случае пользователь с контекстом на 900 тысяч токенов после часа простоя получал полный промах по кешу на следующем сообщении. Это заметно било по лимитам, особенно у Pro-подписчиков. Исправление, которое должно было сократить эти издержки, и внесло баг. Починили его 10 апреля. Отдельный неприятный вывод для индустрии здесь прост: оптимизация стоимости и латентности в LLM-продуктах очень легко превращается в оптимизацию качества вниз, даже если на бумаге все выглядит рационально.
Третье изменение пришло уже 16 апреля, вместе с Opus 4.7. В системный промпт добавили ограничения на многословие: текст между вызовами инструментов просили держать в пределах 25 слов, а финальные ответы — до 100 слов. После внутреннего тестирования без заметных регрессий это отправили в прод. Но уже более широкие абляционные проверки, проведенные в ходе расследования, показали падение на 3% и для Opus 4.6, и для 4.7. Для обычного SaaS это мог бы быть спор о метриках. Для кодового ассистента 3% — это разница между «схватил проблему» и «уверенно поехал править не то». Ограничение откатили 20 апреля.
Почему это важно не только фанатам Claude
В этой истории интересна не только сама тройка ошибок, но и то, как именно Anthropic их пропустила. Внутренние evals и dogfooding не поймали ни одну из трех проблем по разным причинам. Сотрудники пользовались не теми же сборками, что внешние пользователи. Баг кеша проявлялся только в специфическом состоянии — в «залежавшейся» сессии. А тестовый набор оказался слишком узким, чтобы уверенно засечь 3-процентную просадку от изменения системного промпта. Для любой команды, которая строит продукт поверх LLM, это почти чек-лист типовых провалов: рассинхрон между внутренней и публичной версией, недостаточная проверка stateful-сценариев и переоценка силы локальных тестов.
Отдельный штрих добавило внутреннее расследование с помощью самого ИИ. Anthropic прогнала свой инструмент Code Review по pull request’ам, которые внесли ошибки. Opus 4.7 смог найти баг кеширования, если ему давали достаточно контекста по репозиторию. Opus 4.6 — нет. Компания теперь обещает добавлять в Code Review поддержку дополнительных репозиториев как контекста. Это, пожалуй, одна из самых практичных деталей всей истории: ассистенты уже можно применять не только для генерации кода, но и для ретроспективного поиска инженерных промахов. Но, как видно по тому же кейсу, эффективность у них сильно зависит от полноты окружения, а не только от названия модели.
Реакция сообщества была предсказуемо шумной. На Hacker News часть комментаторов похвалила Anthropic хотя бы за подробный постмортем — редкий жанр для AI-компаний, особенно когда речь идет не о громком релизе, а о тихом ухудшении продукта. Другие были жестче и усомнились, что разговоры про latency были главной причиной спорных решений, а не прикрытием для экономии вычислений. Еще одна линия критики касалась системного промпта: если компания публикует бенчмарки на одной конфигурации, а потом незаметно меняет поведение модели через prompt-layer, это уже не мелкая настройка интерфейса, а фактор, который должен быть прозрачно версионирован для пользователей.
Fortune, на которое ссылается InfoQ, отмечало, что часть клиентов чувствовала себя почти gaslit: сначала им намекали, что ничего необычного не происходит, хотя деградация была заметна в повседневной работе. На Reddit обсуждение ушло еще дальше. Пользователи указали на проблему, которую постмортем напрямую не разбирает: делегирование подзадач на более дешевую модель Haiku, которое видно только в подробных логах. Для интерактивного режима это неприятно, но переживаемо: инженер замечает, что ответ стал слабее, и корректирует курс. Для автоматизированных пайплайнов это уже другой класс риска. Там качество ломается тихо и может всплыть через несколько задач downstream, когда искать причину уже дороже.
Для русскоязычной IT-аудитории главный вывод скучный, но дорогой: при внедрении AI-инструментов в разработку нужно мониторить не только uptime и цену токена, но и поведенческие метрики продукта после каждого изменения на уровне промптов, маршрутизации, кеша и дефолтных настроек. Anthropic по итогам обещает больше сотрудников переводить на точные публичные сборки, расширять evals для каждого изменения системного промпта, добавлять soak-периоды и более осторожные rollout’ы. Вопрос теперь не в том, бывают ли у AI-ассистентов такие деградации, а в том, какая из компаний первой научится версионировать «обвязку» вокруг модели так же строго, как бэкенд-команды давно версионируют код и схему данных.