Я думал, что я самый умный. Я написал вспомогательную функцию, которая резервировала ровно тридцать процентов контекстного окна в качестве «бюджета на размышления» (thinking budget) для нашего AI-пайплайна. Это было чисто, предсказуемо и прекрасно работало на Opus 4.5. Но когда я переключился на Opus 4.8, каждый запрос завершался ошибкой 400. Моя тщательно выверенная математика токенов в одночасье превратилась в мусор.

Старый паттерн был прост. Вы устанавливали значение budget_tokens, и модель распределяла свои размышления так, чтобы уложиться в этот лимит. Если я передавал контекст в 128K, мой код выделял примерно 38 000 токенов на рассуждения, оставляя остальное для ответа. Это казалось ответственным подходом. Как соблюдение скоростного режима при вождении.

Эта модель ушла в прошлое. Новые релизы, такие как Opus 4.7 и 4.8, используют адаптивное мышление (adaptive thinking). Вы больше не выбираете число. Вместо этого вы передаете «регулятор усилий» (effort knob). Это звучит как простое переименование, но эти два способа управления не могут быть более разными. budget_tokens устанавливал жесткий потолок того, сколько модели разрешено думать. Effort управляет тем, как модель думает и действует в принципе. Одно — это счетчик на заправке. Другое — карта двигателя.

Сопоставление уровня усилий с реальными задачами

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

Классификация и маршрутизация почти всегда должны использовать уровень low. Это быстрые решения. Является ли это запросом на возврат средств или вопросом по продажам? Нужно ли эскалировать эту запись в логе? Вам не нужен монолог. Низкий уровень усилий минимизирует задержку (latency) и делает стоимость ничтожно малой.

Большая часть трафика приложений — ежедневная работа по суммаризации, рерайтингу, ответам в поддержке и извлечению контента — вписывается в уровни от medium до high. Это точка баланса. Модель получает достаточно пространства, чтобы разрешить реальную двусмысленность, не тратя токены на задачу, которая не требует развернутой цепочки рассуждений (chain of thought).

Программирование и агентные циклы требуют уровня xhigh. Именно здесь ошибки накапливаются как снежный ком. Если модель построит плохой план на первом этапе цикла вызова инструментов (tool-calling loop), она потратит следующие три шага на исправление ущерба. Или, что еще хуже, она вызовет не те инструменты, галлюцинирует параметры и оставит пользователя смотреть на сломанный рабочий процесс. Качественные рассуждения на старте предотвращают этот спираль.

Критические задачи должны получать уровень max. Не используйте это для всего подряд. Резервируйте этот уровень для моментов, когда цена ошибки выше любого счета за токены. Финансовая сверка, проверки безопасности, архитектурные решения и медицинская сортировка (triage) — вот подходящие примеры. Если ошибка означает, что человеку придется часами распутывать этот хаос, заплатите за дополнительные размышления.

Сюрприз со стоимостью

Вот часть, которая разрушила мою ментальную модель. Я предполагал, что максимальные усилия всегда будут раздувать мои расходы. В рамках одного шага — так и есть. Трассировка рассуждений становится длиннее. Но в многошаговых агентных задачах общий счет часто снижался.

Модель лучше планирует с первой попытки. Она делает меньше вызовов инструментов. Она сама останавливает себя от блуждания в тупиках. Я наблюдал, как агент извлечения данных, которому обычно требовалось пять итераций «вопрос-ответ», справился за две, потому что у модели было достаточно пространства для рассуждений, чтобы правильно распарсить схему в самом начале. При оценке стоимости смотрите на завершение задачи, а не на отдельный запрос. Больший бюджет на размышления за один шаг может означать меньшее общее количество шагов.

Как провести миграцию, ничего не сломав

Если в вашем коде всё еще встречаются budget_tokens, вот точный путь выхода. Не пропускайте третий и пятый шаги. Я пропустил их, и это стоило мне целого дня отладки.

Найдите budget_tokens в своем коде. Каждый экземпляр должен быть удален. Этот параметр не поддерживается в новых моделях и вызовет ошибку 400.

Замените объект бюджета на блок адаптивного мышления. Используйте thinking: { type: "adaptive" }.

Добавьте output_config с явным уровнем усилий для каждого вызова. Не полагайтесь на глобальное значение по умолчанию, если ваш трафик неоднороден. Ваш легковесный эндпоинт классификации не должен случайно наследовать те же настройки усилий, что и ваш агент для кодинга. Будьте эксплицитны в месте вызова.

Удалите ваш вспомогательный метод расчета бюджета. Я знаю. На него, вероятно, написаны юнит-тесты. На мой тоже были. Но теперь это мертвый груз. Платформе не нужна ваша математика токенов. Модель сама управляет своим темпом.

Удалите temperature, top_p и top_k. В моделях Opus 4.7 и 4.8 эти параметры сэмплирования вызовут ошибки 400. Платформа удалила их в этом поколении. Ваши старые трюки по настройке температуры здесь не сработают, а их наличие незаметно сломает процесс миграции.

Тестируйте каждую модель отдельно. Opus 4.5 и 4.8 — это совершенно разные модели. Конфигурация, работающая на одной, не обязательно будет работать на другой. Если вы поддерживаете несколько версий, разветвляйте логику или рассматривайте их как отдельные бэкенды.

Исправление зависания UI

Существует одна особенность стриминга, которая запутает пользователей, если её не обработать. В новых моделях блоки размышлений (thinking blocks) передаются в потоке, но по умолчанию текст пуст. В вашем интерфейсе это выглядит как долгая, неловкая пауза без видимого прогресса. Пользователи решат, что приложение зависло.

Чтобы это исправить, передайте thinking: { type: "adaptive", display: "summarized" }. Это даст вам видимый индикатор прогресса, не вываливая сырой поток мыслей в окно чата. Ваш фронтенд остается отзывчивым, а пользователи понимают, что «под капотом» что-то происходит.

Настоящий урок

Я построил целый слой абстракции поверх параметра, который вендор и не планировал оставлять надолго. Я обернул их настройки в собственную логику, потому что думал, что понимаю компромиссы лучше, чем платформа. Это было не так. Адаптивное мышление (adaptive thinking) — более выгодное решение, потому что модель сама решает, когда ей нужно глубоко рассуждать, а когда можно работать в упрощенном режиме. Моя кодовая база стала меньше. Результаты стали точнее. Иногда правильное инженерное решение — это удалить «умный» код и позволить платформе делать свою работу.

Если вы хотите прочитать оригинальные заметки по миграции, вы можете найти их здесь. Для участия в подобных практических обсуждениях присоединяйтесь к сообществу GyaanSetu AI в Telegram.