Claude Code модели: как выбрать по задачам своего репозитория и сравнить diff

Модель в Claude Code выбирают на своих задачах: команда берёт три-четыре типовые правки из репозитория, прогоняет их на разных алиасах и сравнивает diff, результат тестов и расход. Общий рейтинг моделей отвечает на вопрос о среднем разработчике, а ваш вопрос касается конкретного кода, конкретных тестов и конкретной привычки ревьюера. Такой выбор уместен, когда у репозитория есть автоматические тесты, иначе сравнивать приходится на глаз.

Способы выбора

Порядок приоритета описан в документации Claude Code по настройке моделей: команда внутри сессии перебивает флаг запуска, флаг перебивает переменную окружения, переменная перебивает файл настроек. Для эксперимента этого достаточно: запускаете сессию с нужным флагом, а в середине задачи меняете выбор через /model. Привычка фиксировать алиас в настройках проекта пригодится позже, когда выбор будет сделан и закреплён за командой.

• sonnet — алиас для повседневной разработки: правки, тесты, небольшие рефакторинги.
• opus — алиас для задач, где нужно длинное рассуждение: чужой модуль, запутанная ошибка, архитектурное решение.
• haiku — быстрый вариант для механических операций вроде переименования или массовой правки по шаблону.
• opusplan — связка, в которой планирование идёт на одной модели, а исполнение плана на другой.
• Суффикс [1m] включает расширенное окно контекста там, где версия модели его поддерживает.

Какая модель стоит по умолчанию, зависит от типа учётной записи: подписка и доступ через API дают разные стартовые значения, а список доступных вариантов может отличаться между аккаунтами. Поэтому в отчёте о сравнении запишите алиас вместе с полным именем, которое показал /model в вашей сессии. Без этой записи через месяц невозможно понять, что именно вы сравнивали.

Тестовые задачи

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

Текст задачи заслуживает отдельного внимания. Укажите файлы, в которых разрешено менять код, команду запуска тестов и признак готовности, например «все тесты модуля проходят, публичные имена остались прежними». Чем точнее критерий, тем меньше результат зависит от догадок модели, и тем яснее видна разница между моделями без примеси разных формулировок.

1. Создайте отдельную ветку или рабочее дерево git на каждую модель и каждую задачу, чтобы результаты лежали рядом и оставались раздельными.
2. Запустите claude --model sonnet, затем claude --model opus и вставьте один и тот же текст задачи. Контекст CLAUDE.md и права доступа держите одинаковыми.
3. После завершения задачи запустите тесты сами, отдельным вызовом. Отчёт агента об успешных тестах считайте заявлением; доказательство даёт только ваш прогон.
4. Сохраните diff, вывод тестов и расход токенов по /usage для каждой пары «задача и модель» в общую таблицу.

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

Чтение diff

Прошли тесты или нет, решает только первую половину. Вторая половина: насколько diff удобно читать и принимать. Короткий точечный diff, который меняет ровно то, что просили, экономит ревьюеру внимание. Длинный diff с попутной переделкой соседних функций требует отдельной проверки каждого куска, даже если тесты зелёные. Читайте результат так, как читаете чужой pull request, и фиксируйте замечания по одной схеме.

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

Когда мнения ревьюеров расходятся, добавьте в таблицу колонку «принял бы без правок / принял бы с правками / отклонил». Три ответа от двух-трёх человек дают картину честнее, чем единичная оценка автора эксперимента.

Расход и рассуждение

Помимо алиаса качество и расход меняет уровень рассуждения. Команда /effort принимает значения от low до max: на низком уровне агент отвечает быстрее и дешевле, на высоком тратит больше токенов на размышление. Для честного сравнения фиксируйте уровень одинаковым у всех моделей, а затем отдельным прогоном проверьте, меняет ли повышение уровня результат на вашей самой трудной задаче.

Расход смотрите по счётчику самой сессии: окно /usage показывает токены текущей сессии, а на подписке ещё и использование плана. Подробнее о том, как лимиты прерывают длинные задачи и как планировать работу при них, написано в материале про лимиты Claude Code и контроль расхода. Цены и квоты вендора меняются, поэтому актуальные значения берите со страницы тарифов самого сервиса, а в таблице эксперимента храните относительные величины: сколько токенов ушло на каждую задачу у каждой модели.

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

Решение для команды

По итогам прогона у вас окажется таблица из задач, моделей, ссылок на diff и оценок ревьюеров. Решение обычно выглядит как правило распределения, а единого ответа «лучшая модель» нет: механические правки идут на быстрый алиас, повседневные задачи на средний, сложные расследования на старший или на связку с планированием. Правило записывают в общий файл CLAUDE.md репозитория, как это делает команда с единым контуром Claude Code, чтобы новичку хватало файла вместо догадок.

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

Если часть сотрудников работает через собственные подписки, а часть через ключи, выбор модели придётся сверять с тем, что реально доступно каждому. Запишите в правило алиас и запасной вариант на случай, когда основной временно недоступен или упёрся в лимит. Тогда прерывание задачи превращается в переключение, а работа продолжается по уже известной процедуре.

Частые вопросы