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

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

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

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

Последняя строка — предложение для испытания, а не официальная гарантия, что 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, лимит ответа и разрешения инструментов

Эти параметры отвечают на разные вопросы. Effort влияет на объём рассуждений. max_tokens ограничивает токены ответа, включая thinking. Разрешения инструментов определяют действия, доступные приложению. Повышение effort не создаёт отсутствующий файловый инструмент и не даёт доступа к закрытому репозиторию; увеличение длины ответа не устраняет противоречивое задание.

Возьмём задачу «исправить итог CSV и запустить тесты». Если есть исходный код и исполняемый тест, effort действительно можно сравнивать. Если доступен только скриншот ошибки, сначала нужен код. Если правильный патч уже есть, но команда теста запрещена, требуется разрешённый способ проверки. Обозначать все три ситуации как «нужен max» значит скрывать причину.

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

Пример стоимости принятой задачи

Допустим, две конфигурации решают одинаковые десять небольших задач. Следующие цифры — синтетический учебный пример, не измерения Sonnet. Medium расходует $0.40 на все попытки, восемь задач приняты. High расходует $0.60, приняты девять. Стоимость принятого результата составляет $0.40 / 8 = $0.05 и $0.60 / 9 ≈ $0.0667 соответственно.

В примере high примерно на треть дороже на принятый результат, но завершает одну дополнительную задачу. Выгодность зависит от ценности завершения и обработки неудач. Нельзя заключить, что medium «на 25% менее точен» или high «всегда лучше». Маленькая синтетическая выборка не доказывает рабочую надёжность.

Теперь рассмотрим medium-first: все десять задач сначала идут в medium, а две неудачные — в high. Если эти два дополнительных запуска вместе стоят $0.12 и оба успешны, общая стоимость $0.52 за десять принятых задач, или $0.052 за одну. Арифметика объясняет возможную пользу повышения уровня, но не предсказывает, что high исправит любую неудачу medium. Если оба дополнительных запуска провалятся, расходы всё равно станут $0.52, а принятых задач останется восемь: $0.065 за одну.

Включайте все попытки, в том числе остановленные и неуспешные. Плату за инструменты и время человека учитывайте отдельно, если единицы различаются. При нуле принятых задач отношение не определено, а не равно $0.00. Если подписка не даёт надёжных расходов по задачам, показывайте наблюдаемое использование и задержку отдельно, не выдумывая сумму по тарифам API.

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

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

Запускайте каждую настройку в новой сессии из одного состояния. По возможности чередуйте порядок: временные условия сервиса и прогрев кэша могут постоянно помогать второму запуску. Состояние кэша записывайте, а не считайте неизменным. Повторения одной задачи — испытания одной задачи, а не дополнительные независимые задачи.

В строке результата нужны ID задачи, точная модель и endpoint, запрошенный и при возможности наблюдаемый применённый effort, причина завершения, время, категории usage, повторы, результат теста и выход за рамки задания. Сохраните ответ или diff для аудита приёмки. Если API не показывает применённое значение, напишите «нельзя независимо наблюдать», а не копируйте запрошенное значение с отметкой о проверке.

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

Заранее определите повышение уровня и остановку

Пример политики: начать ограниченную кодовую задачу с medium, один раз попробовать high при подтверждённой ошибке рассуждения на том же полном входе, а после второй неудачи остановиться для проверки. Это пример, не настройка Anthropic по умолчанию. Заранее исключите из таких повторов отсутствие доступа, неподдерживаемые параметры и неполный ввод.

Xhigh или max стоит испытывать, когда дополнительные рассуждения действительно могут помочь наблюдаемой ошибке и позволяют ограничения времени и расходов. Для них используйте adaptive thinking. У between_tools документированный максимум — high, а изменение effort в середине диалога ограничено. Для сравнения режимов начните новый контролируемый тест, не создавая невалидную смешанную историю.

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

Итоговая рекомендация должна обозначать область: например, «medium — базовый уровень для этих проверенных исправлений CSV; high оценивается на перечисленных отказах». Это полезнее универсальной метки лучшего effort и остаётся проверяемым при смене версии модели или состава задач.

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

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

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