Как выбрать effort в Sonnet 5.5: когда нужны medium, high и max

Подберите effort Sonnet 5.5 по приёмке, задержке и расходам. Разберите разные настройки API и Claude Code и проверьте пользу более высокого уровня.

Линейная иллюстрация компаса с заголовком Sonnet 5.5 Effort.

Effort в Sonnet 5.5 — параметр для проверки, а не гарантия качества. Anthropic рекомендует medium как отправную точку для чётко поставленных агентных задач программирования и многошаговой работы с инструментами, high — для более трудной или длительной работы. Для чувствительного к задержке чата предлагаются medium или low. По умолчанию нативный API использует high, а у Claude Code есть собственная настройка.

Рекомендации взяты из документации поведения Sonnet 5.5, проверенной 29 сентября 2026 года. Статья объясняет, как оценить компромисс. Она не заявляет собственный бенчмарк Ofox по всем уровням effort.

Начните с задачи

НагрузкаДокументированная отправная точкаЧто проверять
Короткий чат с жёсткими требованиями к задержкеlow или mediumВремя ответа и пропущенные обязательные детали
Чётко заданная агентная работа с кодомmediumТесты, границы правок и ходы инструментов
Более трудные или длинные инструментальные задачиhighПринятый результат и повторяющиеся ошибки
Сложная задача, которая всё ещё не решаетсяПроверить более высокий уровень относительно базыМеняет ли дополнительный расход итог

Последняя строка — предложение для испытания, а не официальная гарантия, что xhigh или max устранят неудачу. Неполные требования, недоступные инструменты и противоречащие инструкции могут помешать при любом effort.

Страница модели указывает high как default API. Документация Claude Code описывает medium для Sonnet 5.5 в этом клиенте. Фиксируйте точку входа до сравнения: два запуска «Sonnet по умолчанию» могут иметь разные настройки.

Почему max не подходит как универсальный совет

Стартовая оценка Artificial Analysis обнаружила большой расход выходных токенов на max и невыгодное соотношение затрат относительно ряда альтернатив. Одновременно отчёт показывает серьёзные возможности на бенчмарках. Противоречия нет: сильный результат может достигаться ценой большего числа токенов.

Оценка проводилась на предварительном развёртывании с ошибкой структурированного вывода; авторы планируют повтор соответствующих тестов. Стоимость бенчмарка — не коммерческое предложение на исправление вашей ошибки и не доказательство бесполезности любого запуска max. Это повод собирать показатели качества и расходов вместе.

Высокий effort может менять и поведение. Дополнительное исследование полезно, когда проверяет относящиеся к проблеме объяснения, и вредно, когда расширяет задачу или уходит в постороннюю работу. Поэтому приёмка должна учитывать границы изменения, а не только прохождение одного теста.

Небольшое сравнение уровней

Подготовьте типичные задачи с ожидаемыми результатами или критериями приёмки. Зафиксируйте версию модели, инструменты, входные данные и исходное состояние репозитория. Запустите базовый уровень, затем более высокий или низкий на тех же задачах. Используйте независимые сессии, если не хотите, чтобы результат первого запуска подсказал ответ следующему.

Записывайте хотя бы:

Задача | Запрошенный effort | Применённый уровень | Принято | Попытки
Секунды | Входные токены | Категории кэша | Выходные токены
Плата за инструменты | Общая стоимость | Посторонние правки | Заметки ревью

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

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

Как задать effort без ошибки запроса

Для нативного API запрос с adaptive thinking может выглядеть так:

{
  "model": "claude-sonnet-5-5",
  "max_tokens": 2048,
  "thinking": {"type": "adaptive"},
  "output_config": {"effort": "high"},
  "messages": [{"role": "user", "content": "List the acceptance checks for a CSV parser fix."}]
}

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

Если between_tools отключает предварительные рассуждения, оставьте effort не выше high. Режим не поддерживает xhigh или max; изменение уровня внутри разговора также ограничено. Перед переносом прежнего disabled или ручного бюджета изучите план миграции.

В Claude Code можно запускать с --effort medium или выбирать поддерживаемый уровень через /effort. Управляемые настройки способны ограничить реальный уровень. Не приравнивайте запрошенный и применённый effort без проверки поведения клиента и аккаунта.

Когда сравнить другую модель

Если задача остаётся трудной, сравните повышение effort Sonnet с использованием другой модели. Sonnet и Opus — выбор внутри Claude; Sonnet и Sol — испытание разных разработчиков. При смене конфигурации сохраните задачу и критерии приёмки.

Выбрав исходную конфигурацию, запишите причину выбора и ошибки, при которых допускается переход на более дорогой вариант. Это упростит оценку следующих обновлений. Уровни effort Sonnet 5.5 перекалиброваны относительно Sonnet 5, поэтому прежнее название без нового теста не доказывает одинаковое поведение.

Часто задаваемые вопросы

High — значение по умолчанию везде?
Нет. Нативный API и Claude Code имеют разные документированные значения. Ограничения аккаунта и явные настройки могут менять фактическую конфигурацию.
Можно совместить max и between_tools?
Нет. Режим поддерживает low, medium и high. Для более высоких уровней нужен adaptive thinking.
Понижение effort всегда удешевляет завершённую задачу?
Не обязательно. На одну попытку может уйти меньше токенов, но понадобятся дополнительные попытки или участятся неудачи. Измеряйте стоимость принятого результата, а не отдельного ответа.