Управление мышлением

Мышление Claude адаптивно: модель оценивает каждый запрос и сама решает, думать ли и насколько много. Вы задаёте намерение, при желании указываете усилие, а модель распределяет рассуждения туда, где, по её оценке, они помогут.

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

Чтобы узнать, как включить мышление, как читать вывод мышления, а также о выводе мышления в Claude Fable 5 и Claude Mythos 5, см. обзор Мышление. На этой странице рассматривается, как Claude решает, когда думать, как управлять этим решением, а также механика кэширования, стоимости и ценообразования, которая из этого следует.

Как Claude решает, когда думать

Мышление для модели необязательно. При каждом запросе Claude взвешивает сложность входных данных и решает, улучшит ли ответ более глубокое рассуждение. Простой фактический вопрос может получить прямой ответ вообще без блока мышления; многошаговая математическая задача или сложная задача отладки запускает более глубокое рассуждение.

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

Основной элемент управления этим решением — параметр effort (усилие), который действует как мягкое указание на то, насколько охотно Claude должен думать и насколько глубоко; см. раздел Уровни усилия на этой странице, чтобы узнать, что делает каждый уровень.

Если вы хотите, чтобы Claude думал реже, понизьте уровень усилия, прежде чем прибегать к управлению через подсказки.

Мышление также автоматически чередуется с использованием инструментов: Claude может думать между вызовами инструментов, обдумывая каждый результат инструмента, прежде чем решить, что делать дальше (чередующееся мышление). Для этого не нужен бета-заголовок или какая-либо дополнительная настройка.

Полную картину того, как взаимодействуют конфигурация мышления и параметр effort, см. в разделе Мышление и усилие.

Управление тем, как часто Claude думает

То, думает ли Claude на данном ходе, поддаётся управлению через подсказки. Усилие задаёт общую установку, но вы также можете формировать решение напрямую с помощью указаний на естественном языке — либо глобально в «system prompt» (системной подсказке), либо для отдельного сообщения из хода пользователя.

Используйте оба рычага вместе в таком порядке:

1. Установите уровень усилия, соответствующий стандартному балансу качества и задержки для вашей рабочей нагрузки.
2. Добавляйте указания в подсказке только в том случае, если срабатывание мышления Claude на этом уровне всё ещё не соответствует вашим потребностям.

Более общие рекомендации по составлению подсказок с мышлением см. в разделе использование возможностей мышления и чередующегося мышления.

Уровни усилия

Усилие — основной рычаг управления мышлением. Каждый уровень задаёт своё значение по умолчанию для того, как часто Claude думает и насколько глубоко:

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

Усилие задаётся в output_config.effort, а не внутри объекта thinking; полные примеры для каждого языка см. в разделе Усилие.

{
  "model": "claude-opus-5",
  "max_tokens": 4096,
  "output_config": { "effort": "medium" },
  "messages": [{ "role": "user", "content": "..." }]
}

Доступность уровней зависит от модели; таблица доступности усилия на странице об усилии является авторитетным источником сведений о том, какие уровни поддерживает каждая модель.

Указания в системной подсказке

Указания в системной подсказке смещают порог мышления Claude для каждого запроса в разговоре. Если Claude думает чаще, чем нужно вашей рабочей нагрузке, добавьте в системную подсказку указание вроде этого:

Extended thinking adds latency and should only be used when it
will meaningfully improve answer quality, typically for problems
that require multistep reasoning. When in doubt, respond directly.

Чтобы, наоборот, поощрять мышление, используйте фразу вроде:

This task involves multistep reasoning. Think carefully before responding.

Эффективность управления может быть чувствительна к точной формулировке. Если одна формулировка не даёт желаемого поведения, попробуйте более прямой вариант.

Управление на уровне отдельных сообщений

Вы также можете управлять мышлением для отдельных сообщений из хода пользователя, независимо от системной подсказки. Добавление "Please think hard before responding." к сообщению пользователя побуждает Claude думать на этом ходе; "Answer directly without deliberating." подавляет мышление.

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

Проверьте управление на своей рабочей нагрузке

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

Механика

Из того, что Claude сам управляет своим мышлением, следуют три механики: валидация ходов, кэширование подсказок и способ ограничения стоимости.

Валидация ходов

Ходы ассистента не обязаны начинаться с блока мышления. (Модели, использующие устаревший ручной бюджет мышления, требуют, чтобы последний ход ассистента в запросе с включённым мышлением начинался с такого блока; см. Структура ходов в ручном режиме.)

Для многоходовых приложений это означает, что вы можете передавать историю разговора обратно в том виде, в каком она у вас есть:

• Ходы ассистента, в которых Claude решил не думать, являются допустимой историей как есть.
• Вы можете возобновить разговор, который начался без мышления или использовал другую конфигурацию мышления, не переписывая его историю.
• В историю, собранную из смешанных источников, не нужно заново вставлять блоки мышления в начало каждого хода ассистента, чтобы она прошла валидацию.

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

Кэширование подсказок

Последовательные запросы, сохраняющие одну и ту же конфигурацию мышления и уровень усилия, сохраняют «prompt caching» (кэширование подсказок); полные правила см. в разделе Мышление и кэширование подсказок. Итоговое значение усилия встраивается в подсказку, поэтому его изменение между запросами делает точки останова кэша недействительными — так же, как изменение устаревшего параметра budget_tokens на моделях, которые его используют. Явная установка effort в значение по умолчанию для модели эквивалентна его отсутствию и не нарушает кэш.

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

