Claude Code даёт две настройки, которые обе как бы «улучшают ответ»: модель и уровень усилий (effort). Но как они влияют на результат? И как понять, когда нужно менять модель, а когда — просто уровень усилий?
Легко предположить, что модель побольше, например Fable, даёт результат лучше, чем Sonnet, а более высокий уровень усилий значит просто «Claude думает дольше перед ответом».
Первое предположение верно. Наши крупнейшие модели действительно более способные согласно отраслевым бенчмаркам.
А вот усилия значат больше, чем «время на размышление». Effort определяет, сколько работы Claude выполняет над вашим запросом в целом. Сюда входит и то, сколько он думает, но также:
сколько файлов он читает;
сколько он всё проверяет;
как далеко он продвигается в многошаговой задаче, прежде чем вернуться к вам за уточнением.
При высоком уровне усилий Claude совершает больше таких действий (читает файлы, гоняет тесты, перепроверяет), прежде чем вернуться с ответом. При низком уровне он скорее спросит у вас больше контекста, чем будет сам разбираться, потратив на это токены.
Как работает выбор модели
Чтобы понять, что именно контролирует настройка модели, стоит начать с самого начала — с момента, когда вы нажимаете Enter.
Claude Code собирает ваше сообщение вместе с системным промптом, описаниями инструментов, вашим CLAUDE.md, историей разговора и любыми файлами в контексте. Всё это отправляется в API одним запросом.
Однако модель никогда не видит всё это как обычный текст. Первое, что происходит на сервере — токенизация: текст разбивается на кусочки, и каждый кусочек отображается в целое число из фиксированного словаря, на котором модель обучалась. const может отображаться в 1978, await — в 4293. С этого момента ваш промпт — это массив целых чисел.
Задача модели — взять этот массив и предсказать, какой токен идёт следующим. Она делает это, вычисляя вероятность для каждого токена в своём словаре и выбирая из верхних по вероятности. После «const x = await» хорошо обученная модель даёт высокую вероятность токену «fetch» (весьма вероятно) и почти нулевую — токену «banana» (совсем не вероятно).
То, что превращает входные токены в эти вероятности — веса (также называемые параметрами): миллиарды чисел, организованных в большие матрицы. Чтобы предсказать один токен, модель прогоняет ваш ввод через эти матрицы (длинную цепочку матричных умножений) и в конце считывает вероятности. Именно в весах хранится всё, что модель «знает».
Веса каждой модели фиксируются во время обучения, и к моменту, когда вы отправляете запросы, они доступны только для чтения. Ничто в вашем промпте, CLAUDE.md или контексте их не меняет. Именно это подразумевают, когда говорят «инференс» (inference): использование модели после завершения обучения, с зафиксированными весами.
Всё, что Claude знает о TypeScript, популярных фреймворках или любых других общих знаниях о программировании, было закодировано в эти веса на этапе обучения.
Ваш промпт и контекст всё же могут направлять предсказание. Показать Claude ваш реальный код — это и есть направление, и оно работает очень хорошо. Однако это никак не влияет на веса.
Если библиотека не существовала на момент обучения модели, её нет в весах. Вы можете положить документацию в контекст, и Claude ей воспользуется, но это направление, а не обучение. Ответ Claude меняется только для этого одного запроса, а сама модель ничего не сохраняет.
Когда Claude уверенно вызывает несуществующий API (галлюцинация) — это веса выдают последовательность токенов, которая выглядит правдоподобно на основе паттернов обучения, а не результат неудачного поиска.
Так что же делает смена модели? Она подменяет, какой набор зафиксированных весов обрабатывает ваш запрос.
Модель не генерирует весь ответ сразу. Она предсказывает один токен, добавляет его к последовательности и снова прогоняет все вычисления, чтобы получить следующий. Ответ из 200 токенов — это 200 отдельных проходов через веса. Именно в этом цикле кроется большая часть времени ожидания (и стоимости вывода).
Настройка модели решает, какие веса обрабатывают запрос, а также определяет, сколько стоит каждый выходной токен.
Что она не решает — это сколько токенов будет сгенерировано. Это число может сильно различаться для одного и того же промпта, в зависимости от того, сколько работы решит проделать Claude.
А это уже именно то, что контролирует effort.
Если статья понравится — приглашаю в канал AI for Devs. Каждый день публикую похожие материалы: модели, агенты, практические кейсы и новости из мира AI.
Как работает effort
Пока Claude Code работает над задачей, генерируемые токены делятся на несколько категорий:
Размышления (thinking) — рассуждения, которые вы видите потоком до и между действиями.
Вызовы инструментов (tool calls) — структурированные блоки, называющие инструмент вроде Read или Edit и его аргументы, которые Claude Code затем разбирает и выполняет.
Текст для вас — план, промежуточные обновления, итоговое резюме.
Всё это — обычные выходные токены из одного и того же цикла, оплачиваемые по одной ставке. Токены размышлений, например, генерируются точно так же, как и остальные выходные токены, и остаются в контексте до конца сессии.
К тому моменту, когда Claude переходит к написанию кода, его более ранние рассуждения уже часть входных данных — точно так же, как прочитанный файл.
Так как же effort меняет всё это? Уровень усилий передаётся модели как часть запроса, прямо рядом с вашим промптом. Модель обучена понимать, как вести себя на каждом уровне усилий, и это выученное поведение зашито в зафиксированные веса.
Когда приходит ваш запрос, effort — это просто ещё один вход, на который реагирует модель, точно так же, как она реагирует на текст вашего промпта. Он задаёт, насколько тщательным и насколько уверенным должен быть Claude, прежде чем считать задачу выполненной. Это решение принимается на каждом ходу, и более высокая уверенность требует больше токенов для выполнения задачи.
На более высоких уровнях усилий Claude часто начинает с составления плана, и уровень усилий влияет на глубину и ширину этого плана. Но план не зафиксирован навсегда. Получая результаты своих действий, Claude обновляет своё представление о том, насколько он продвинулся и насколько уверен в накопленном результате.
Если шаг 1 из плана отладки с тремя гипотезами находит баг, «исследовать гипотезы 2 и 3» может больше не понадобиться. Claude обычно прямо говорит об этом (например: «первая проверка нашла причину, так что оставшиеся проверки не нужны») и пропускает их. Это видно в Claude Code, когда список задач пересматривается прямо по ходу работы.
Более высокий уровень усилий действительно повышает вероятность, что Claude перепроверит найденный ответ или всё равно заглянет в гипотезы, которые мог бы пропустить. Однако, как правило, он не будет искусственно раздувать расход токенов на простой задаче только потому, что уровень усилий поднят. За «переусердствованием» (overthinking) наша команда специально следит при обучении моделей — оно снижает эффективность.
Выбор уровня усилий
Для большинства задач используйте уровень усилий по умолчанию для конкретной модели. Значение по умолчанию — это уровень, на котором Claude масштабирует расход токенов до того объёма, который большинство людей хотели бы потратить на задачу.
Думайте об effort как о ручном переопределении того, насколько усердно и как долго работает Claude. Обращайтесь к нему осознанно, когда у вас есть сильное предпочтение в сторону тщательности или скорости, исходящее из вашей области или типа работы, и относитесь к этому как к общей настройке предпочтений, а не как к решению для каждой конкретной задачи.
Одно практическое замечание после запуска Opus 4.8: в наших тестах уровень усилий по умолчанию у Opus 4.8 даёт лучшие результаты при том же расходе токенов, что и уровень усилий по умолчанию у Opus 4.7 на той же задаче.
Что менять, когда Claude ошибается
Когда Claude в чём-то ошибается, первым порывом не должно быть изменение настройки. Первым делом стоит посмотреть на контекст, который вы дали. Ваш промпт слишком расплывчатый? Подключены ли к Claude нужные инструменты? Есть ли у него нужные скиллы?
Если вы поднимаете уровень усилий для задачи, которой это в принципе не должно требоваться, проблему обычно нужно искать выше по потоку: в контексте, в вашем CLAUDE.md или в том, как поставлена задача.
Но допустим, вы дали ясный контекст, а Claude всё равно ошибся. Вопрос, который стоит себе задать: он недостаточно постарался или ему не хватило знаний?
Меняем модель когда задача была слишком сложной. Выбирайте более крупную модель, когда задача действительно сложная: тонкие баги, незнакомая область, архитектурные решения. Более крупная модель нужна тогда, когда меньшая модель уверенно ошибается независимо от того, сколько контекста вы ей дадите.
Крупные модели также лучше справляются с неоднозначностью. На меньших моделях конкретные инструкции, направляющие выполнение, — более надёжный рецепт успеха.
Выбирайте меньшую модель, когда работа рутинная: правки, которые можно точно описать, механические изменения, вопросы о коде, который уже в контексте. Нет смысла платить за возможности, которые задаче не нужны.
Если у Claude был весь нужный контекст, он явно постарался и всё равно ошибся — это сигнал выбрать более крупную модель. А если вы уже на крупной модели, а работа долгое время была рутинной, переход на меньшую модель повысит скорость и, как правило, снизит стоимость без потери качества результата.
Меняем effort когда Claude недостаточно постарался. Выбирайте более высокий уровень усилий, если Claude ошибся из-за того, что недостаточно постарался: пропустил файл, не прогнал тесты или не перепроверил свою работу. Это особенно актуально, если вы выбрали уровень усилий ниже стандартного для модели.
Специалист, эксперт и универсал
Один из способов, которым мне нравится представлять себе эти две настройки: Fable — это специалист, способный справиться с проблемами, которые почти никому больше не по силам, Opus — эксперт, а Sonnet — по-настоящему хороший универсал. Уровень усилий определяет, сколько времени любой из них тратит на вашу задачу.
Opus с низким уровнем усилий — это как получить пять минут с экспертом, у которого большой опыт именно с такими проблемами, как ваша. Он приносит знания, которых нет нигде в вашей кодовой базе: паттерны, которые он уже видел, подводные камни, которые он знает, как проверить — тот опыт, что появляется только после решения множества похожих задач. Но пять минут — это быстрый просмотр вашего кода, а не внимательный проход по каждому файлу.
Sonnet с высоким уровнем усилий — это универсал, у которого есть целый день. Он отлично пишет код и прочитает всё, запустит всё, что нужно, перепроверит свою работу и в итоге будет глубоко разбираться именно в вашем коде.
Fable — это специалист, к которому обращаются, когда все остальные зашли в тупик. Даже с низким уровнем усилий он заметит то, что не заметил бы никто другой. Именно за это распознавание вы платите больше всего, так что его стоит приберегать для задач, которым это действительно нужно.
Здесь нет универсально «лучшей» настройки. Модель отвечает за то, насколько Claude способный; effort — за то, насколько он тщательно старается. Большинству реальных задач нужно и то, и другое одновременно.
Усилия, модель и расход токенов
Так как же влияют друг на друга выбор модели, уровень усилий и расход токенов? Это зависит от задачи.
На рутинной работе при одинаковом уровне усилий и крупная, и маленькая модели обычно справляются одинаково. Крупная модель расходует больше токенов на дополнительные шаги проверки, да ещё и по более высокой цене за токен. Именно поэтому переход на меньшую модель для рутинных участков работы реально экономит деньги без потери качества.
На более сложной, многошаговой работе уравнение меняется. Меньшей модели приходится продвигаться к пределу своих возможностей, расходуя итерации, тогда как крупная модель достигает того же уровня качества за меньшее число шагов.
За токен крупной модели вы платите больше, но на задачах, которые по-настоящему выходят за пределы возможностей меньшей модели, итоговая стоимость всей задачи может оказаться ниже. А что важнее: крупная модель может завершить задачи, которые меньшая не может решить вообще — даже на максимальных уровнях усилий.
Наиболее заметно это в случае с Fable. На длинной, многошаговой работе он отрывается от остальных сильнее всего. В наших тестах он завершал задачи, которые Opus и Sonnet не могли решить ни на каком уровне усилий. При этом он и стоит больше за токен — ещё одна причина приберегать его для работы, которая действительно этого требует.
Ключевой момент на графиках выше: effort задаёт, насколько далеко Claude готов продвинуться по этой кривой. Это не значит, что ему обязательно понадобится пройти весь этот путь, чтобы завершить задачу.
И наконец: effort влияет на расход токенов, но не ограничивает его. Единственное жёсткое ограничение в системе — max_tokens, который обрывает ответ посреди генерации при достижении лимита, но это грубый инструмент, актуальный в основном для разработчиков, работающих напрямую с API. Более мягкие рычаги — например, бюджеты на задачу или просьба в промпте отвечать короче — работают лучше. Это ориентиры, которым модель обучена следовать (она стремится завершить работу, приближаясь к лимиту).
Effort отвечает за то, сколько работы выполняет Claude. Модель отвечает за то, что Claude знает.
Когда результат вас не устраивает, сначала проверьте контекст, а потом меняйте настройки: дайте Claude ясный промпт, нужные инструменты и скиллы, и способ проверить собственную работу.
Если Claude всё равно ошибся, спросите себя: ему не хватило знаний или он не постарался как следует? Не хватило знаний — это вопрос модели, не постарался — вопрос уровня усилий.
Русскоязычное сообщество про AI в разработке
Друзья! Эту статью подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-агентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!
