Одна из лучших особенностей наших новейших моделей Claude — то, как они реагируют на параметр effort (уровень усилий), не ломая при этом кэш промптов в Claude Code. Но пользователи задают мне об этом массу вопросов. Что вообще такое effort и когда какой уровень выбирать? Зачем он вообще нужен?
Чтобы ответить, я решил глубоко погрузиться в результаты эвалов и самостоятельно протестировать работу effort на типичных повседневных задачах.
Примечание: больше интерактивных схем и пояснений к этой статье вы найдете на https://claude.dev/blog/spending-your-effort/
Если говорить в общих чертах, я выяснил, что effort — отличный способ управлять тем, сколько времени Claude тратит на проверки и тестирование граничных случаев, а также насколько активно модель полагается на собственную оценку ситуации.
Повышенный effort давал лучшие результаты там, где проверки и поиск граничных случаев особенно важны: в работе с железом, код-ревью и безопасности.
А вот низкий и средний уровни идеально подходили для быстрых задач и ситуаций, когда нужно постоянно держать руку на пульсе и работать вместе с Claude.
В обычной разработке я теперь использую такой цикл: сначала прошу модель провести со мной интервью, затем реализую задачу на low/medium effort, проверяю результат, а после запускаю верификацию на high effort.
Что такое effort?
Если коротко, effort дает модели примерное понимание того, сколько вычислительных ресурсов вы готовы выделить на задачу. Отчасти это связано с вашей собственной оценкой сложности работы.
Представьте: если вас просят сделать что-то за 12 часов непрерывной работы, вы решите, что от вас ждут максимального погружения и усердия. А если ту же задачу нужно выполнить за 1 час, вы постараетесь сразу выдать лучший вариант, который закроет потребность, а дальше будете дорабатывать его итерациями.
Или вы можете возразить: «На это нужно минимум 3 часа» — и потратить эти три часа, чтобы выдать результат.
К effort стоит относиться точно так же. Claude всегда старается выполнить задачу адекватно, но при высоком уровне effort модель будет действовать самостоятельнее, активнее оценивая и проверяя результат.
Кривые effort
Кривые effort у Fable 5.1 и Opus 5.5 — лучшие на сегодняшний день: на каждом уровне растут и показатели бенчмарков, и расход токенов. Ниже приведен график результатов Terminal Bench 3.0 в зависимости от уровня effort, полученный во время моих тестов для этой статьи.
Но что это значит на практике? Чтобы разобраться, я попробовал выполнить несколько задач с разными уровнями effort и детально изучил бенчмарки.
Разработка с использованием effort
Лучший способ понять, как работают модели, — поэкспериментировать. Я выполнял одни и те же задачи на разных уровнях effort в Opus 5.5, чтобы посмотреть, как меняется подход модели к работе. Задач было много и самых разных, но здесь я покажу всё на нескольких простых примерах.
Задача на разработку с минимумом вводных
Если я прошу Claude «создать приложение-трекер для фитнеса и тренировок», уровень effort кардинально меняет степень проработанности приложения, а также количество решений, которые модель принимает сама. На low effort фитнес-приложение получается просто журналом с базовым графиком. Чем выше effort, тем сложнее приложение и тем больше в нем деталей. На max effort появляется даже тепловая карта.
Если мне нужна простая база для дальнейших итераций, хватит low effort. Max effort пригодится, когда хочется получить от Claude максимум с первой попытки.
Задача на дизайн с базовыми требованиями
А что, если задача уже неплохо описана, но хочется немного поэкспериментировать вместе с Claude? В качестве примера я попросил переработать меню /config в Claude Code. Все варианты сводились примерно к одной идее: использовать подменю и улучшить поиск.
На low effort (заняло 1 минуту) я получил интерактивный набросок, который передавал суть, но мало напоминал интерфейс Claude Code.
На max effort (заняло 28 минут) получился макет, очень похожий на реальный Claude Code, плюс подробные сценарии использования для разных пользовательских путей.
Если цель — итерировать и давать обратную связь, low effort приведет к результату гораздо быстрее. Зато max effort сразу выдает нечто куда более отполированное. Для этой конкретной задачи я бы предпочел low effort, чтобы лучше понять замысел Claude.
Задача на разработку с детальным ТЗ
Что будет, если дать Claude максимум деталей? Я попросил модель подробно расспросить меня о фитнес-приложении, а затем передал готовое ТЗ разным моделям для реализации с разными уровнями effort.
Выяснилось, что при наличии четкого ТЗ модели ведут себя гораздо более похоже. Дизайны и реализация выходили схожими, отличались лишь детали, а на max effort Claude потратил время на упрощение некоторых из них.
Главные выводы
В обычной разработке, особенно при создании новых фич, выбор уровня effort сильно зависит от того, насколько плотно вы хотите контролировать процесс. Low effort позволяет Claude быстро предложить отправную точку, а более высокие уровни сделают больше работы, но модель будет принимать больше решений за вас.
Особенно продуктивный цикл разработки фичей, которым пользуюсь я:
- Дайте Claude ТЗ и попросите расспросить вас о любых недостающих деталях
- Реализуйте задачу на low effort
- Проверьте, правильно ли модель поняла суть, при необходимости сделайте итерации на low effort
- Проведите проверку и тестирование на high effort
Как уровни effort влияют на результат в сложных задачах
Конечно, примеры выше — игрушечные, и Claude легко с ними справляется. Но что происходит, когда разница заключается в том, выполнит модель задачу или нет?
Чтобы найти такие сложные проблемы, пришлось обратиться к бенчмаркам, и я выбрал тот, что мне нравится: Terminal Bench 3 — бенчмарк, созданный сообществом.
Задачи Terminal-Bench 3.0 можно условно разделить на категории: безопасность, железо, ML, наука, ПО, эксплуатация и медиа. Все задачи можно посмотреть здесь: https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0. Их собирает сообщество, так что внести вклад может любой желающий.
Их стоит прочитать, чтобы понять, с какими проблемами сталкиваются эти модели. Меня, честно говоря, удивил масштаб и амбициозность многих задач. Они намного сложнее того, с чем я обычно имею дело.
Например, среди задач были такие:
- Железо (retro-console-soc): написать на Verilog 8-битную игровую консоль, которая поместится в небольшую FPGA и сможет отрендерить тестовый ROM.
- Наука (takens-embedding-lean): формально доказать теорему вложения Такенса в Lean 4.
- ML (mp-checkpoint-consolidation): объединить 16 шардов чекпоинта mixture-of-experts в один файл, воспроизводящий эталонные логиты.
- Эксплуатация (intrastat-meldung): полностью провести процесс подачи месячной отчетности по торговле в ЕС для компании.
- Медиа (layout-config-recreation): воссоздать изображение постера в виде редактируемого файла макета.
Высокие уровни effort помогают, когда много граничных случаев
Главный вывод, который я сделал, изучая результаты Terminal Bench 3: высокий effort лучше всего подходит для задач с множеством скрытых граничных случаев.
Отличный пример — html-js-filter, задача из Terminal-Bench 3.0, требующая создать HTML-санитайзер, блокирующий все возможные способы внедрения JavaScript на страницу. Fable 5.1 улучшила результат с 1/5 на low до 5/5 на xhigh.
Типичная попытка на low effort занимает около 2 минут. Модель писала фильтр примерно за один проход, а затем тестировала его на одной странице, написанной вручную.
Запуск на high effort занимает около 33 минут. В том прогоне, который я отслеживал, модель сначала критически проверила свой черновик, затем прочитала исходники установленного парсера на предмет багов, прогнала множество чистых тестов, пока их вывод не совпал с входными данными, запустила стандартный набор XSS-тестов и в итоге написала фаззер для случайных документов.
Для задачи с таким количеством граничных случаев, как HTML-санитайзер, дополнительные усилия полностью себя оправдывают. Тратить больше токенов ради тщательности имеет смысл и в сложных задачах с высокими требованиями к продакшену, например при оптимизации производительности или аудите безопасности.
Но далеко не для каждой задачи нужен такой уровень effort.
На схеме ниже показаны все результаты Terminal-Bench 3.0 и причины ошибок для разных моделей и уровней effort. В целом повышение effort снижает количество ошибок из-за пропущенных граничных случаев (фиолетовые блоки), но не помогает, если модель изначально выбрала неверный подход (синие блоки).
Области, где effort действительно помогает
Один из самых интересных выводов, который я сделал, тестируя эти модели на TerminalBench: есть области, где effort дает гораздо больший эффект, чем в других. Разбивка показана на следующей схеме:
Чтобы проиллюстрировать это, я выбрал несколько задач из разных областей Terminal Bench 3.0, где Opus 5.5 не справлялась на low effort, но успешно решала их на high effort — в основном потому, что начинала тестировать и учитывать граничные случаи:
mvcc-lsm-compaction: задача из Terminal-Bench 3.0, где нужно исправить баг движка хранения по отчету о падении, не сломав при этом компакцию. Opus 5.5 улучшила результат с 0/5 на low до 4/5 на xhigh.
На low effort (около минуты на попытку) Claude редактировала код до сборки или запуска скрипта воспроизведения и не проверяла, смог бы её новый тест поймать исходный баг.
На xhigh (около 11 минут) Claude сначала воспроизводила падение, писала рандомизированный тест, сравнивая результат с эталоном без компакции, и проверяла, что тесты падают на частично готовых исправлениях.
cli-2ph-simple: задача из Terminal-Bench 3.0, требующая написать CLI-решатель задач линейного программирования на Python. Opus 5.5 улучшила результат с 0/5 на low до 5/5 на high.
На low модель писала решатель за один проход, проверяла его на нескольких мелких задачах и останавливалась примерно на 10 тыс. токенов. В последнем сообщении Claude предупреждала, что на больших задачах решение может работать медленно, но проверять это не стала.
На high Claude тестировала свой решатель на случайных задачах, сверяясь с отдельным решателем полным перебором, затем замеряла время на крупных задачах, натыкалась на случаи, которые работали слишком долго или приводили к падению, и перерабатывала алгоритм поиска.
gsea-proteomics: задача из Terminal-Bench 3.0, где нужно провести анализ обогащения набора генов (GSEA) на протеомных данных, чтобы определить, какие из восьми методов лечения дают эффект, похожий на целевую ткань. Opus 5.5 улучшила результат с 0/5 на low до 4/5 на high.
На low effort Claude выбирала разумный на первый взгляд способ подготовки данных, проводила анализ этим методом и выдавала результат.
На high Claude пробовала два способа подготовки данных, замечала, что список значимых методов лечения меняется, и разбиралась в причинах, прежде чем выбрать правильный вариант.
Если бы пользователь участвовал в процессе, Claude могла бы спросить его, как лучше подготовить данные. Но без участия человека высокий effort работает лучше.
Когда какой уровень effort использовать в Claude Code
Вот мое практическое правило выбора уровня effort:
- Low: когда нужны быстрые ответы и постоянный контроль, например для брейншторма, набросков, простых правок.
- Medium: для большинства повседневных задач разработки, например реализации новых фичей.
- High: для работы, где важна проверка или много граничных случаев, например исправление бага в legacy-кодовой базе.
- Max: когда нужно, чтобы Claude работала полностью автономно над сложными проблемами, например создавала и проверяла приложение от начала до конца или искала уязвимости в критически важном ПО.
Попробуйте менять уровень effort для Opus 5.5 и Fable 5.1 в зависимости от задачи или даже прямо во время диалога с помощью команды /effort в Claude Code — и расскажите, совпадает ли это с вашими ожиданиями.
