В Claude Code разобрали, когда стоит включать высокий effort, а когда он только сжигает время и токены
Тарик команды Claude Code протестировал разные уровни effort на реальных задачах и Terminal-Bench 3.0. Оказалось, что высокий effort нужен далеко не всегда.
Effort определяет, сколько вычислений Claude готов потратить на задачу. Чем выше уровень, тем больше модель самостоятельно проверяет результат, тестирует крайние случаи и принимает решения без участия пользователя. Переключать уровень можно прямо во время работы через /effort, причем у новых моделей это не ломает кеш промпта.
На простых задачах разница огромна по времени. Одну и ту же просьбу сделать приложение для учета тренировок Opus 5.5 выполнил за 1,5 минуты на low, за 4 минуты на medium, за 11 минут на high и за 67 минут на max. Чем выше effort, тем более проработанным становилось приложение, но тем больше решений Claude принимал самостоятельно.
Если заранее дать подробное ТЗ, разница становится заметно меньше. В другом тесте Claude сначала подробно расспросил автора о приложении. После этого реализации на разных уровнях effort получились довольно похожими, хотя время выросло с 16 минут на low до 79 минут на max.
На Terminal-Bench 3.0 повышение effort у Fable 5.1 увеличило число успешных попыток со 140 до 214 из 370. Ошибки, которые собственные тесты модели не смогли обнаружить, сократились с 40 до 14.
Причина простая. На low Claude чаще пишет решение, запускает несколько очевидных тестов и останавливается. На высоком effort он может самостоятельно придумать дополнительные тесты, попробовать сломать собственное решение, сравнить несколько подходов и только после этого закончить работу.
Особенно сильно это помогло там, где результат легко проверить. В тестах Fable 5.1 безопасность выросла с 64% до 87%, аппаратные задачи с 34% до 75%, ML с 54% до 73%, научные задачи с 41% до 61%. В обычной разработке рост оказался скромнее, с 43% до 56%.
Но высокий effort не исправляет все ошибки. Он хорошо помогает находить пропущенные крайние случаи, но модель все еще может изначально неправильно понять задачу. Более того, при долгой автономной работе Claude приходится самостоятельно принимать больше решений, а значит появляется больше мест, где он может выбрать неправильную трактовку.
Поэтому Thariq предлагает довольно практичную схему^
Low подходит для идей, прототипов и простых изменений, когда вы сами постоянно контролируете работу.
medium подходит для большинства обычных задач разработки.
High стоит включать для исправления сложных багов, тестирования и задач с большим количеством крайних случаев.
Max имеет смысл, когда Claude должен долго работать самостоятельно, например полностью собрать и проверить приложение или искать уязвимости в критичном ПО.
Сам Тарик использует гибридный подход. Сначала дает Claude ТЗ и просит найти недостающие детали. Затем делает реализацию на low, быстро проверяет направление и вносит правки. И только финальную проверку и тестирование запускает на high.
Получается полезное правило. Чем больше вы сами участвуете в работе Claude, тем меньше нужен высокий effort. Чем дольше модель должна работать самостоятельно и проверять себя без человека, тем больше смысла дать ей дополнительное время и вычисления.