Thinking-модели: когда включать режим рассуждений

Ещё пару лет назад модель просто отвечала: вы отправили запрос — получили текст. Сегодня почти у каждой большой модели есть промежуточный этап: прежде чем выдать ответ, она пишет «для себя» цепочку рассуждений — прикидывает варианты, проверяет себя, отбрасывает тупиковые ходы. Этот этап называют режимом рассуждений, thinking или reasoning, и у него есть регулятор глубины.

Регулятор этот стоит денег. Токены размышлений оплачиваются как обычные выходные токены, занимают место в контексте и добавляют секунды к ответу — а видите вы в лучшем случае краткую сводку. Поэтому вопрос «включать или нет» — не про красоту, а про счёт в конце месяца и про то, дождётся ли пользователь ответа. Разберёмся, как этот переключатель устроен у основных провайдеров, что он реально меняет и по каким признакам решать, поднимать его или опускать.

Что происходит, когда модель «думает»

Технически ничего мистического: модель генерирует дополнительный текст, который не попадает в ответ. Она разбирает условие, пробует подход, замечает ошибку, начинает заново. Это те же самые токены, что и обычная генерация, просто адресованные самой себе.

Отсюда сразу следуют три практических факта, которые важнее любых бенчмарков.

Первое: за размышления вы платите по ставке выходных токенов. Не по льготной, не бесплатно. На сложной задаче модель может потратить на внутренние рассуждения больше, чем на сам ответ — и в счёте это будет выглядеть как очень длинный ответ. Как считать такие расходы, подробно разобрано в заметке Токены и лимиты: как считать и экономить.

Второе: размышления занимают тот же бюджет вывода. Если вы поставили max_tokens впритык под ожидаемый ответ, модель может исчерпать лимит прямо посреди рассуждений и вернуть обрезанный результат. У Anthropic это видно по stop_reason: "max_tokens", у OpenAI — по статусу incomplete с причиной max_output_tokens. Лечится не уменьшением глубины, а нормальным запасом по лимиту: в документации OpenAI прямо советуют резервировать не меньше 25 000 токенов на рассуждения и ответ, пока вы экспериментируете.

Третье: наружу отдаётся сводка, а не сырой ход мысли. И Anthropic, и Google, и OpenAI показывают сокращённую версию рассуждений — при этом тарифицируют полный объём. То есть по длине видимой сводки оценить расход нельзя, нужно смотреть на счётчики в ответе API.

Как это включается у разных провайдеров

Единого стандарта нет — у каждого свой параметр и своя логика. Сводная картина по ценам и лимитам есть в заметке Сравнение API: Gemini, Claude и OpenAI, здесь — только про рассуждения.

Anthropic: adaptive thinking и параметр effort

У Claude сейчас сосуществуют два механизма. Старый — extended thinking: вы передаёте thinking: {"type": "enabled", "budget_tokens": N} и явно задаёте, сколько токенов отвести на размышления. Минимум — 1024 токена, и бюджет должен быть меньше max_tokens. Это режим фиксированного бюджета: он всегда тратится, даже если вопрос тривиальный.

Новый механизм — adaptive thinking: thinking: {"type": "adaptive"} плюс output_config: {"effort": "..."}. Здесь вы не назначаете бюджет в токенах, а задаёте уровень усилия — low, medium, high, xhigh или max. Модель сама решает на каждом запросе, думать ли вообще и насколько долго: на простом вводе она может пропустить размышления целиком.

Важный нюанс при миграции: на моделях поколения 4.7 и выше старый type: "enabled" уже не принимается и возвращает 400 — нужно переходить на adaptive. Меняются и умолчания: у Opus 5 уровень усилия по умолчанию high, у Opus 5.5 — medium. Есть и модели, где рассуждения выключить нельзя в принципе; у Opus 5 они отключаются, но не на уровнях xhigh и max — попытка вернёт ошибку.

Отдельно стоит запомнить: конфигурация thinking входит в кэшируемый префикс запроса. Если вы дёргаете уровень усилия от запроса к запросу, вы каждый раз промахиваетесь мимо кэша и платите за префикс заново — см. Кэширование промптов. Фактический расход смотрите в usage.output_tokens_details.thinking_tokens.

OpenAI: reasoning.effort

У OpenAI ручка называется reasoning.effort и принимает, в зависимости от модели, значения от none и minimal до high, xhigh и max. У GPT-5.5 значение по умолчанию — medium, и документация называет его лучшей стартовой точкой. У новых моделей линейки GPT-6 универсального умолчания нет, уровень лучше задавать явно; none там не поддерживается и вернёт 400.

Сами токены рассуждений через API не видны совсем — только их количество в output_tokens_details.reasoning_tokens. Если нужна хотя бы сводка, её включают отдельно через reasoning.summary со значением auto, concise или detailed.

Google Gemini: thinking_level и thinkingBudget

У Google механизм зависит от поколения. В моделях Gemini 3 используется thinking_level с уровнями minimal, low, medium, high. Уровень minimal близок к «не думать вообще», но полного отключения не гарантирует. Поддержка уровней неоднородна: Flash-модели 3.7 и 3.8 не принимают minimal, а 3.1 Pro — ни minimal, ни low, и по умолчанию работает на high.

