Армин Ронахер, автор Flask и один из наиболее узнаваемых инженеров в мире Python, наткнулся на неприятный сюрприз: Opus 4.8 и Sonnet 5 стабильно ломают вызовы инструментов в его кодинг-агенте Pi, тогда как более старые модели того же семейства работают без нареканий. Чем новее модель - тем хуже она справляется с задачей.

Что именно происходит

Суть сбоя - в механике вызовов инструментов. Это не магия и не отдельный канал: модель просто генерирует текст со специальными маркерами, который сервер интерпретирует как команду. У Anthropic используется псевдо-XML формат, где простые параметры пишутся напрямую, а вложенные структуры - как JSON внутри тега. Именно на стыке этих форматов что-то идёт не так.

Когда новая модель заканчивает длинную экранированную строку с содержимым файла, она должна закрыть объект. Вместо этого дописывает несуществующие поля - requireUnique, matchCase, oldText2 и другие, каждый раз разные. Сам контент при этом корректен: старый и новый текст совпадают байт в байт. Агент отклоняет вызов из-за мусора в конце, хотя полезная нагрузка верна.

Частота ошибок сильно зависит от длины сессии. На свежем коротком промпте сбой не воспроизводится вовсе. В длинной агентной сессии Opus 4.8 фейлил около 20% вызовов. Удаление thinking-блоков из истории диалога снижало число отказов вдвое - включение строгого режима (strict mode) убирало их полностью.

Версия Ронахера: след обучения в Claude Code

Случайная деградация? Ронахер так не думает. Его гипотеза указывает на пост-тренинг: судя по всему, обучение с подкреплением у Anthropic проходит внутри Claude Code или очень похожей среды.

Изучив исходники Claude Code, он обнаружил, что тот крайне снисходителен к неаккуратным вызовам: молча чинит битые Unicode-последовательности, принимает алиасы параметров и отфильтровывает неизвестные ключи. Если модель в такой среде дописала лишнее поле - задача всё равно завершилась, награда получена. Стимула не галлюцинировать ключи попросту нет.

Параллельно модель намертво привыкает к родной плоской схеме edit-инструмента. Любая другая схема - например, вложенный массив правок в Pi - оказывается для неё всё дальше от обученного распределения. Старые модели такой проблемы не имеют: их тренировали в иных условиях.

Последствия для сторонних разработчиков

Вывод неутешителен. Схемы инструментов перестали быть нейтральным контрактом - они теперь зависят от того, в каком харнессе прошёл пост-тренинг. Чем больше RL-обучения концентрируется внутри одного закрытого окружения, тем сильнее сторонние агенты вынуждены наследовать его поведенческие привычки, не имея доступа к самим настройкам.

Для сравнения: протестированные модели OpenAI аналогичной регрессии не показали. Их формат позволяет явно помечать начало JSON и подключать грамматики для кастомных инструментов - технически более прозрачное решение.

Проблему подхватил Саймон Уиллисон, сооснователь Django. Он задаётся практическим вопросом: не придётся ли теперь поддерживать несколько версий одного инструмента редактирования, подставляя каждой модели ту схему, на которой она лучше всего работает. Ирония очевидна - ещё недавно тренд указывал ровно в обратную сторону, и казалось, что умные модели адаптируются к любым инструкциям.

• Ошибка воспроизводится на Opus 4.8 и Sonnet 5, старые модели Anthropic проблемы не имеют
• В длинных сессиях частота сбоев достигает 20% вызовов
• Удаление thinking-блоков снижает число ошибок вдвое, strict mode устраняет их полностью
• Модели OpenAI аналогичной регрессии в тестах не показали
• Внутренности RL-окружений Anthropic сторонним разработчикам недоступны