Следующий пример демонстрирует инвалидацию с помощью многоходового скрипта, который вы можете запустить сами:

import requests

client = Anthropic()


def fetch_article_content(url):
    text = requests.get(url).text
    lines = (line.strip() for line in text.splitlines())
    return "\n".join(line for line in lines if line)


# Получаем содержимое статьи
book_url = "https://www.gutenberg.org/cache/epub/1342/pg1342.txt"
book_content = fetch_article_content(book_url)
# Используем достаточно текста для кэширования (первые несколько глав)
LARGE_TEXT = book_content[:10000]

# Без системной подсказки — кэширование в сообщениях
MESSAGES = [
    {
        "role": "user",
        "content": [
            {
                "type": "text",
                "text": LARGE_TEXT,
                "cache_control": {"type": "ephemeral"},
            },
            {"type": "text", "text": "Analyze the tone of this passage."},
        ],
    }
]

# Первый запрос — создание кэша
print("First request - establishing cache")
response1 = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    messages=MESSAGES,
)

print(f"First response usage: {response1.usage}")

MESSAGES.append({"role": "assistant", "content": response1.content})
MESSAGES.append({"role": "user", "content": "Analyze the characters in this passage."})

# Второй запрос — та же конфигурация (ожидается попадание в кэш)
print("\nSecond request - same configuration (cache hit expected)")
response2 = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    messages=MESSAGES,
)

print(f"Second response usage: {response2.usage}")

MESSAGES.append({"role": "assistant", "content": response2.content})
MESSAGES.append({"role": "user", "content": "Analyze the setting in this passage."})

# Третий запрос — другой уровень усилий (ожидается промах кэша)
print("\nThird request - different effort level (cache miss expected)")
response3 = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    output_config={"effort": "medium"},
    messages=MESSAGES,
)

print(f"Third response usage: {response3.usage}")

First request - establishing cache
First response usage: { cache_creation_input_tokens: 3546, cache_read_input_tokens: 0, input_tokens: 15, output_tokens: 1033 }

Second request - same configuration (cache hit expected)
Second response usage: { cache_creation_input_tokens: 0, cache_read_input_tokens: 3546, input_tokens: 1062, output_tokens: 1630 }

Third request - different effort level (cache miss expected)
Third response usage: { cache_creation_input_tokens: 3546, cache_read_input_tokens: 0, input_tokens: 2706, output_tokens: 1468 }

Контроль стоимости

Вы не задаёте бюджет токенов мышления. Стоимость ограничивают два элемента управления:

• max_tokens — жёсткий предел общего вывода для запроса, мышления и текста ответа вместе. Claude никогда не генерирует сверх него. В цикле использования инструментов у каждого запроса в ходе свой max_tokens, поэтому он не ограничивает расходы всего хода.
• effort — мягкое указание на то, какую часть этого вывода Claude выделяет на мышление. Оно формирует поведение, но не гарантирует количество токенов.

Поскольку мышление учитывается в max_tokens, установите его достаточно высоким, чтобы оставить место и для рассуждений, и для ответа. Значение max_tokens, рассчитанное на ответ без мышления, часто оказывается слишком маленьким, когда Claude начинает думать над сложными запросами.

При усилии high и выше Claude может думать обширно и с большей вероятностью исчерпает бюджет. Если вы видите в ответах stop_reason: "max_tokens", у вас есть два средства:

• Повысьте max_tokens, чтобы дать модели больше места для мышления плюс ответа.
• Понизьте уровень усилия, чтобы Claude думал меньше и оставлял большую часть бюджета для текста ответа.

Какое из них правильное, зависит от того, нуждались ли усечённые ответы в рассуждениях. Если качество этих запросов важно, повысьте предел; если они были чрезмерно обдуманы, понизьте усилие.

Ценообразование

Мышление влечёт за собой плату за:

• Токены, которые Claude использует во время мышления (тарифицируются как выходные токены)
• Блоки мышления из предыдущих ходов ассистента, остающиеся в контексте, согласно правилу сохранения по умолчанию: все ходы по умолчанию на моделях, сохраняющих всё, и только последний ход в остальных случаях (тарифицируются как входные токены)
• Стандартные выходные токены текста

То, за что вам выставляется счёт, одинаково независимо от настройки display; меняется только то, что вы видите:

Чтобы увидеть, сколько тарифицируемых выходных токенов было потрачено на внутренние рассуждения, прочитайте usage.output_tokens_details.thinking_tokens в ответе. Это значение отражает исходные рассуждения, сгенерированные моделью (а не суммаризированный текст, возвращённый в теле), и всегда меньше или равно output_tokens. Вычтите его из output_tokens, чтобы приблизительно оценить часть вывода, не относящуюся к рассуждениям. При потоковой передаче эта разбивка появляется только в финальном событии message_delta.

{
  "usage": {
    "input_tokens": 25,
    "output_tokens": 348,
    "output_tokens_details": {
      "thinking_tokens": 312
    }
  }
}

output_tokens остаётся включающим всё авторитетным итогом, используемым для выставления счетов. output_tokens_details — это разбивка только для чтения, предназначенная для наблюдаемости. Полную информацию о ценах, включая базовые тарифы, записи в кэш, попадания в кэш и выходные токены, см. в разделе Цены.

Следующие шаги