В поколении Gemini 2.5 логика другая — числовой thinkingBudget. Ноль выключает рассуждения там, где это разрешено, -1 включает динамический режим, когда модель подбирает бюджет под сложность задачи сама. Диапазоны зависят от модели: у 2.5 Flash это 0–24 576 токенов, у 2.5 Pro рассуждения отключить нельзя вовсе, допустимый диапазон — 128–32 768. Сводки включаются через includeThoughts, расход виден в thoughtsTokenCount.

GLM-5.3: выключателя больше нет

У Z.ai пошли по радикальному пути: в GLM-5.3 рассуждения всегда включены, отключить их нельзя. Остались три уровня reasoning_effort — low, high и max, причём умолчание — самый тяжёлый max. Это стоит держать в голове: если вы просто подставили новую модель в старый код, вы по умолчанию получили самый дорогой и самый медленный режим. Обзор среды разработки на этой модели — в заметке ZCode от Z.ai.

Когда режим рассуждений окупается

Общее правило простое: думать стоит там, где у задачи есть несколько шагов и цена ошибки на любом из них высока.

• Многошаговая логика и математика. Всё, где нужно свести несколько условий, посчитать и проверить результат. Здесь глубина даёт самый заметный прирост.
• Отладка и разбор незнакомого кода. Задачи вида «почему это падает» требуют перебора гипотез — ровно то, чем занимается модель в рассуждениях.
• Планирование работы агента. Шаг, на котором агент решает, какие инструменты вызвать и в каком порядке, — лучшее место потратиться. Дальше, на исполнении отдельных подзадач, усилие можно снижать; как это устроено в связке главный агент плюс субагенты, разобрано в заметке Агенты в Claude Code.
• Сложные правила и противоречивые требования. Когда в промпте десяток условий, часть которых конфликтует, модель без рассуждений склонна просто проигнорировать половину.

Когда он только мешает

Обратная сторона: на широком классе задач глубина не улучшает результат, зато гарантированно добавляет задержку и расход.

• Классификация и разметка. Определить тональность отзыва или категорию заявки — одношаговая задача. Тут выигрывает дешёвый уровень и хороший промпт.
• Извлечение данных по схеме. Если модель просто достаёт поля из текста в JSON, глубокие рассуждения не нужны — нужна жёсткая схема, см. Структурированный вывод (JSON).
• Переписывание и форматирование текста. Сократить, переформулировать, привести к стилю — механическая работа.
• Интерактивные сценарии. Чат на сайте, автодополнение, подсказки в интерфейсе. Пользователь уйдёт раньше, чем модель додумает.

Есть и менее очевидный эффект: на простых вопросах избыточные рассуждения иногда делают ответ хуже. Модель успевает «передумать» — уговорить себя отказаться от верного первого варианта в пользу более изощрённого и неправильного. Если вы замечаете, что на тривиальных кейсах качество просело после поднятия уровня, это не случайность.

Как выбирать уровень на практике

Порядок действий, который экономит больше всего нервов и денег:

1. Начните с середины. medium (или high там, где это умолчание) — нормальная стартовая точка. Не начинайте с max: вы не поймёте, нужен ли он вам, а счёт вырастет сразу.
2. Соберите набор тестовых кейсов. Двадцати-тридцати реальных примеров с эталонными ответами достаточно, чтобы увидеть разницу между уровнями. Без этого вы будете выбирать глубину по ощущениям. Как собрать такой набор — в заметке Как тестировать AI-агента: гайд по evals.
3. Двигайтесь вниз, а не вверх. Снижайте уровень до тех пор, пока качество на тестах не начнёт падать, и остановитесь на шаг выше. Так вы найдёте минимально достаточную глубину, а не максимально приятную.
4. Разделите задачи по уровням. В одном пайплайне вполне нормально держать low на классификации, medium на генерации и high на планировании. Единая настройка на весь проект почти всегда означает, что часть задач переплачивает.
5. Сначала попробуйте промпт. Часто то, за чем тянутся к высокому уровню усилия, решается внятной инструкцией и парой примеров — это дешевле на порядок. Приёмы собраны в заметке Промпт-инжиниринг: практические приёмы.
6. Логируйте счётчики рассуждений. thinking_tokens, reasoning_tokens, thoughtsTokenCount — заведите их в метрики с первого дня. Без этого рост расходов вы заметите уже по счёту.

Что запомнить

Режим рассуждений — это не «сделать хорошо», а «потратить больше времени и денег в обмен на шанс не ошибиться на многошаговой задаче». Там, где шагов нет, обмен невыгодный.

Провайдеры при этом явно двигаются в сторону автоматики: adaptive thinking у Anthropic и динамический бюджет у Gemini решают за вас, думать ли на конкретном запросе, а GLM-5.3 вообще убрал выключатель. Но выбор уровня усилия остаётся за вами — и это по-прежнему одна из самых дешёвых ручек оптимизации, до которой можно дотянуться: строчка в конфиге вместо переписывания половины пайплайна.