Sonnet 5 против Opus 5: как за полгода изменился выбор модели для разработки
От выбора одной модели на всю задачу — к routing между execution, сложным reasoning и критическим review.

Февраль: одна задача — одна модель

В феврале выбор Claude для разработки был почти линейным. Sonnet 4.6 стала быстрым default для повседневной работы, а Opus 4.6 подключали к refactoring, сложному debugging и большим codebase.

Это разделение следовало из самих релизов. Opus 4.6 лучше планировала, дольше удерживала agentic task и тщательнее проверяла код. В анонсе Sonnet 4.6 Anthropic оставляла deepest reasoning, multi-agent coordination и критичный refactoring за Opus.

TASK
  ↓
routine  → SONNET
complex  → OPUS

Модель выбиралась на всю задачу. После старта почти никто не планировал сменить её между research, implementation и review.

Июль: Sonnet догнала старую границу, Opus создала новую

30 июня вышла Sonnet 5, 24 июля — Opus 5. За пять месяцев обе ступени сдвинулись, но с разной ролью.

Sonnet 5 Anthropic называет самой agentic Sonnet-моделью: она планирует, использует browser и terminal и работает автономно на уровне, который недавно требовал более дорогих моделей. На части eval новая Sonnet достигает уровня Opus 4.8, хотя это не означает равенства на любой задаче.

Opus 5 одновременно поднимает верхнюю планку software engineering и long-running work. Получилась бегущая лестница:

FEBRUARY
Sonnet 4.6 ───────
Opus 4.6   ─────────────

JULY
Sonnet 5   ──────────────
Opus 5     ───────────────────

Sonnet не сделала Opus ненужной. Возможности вчерашнего premium-tier стали массовыми, а новый Opus-tier ушёл дальше в сложность, неопределённость и длинный горизонт.

Не «слабее и сильнее», а default и escalation

Sonnet 5 больше не выглядит компромиссом, который выбирают только ради цены. Для bugfix, feature, migration, тестов и repository research она уже проходит нужный reliability threshold. Поэтому исходный вопрос меняется:

Не «почему я не использую Opus?», а «какое свойство этой задачи оправдывает дополнительный reasoning Opus?».

Для обычного API endpoint ответ часто будет «никакое». Sonnet исследует существующий pattern, добавит migration и service logic, запустит PHPUnit и PHPStan. Если итоговый diff небольшой и понятный, Opus не создаст заметной инженерной ценности.

В материале о Sonnet 5 как default я разбирал это на уровне одной session. После выхода Opus 5 следующий шаг — routing уже не всей задачи, а её отдельных этапов.

Routing начинается с риска, а не размера diff

Пятьсот строк CRUD могут быть предсказуемее двадцати строк в authentication layer. Поэтому количество файлов и оценка времени плохо выбирают модель.

Я бы смотрел на четыре признака:

COMPLEXITY
сколько взаимосвязанных решений

UNCERTAINTY
сколько business rules ещё неизвестно

RISK
что сломается при ошибке

RECOVERABILITY
можно ли безопасно откатить изменение

Обычный bug начинает Sonnet. Неизвестная race condition между payment workers может эскалироваться после research. Необратимая data migration или security incident сразу получает Opus: экономия model cost несоизмерима с ценой ошибки.

Хорошая эскалация передаёт Opus не сырой history, а context package: цель, constraints, подтверждённые факты, отвергнутые hypotheses, текущий diff и точку решения.

Одна PHP-задача, две модели

Возьмём migration большого Symfony-проекта с собственного PermissionService на Voters. Раньше вся работа целиком ушла бы одной модели. В июле её разумно разложить иначе.

SONNET 5
research permission paths
        ↓
OPUS 5
migration plan + invariants
        ↓
SONNET 5
implementation + tests
        ↓
OPUS 5
critical review
        ↓
HUMAN
accept risk and merge

Sonnet выполняет объёмную, но проверяемую работу: ищет controller checks, Twig conditions, API authorization и существующие tests. Opus тратит compute на две точки с высокой ценой ошибки — архитектурный план и проверку сохранения permission semantics.

Для маленькой feature такая схема избыточна. Там лучший orchestrator — короткий workflow Sonnet → tests → human review. Дополнительный handoff тоже стоит токенов, времени и риска потерять constraint.

Opus становится consultant и reviewer

Самая практичная архитектура не обязательно требует Opus-coordinator. Sonnet может вести task и вызвать Opus только при архитектурной неоднозначности. После рекомендации implementation снова возвращается в дешёвый execution layer.

SONNET COORDINATOR
├── Sonnet research worker
├── Sonnet test worker
└── hard decision
        ↓
      OPUS CONSULTANT

Второй сильный сценарий — независимый review. Sonnet приносит проверенный PR, Opus получает requirement и полный diff с инструкцией искать причины его отклонить, затем решение принимает человек.

Так Opus концентрируется на synthesis, contradiction и risk, а не оплачивает каждый grep. Но одно название модели не гарантирует независимость: reviewer должен иметь свежий context и отдельные инструкции, иначе он повторит assumptions implementer.

Sonnet делает multi-agent экономически практичным

Один agent скрывает цену routing. В системе из coordinator и пяти workers она становится архитектурной характеристикой. Запускать шесть Opus ради поиска usages, документации и test execution расточительно.

Именно поэтому Sonnet 5 может оказаться важнее для масштабирования agentic development. Она достаточно сильна для самостоятельного исполнения и достаточно экономична для параллельных workers.

Здесь вопрос «один Opus или пять Sonnet?» не имеет общего ответа. Связное архитектурное решение выигрывает от одного сильного context. Исследование огромного legacy repository естественно делится на authentication, database, cron, integrations и tests.

Cloud Subagents дают таким workers изолированные context и environment. Model routing добавляет ещё одно измерение: какой уровень reasoning оправдан конкретной ответственностью.

Выбор модели превращается в engineering policy

Правила routing можно хранить рядом с Skills и project instructions:

DEFAULT: SONNET

ESCALATE TO OPUS WHEN:
- security-sensitive change
- irreversible migration
- unclear legacy behavior
- cross-system contract
- repeated strategy failure

REVIEW WITH OPUS WHEN:
- high-risk PR
- architecture boundary changed

Это лучше магического confidence threshold. Наблюдаемые сигналы — повторные failures, растущий change surface, конфликт требований — можно проверить в execution trace.

Оценивать тоже нужно систему. Сравнение 100% Opus с 80% Sonnet + 20% Opus должно учитывать task completion, model cost, human attention, review time, latency и major rework. Победить может не самая сильная модель, а более точный routing.

За полгода изменилась единица выбора

В феврале разработчик выбирал Sonnet или Opus на всю задачу. В июле полезнее сначала спроектировать workflow, а затем распределить research, execution, reasoning и review между моделями.

FEBRUARY
TASK → MODEL

JULY
TASK → WORKFLOW → MODELS

Sonnet становится масштабируемым execution layer. Opus — точкой концентрации reasoning для неопределённых и дорогих решений. Это не вечные роли: следующее поколение снова сдвинет границу, а routing policy придётся обновить.

Логичный следующий этап — orchestrator, который выбирает compute сам. Разработчик задаёт цель, ограничения и risk policy; система решает, где достаточно Sonnet, а где пора подключить Opus. Тогда названия моделей превращаются из ручной настройки session в infrastructure primitives внутри engineering platform.