Extended thinking: когда включать и во что это обходится

Extended thinking доступен на всех текстовых моделях каталога — от claude-opus-5-5 и всей линейки GPT-5.6 до GLM 5.3 (при этом контекст и vision у моделей разные: у Claude и GPT — 1M токенов, у GLM — 128K и без vision; актуальный список — GET https://api.zukko.pro/v1/models). Раз функция доступна везде, возникает соблазн включать её по умолчанию на каждый запрос. На практике это не бесплатно ни по времени, ни по счёту, и для большей части простых запросов не даёт ощутимой разницы в качестве.

Как включается в запросе

В Anthropic-совместимом режиме параметр передаётся в теле запроса к /v1/messages:

curl https://api.zukko.pro/v1/messages \
  -H "Authorization: Bearer fetch_ваш_ключ" \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 2048,
    "thinking": {"type": "enabled", "budget_tokens": 6000},
    "messages": [{"role": "user", "content": "Спроектируй схему БД для маркетплейса с мультивендорными заказами"}]
  }'

budget_tokens ограничивает, сколько модель может потратить на само рассуждение до того, как перейти к финальному ответу — это отдельный бюджет, не входящий в max_tokens итогового текста напрямую, но так же оплачиваемый.

Когда включение оправдано

Extended thinking помогает там, где ответ требует нескольких шагов рассуждения, которые нужно держать в голове одновременно: проектирование схемы данных с учётом ограничений, поиск логической ошибки в алгоритме, разбор запутанной цепочки причин и следствий, планирование миграции с учётом зависимостей между сервисами. В таких задачах модель без thinking чаще выдаёт правдоподобный, но поверхностный ответ, который не выдерживает проверки на реальных ограничениях задачи.

Когда это просто трата денег и времени

Для короткого фактического вопроса, простого форматирования, генерации шаблонного кода по понятной спецификации или ответа, который и без того укладывается в пару предложений, thinking почти всегда не меняет результат, зато удлиняет время ответа и добавляет токены на рассуждение в счёт. Здесь разумнее оставить thinking выключенным по умолчанию и включать точечно.

Как измерить разницу в цене на своих запросах

Самый надёжный способ — не читать общие рекомендации, а сравнить один и тот же запрос с thinking и без:

import requests

KEY = "fetch_ваш_ключ"
TASK = "Опиши архитектуру retry-механизма с exponential backoff и jitter для очереди задач"

for thinking_enabled in [False, True]:
    body = {
        "model": "claude-sonnet-5",
        "max_tokens": 1500,
        "messages": [{"role": "user", "content": TASK}],
    }
    if thinking_enabled:
        body["thinking"] = {"type": "enabled", "budget_tokens": 4000}

Заголовок X-Zukko-Cost-Micros покажет точную разницу в микродолларах между двумя вызовами — миллион микродолларов равен доллару. На своей задаче эта разница может оказаться копеечной или существенной, и узнать это заранее полезнее, чем ориентироваться на общие оценки из чужих статей.

Кэш и thinking вместе

Если один и тот же запрос с thinking повторяется — например, при повторной генерации одного и того же аналитического отчёта, — имеет смысл включить кэширование заголовком X-Zukko-Cache: true (temperature: 0 тоже включает кэш, но только у моделей, которые принимают этот параметр; Claude-модели — claude-sonnet-5, claude-opus-5-5 — могут отклонить temperature, отличную от 1, с ошибкой 400, поэтому им его не передавайте): тогда одинаковые запросы одного пользователя кэшируются на срок до 7 суток для чата, и повторный вызов возвращается мгновенно и бесплатно, с пометкой X-Zukko-Cache: hit в ответе. Срабатывает это только при полном совпадении тела запроса (не «почти одинаковые» запросы и не общий префикс), а попадания в кэш не пишутся в /v1/usage. Thinking-токены при этом не пересчитываются заново — ответ просто отдаётся из кэша.

Считать токены заранее для длинных рассуждений

Если промпт для thinking-задачи сам по себе объёмный — например, включает большой кусок кода на ревью, — полезно заранее прикинуть размер через бесплатный подсчёт:

curl https://api.zukko.pro/v1/messages/count_tokens \
  -H "Authorization: Bearer fetch_ваш_ключ" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-opus-5-5","messages":[{"role":"user","content":"..."}]}'

Это не покажет стоимость thinking-токенов напрямую, но даст понять, сколько уже занимает сам запрос до того, как модель начнёт рассуждать.

Thinking не заменяет vision и не расширяет контекст

Extended thinking — это про глубину рассуждения, а не про то, что модель увидит на картинке или сколько токенов поместится в разговор. Vision и размер контекста — свойства самой модели (у Claude и GPT — 1M токенов и vision, у GLM — 128K и без vision), и они не зависят от того, включён ли thinking — это отдельные, не связанные друг с другом характеристики. Включать thinking в надежде, что модель "лучше разглядит" изображение или удержит больше контекста, бессмысленно: за это отвечают другие параметры запроса, а thinking решает только качество самого рассуждения над уже полученными данными.

Idempotency-Key бережёт бюджет и на thinking-запросах

Раз thinking-токены оплачиваются так же, как обычные, стоит относиться к таким запросам осторожнее при автоматических ретраях. Добавьте заголовок Idempotency-Key со случайным значением на каждый уникальный thinking-запрос — если клиент или агент решит повторить вызов после сетевого сбоя, повтор с тем же ключом и тем же телом в течение 24 часов вернёт уже посчитанный ответ, а не запустит рассуждение заново и не спишет деньги дважды.

Практический вывод

Включайте extended thinking точечно — там, где задача реально требует удержания нескольких условий одновременно, а не как настройку по умолчанию для всех моделей. Разница в цене и времени ответа между включённым и выключенным thinking легко измеряется на собственном примере через заголовок X-Zukko-Cost-Micros, и эта проверка занимает меньше времени, чем спор о том, нужен ли thinking конкретной задаче.