Sonnet 5.5 или Opus 5.5: какую модель выбрать для исправлений и ревью

Sonnet 5.5 стоит сначала оценить на чётко заданных задачах, а Opus 5.5 — включить в испытание там, где нужны сложные суждения, исходные данные неоднозначны или повторяются неудачи. Это способ подбора кандидатов, а не доказательство, что Sonnet всегда справляется с малым, а Opus побеждает на большом. Критериями приёмки остаются тесты репозитория и требования ревью.

Anthropic позиционирует Sonnet как более быстрое и менее затратное дополнение к Opus, а Opus — как модель для сложной работы, требующей взвешенных решений. Но тарифы и effort делают выбор сложнее формулы «Sonnet вдвое дешевле». Статья основана на документации, проверенной 29 сентября 2026 года; собственное парное испытание моделей не заявляется.

Одной тарифной таблицы недостаточно

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

Представим два синтетических запроса: каждый читает 100 000 токенов кэша и генерирует 2 000 оплачиваемых выходных токенов, остальные категории исключены. Sonnet обойдётся в 0,04 доллара, Opus — в 0,06 доллара. Разница не двукратная, поскольку чтение кэша в примере стоит одинаково. Дополнительные ходы одной из моделей снова изменят расчёт.

Свяжите задачу с проверяемым результатом

Это варианты испытаний, а не измеренные показатели успешности. Короткий патч может требовать сложных рассуждений, а длинная механическая правка — быть простой. Число файлов или изменённых строк само по себе плохо отражает трудность.

Читайте результаты вместе с условиями

Стартовый отчёт Artificial Analysis о Sonnet показывает сильные результаты на нескольких задачах и значительно больший расход вывода на max. Он также отмечает проблему структурированного вывода в предварительном развёртывании и запланированные повторные оценки. Этого достаточно, чтобы испытать обе модели, но недостаточно, чтобы определить вашу самую дешёвую конфигурацию.

Сравнение Opus medium с Sonnet max — сравнение конфигураций, а не только моделей. Оно может быть полезным, если опубликованы обе настройки и фактические бюджеты. Даже одинаковые названия effort не гарантируют одинакового объёма вычислений.

В объявлении Anthropic тоже описаны сильные стороны моделей и условия оценки. Разделяйте заявления разработчика, независимые измерения и собственные наблюдения. Расхождения графиков могут объясняться задачами и настройками, а не необъяснимым противоречием.

Простое правило перехода к другой модели

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

Передайте в новый запуск описание проблемы, нужные файлы и результаты тестов. Не считайте подписанные блоки рассуждений переносимыми между моделями. Для Sonnet 5.5 действуют правила модели и диалога из руководства по миграции. Сохраняйте видимые свидетельства вместо расчёта на непрерывность скрытого состояния.

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

Три разные пропорции стоимости

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

Запись кэша Opus на пять минут и час стоит соответственно $5 и $8 за миллион токенов, Sonnet — $2.50 и $4. Если каждой модели создать собственный пятиминутный кэш на 100K, затем прочитать его девять раз и выдавать по 2K на каждом из десяти вызовов, итог — $0.63 для Sonnet и $1.08 для Opus. Sonnet: $0.25 создание + $0.18 чтение + $0.20 выход. Opus: $0.50 + $0.18 + $0.40. Это около 1,71 раза, не постоянный множитель 2.

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

Когда сложность оправдывает раннее включение Opus

Сложность часто связана с неопределённостью правильного поведения, а не с размером изменения. Одна строка проверки доступа может требовать больше осторожности, чем замена имени API в 30 файлах. Позиционирование Anthropic делает Opus разумным кандидатом для длительной работы с неоднозначными решениями, но не доказывает необходимость Opus для любой однострочной ошибки.

Задайте четыре вопроса: неизвестна ли причина; конфликтуют ли требования; возможны ли дорогие побочные эффекты; требует ли приёмка оценки альтернатив, а не сверки определённого ответа? Несколько положительных ответов оправдывают вторую конфигурацию до принятия патча. Они не оправдывают расширение прав инструментов.

Для локальной ошибки форматирования с падающим snapshot-тестом начните с Sonnet и потребуйте целевой тест плюс соседние регрессии. Для повторной оплаты, способной списать деньги дважды, приёмка должна покрывать идемпотентность, частичный отказ и восстановление. При необходимости включите Opus в расследование, но чувствительное изменение проверяйте на фикстурах и человеком. Более сильная модель не заменяет изоляцию внешних действий.

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

Задайте бюджет эскалации заранее

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

Допустим, попытка Sonnet стоит $0.06, эскалация Opus — $0.12, и разрешена максимум одна. Если доля эскалируемых задач равна e, средняя токенная стоимость поданной задачи — $0.06 + $0.12e. При e = 25% это $0.09; при 50% — $0.12, как одна прямая попытка Opus в этих предположениях. Выше 50% такая маршрутизация дороже прямой базы.

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

Передайте второй модели проверяемые материалы

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

Не превращайте пакет в «предыдущая модель сказала X, значит X верно». Отделяйте реальный вывод теста от его интерпретации. Если первый запуск менял файлы, вернитесь к общей базе либо явно зафиксируйте другое начальное состояние. Иначе кажущийся успех Opus может зависеть от полезной работы Sonnet, а кажущаяся неудача — от унаследованного повреждённого дерева.

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

Превратите сравнение в правила по типам задач

Сохраните Sonnet как кандидата для частой, хорошо определённой работы с дешёвой проверкой. Для неоднозначных и дорогих ошибок включите Opus, оставив прямой запуск Opus как базу: иначе не видно, когда сама эскалация расточительна. Если категория постоянно требует перехода, сначала исключите плохой промпт и поломку интеграции, затем решайте, направлять ли её сразу.

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

Если вы работаете по подписке

Нельзя перевести таблицу API в точное количество запросов Claude Code. Лимиты подписки зависят от аккаунта и условий сервиса. Проверяйте фактически выбранную модель, особенно после обновления клиента или смены провайдера, и учитывайте способ оплаты отдельно от названия модели.

В руководстве Claude Code описаны проверка версии и явный выбор. Статья об effort разделяет значения по умолчанию в API и клиенте. Для другого разработчика используйте методику сравнения Sonnet и Sol.