Sonnet доходит до уровня agentic default
30 июня Anthropic представила Claude Sonnet 5. Компания называет её самой agentic-моделью линейки Sonnet: она планирует работу, использует браузер и терминал и достаточно долго действует автономно. Ещё несколько месяцев назад такой набор возможностей чаще связывали с более крупными моделями Opus.
В официальном анонсе Sonnet 5 сказано, что на задачах с повышенным reasoning effort модель в некоторых случаях приближается к Opus 4.8. Ключевая оговорка — в некоторых. Это не означает равенства на любой архитектурной или legacy-задаче.
Но для обычного разработчика важнее не абсолютный лидер benchmark. Важнее порог достаточности:
TASK REQUIREMENT
↓
модель проходит порог
надёжности?
↓
если да — дополнительная
мощность не создаёт ценностиХорошая default-модель должна быть не максимально сильной, а достаточно надёжной для большей части рабочего потока.
У повседневной задачи есть конечный порог сложности
Типичная Symfony feature уже требует полноценного agentic loop. Агент находит существующий API, прослеживает authorization, меняет application logic, добавляет test и запускает PHPStan. Это больше, чем генерация метода, но границы задачи обычно понятны.
Если Sonnet 5 уверенно проходит цепочку:
RESEARCH
↓
PLAN
↓
IMPLEMENT
↓
TEST
↓
REVIEWOpus может сделать те же шаги немного лучше и всё равно не изменить практический результат: обе сессии закончатся небольшим mergeable diff. Поэтому вопрос «какая модель сильнее?» стоит заменить на «какая модель дешевле проходит нужный reliability threshold?».
Это продолжает логику февральского сравнения Sonnet 4.6 и Opus 4.6, но граница сдвинулась. Возможности, которые раньше были premium-классом, становятся нормой для более массовой модели.
Sonnet — default, Opus — escalation
Для большинства bugfix, feature, migration, тестов и локальных refactoring я бы начинал с Sonnet 5. Opus 4.8 превращается не в постоянный режим, а в следующий уровень:
TASK
↓
SONNET 5
│
├── evidence найдено → продолжить
│
└── высокая неоднозначность
или повторные ошибки
↓
OPUS 4.8Такой routing полезнее жёсткого деления «80% на 20%». Сложность часто становится видна только после исследования repository. На старте bug выглядит локальным, а через двадцать минут обнаруживаются два background job, старый integration account и противоречащие друг другу business rules.
Сигналами для escalation могут быть:
- несколько неподтверждённых hypotheses подряд;
- diff растёт быстрее, чем понимание причины;
- тесты указывают на ошибку исходной стратегии, а не одной строки;
- решение меняет контракт между системами;
- неоднозначность требует архитектурного или доменного judgment.
Передача должна включать не весь сырой terminal log, а короткий пакет: цель, constraints, проверенные факты, отвергнутые варианты, текущий diff и открытый вопрос.
Где Opus всё ещё оправдывает стоимость
Я бы сразу выбрал Opus для миграционной стратегии multi-tenant, большого cross-system refactoring или расследования в legacy без нормальных tests. Здесь ошибка в первоначальной модели системы распространяется на десятки последующих решений.
Показательный сценарий — проект из материала об Opus 4.8 и большом legacy PHP: скрытые cron jobs, несколько entry points и правила, которые выглядят как случайный код. Дополнительное исследование до изменения может стоить дешевле неверного refactoring.
Ещё одна разумная роль Opus — критический reviewer. Sonnet исследует, реализует и тестирует, затем более сильная модель получает requirement и полный diff с инструкцией искать причины не принимать изменение. Максимальный reasoning budget расходуется там, где цена пропущенной ошибки особенно высока.
Это не отменяет human review. Sonnet и Opus могут разделять один blind spot, а решение о допустимом риске остаётся у команды.
Считать нужно Total Engineering Cost
На дату релиза Sonnet 5 получила вводную цену $2 за миллион входных и $10 за миллион выходных токенов до конца августа; Opus 4.8 стоила $5 и $25 соответственно. Но цена токена не равна цене решённой задачи. Anthropic отдельно предупреждает, что обновлённая tokenization может менять количество токенов для того же input.
Практическая формула шире:
TOTAL ENGINEERING COST
= model cost
+ human attention
+ review time
+ reworkДешёвая сессия, которую шесть раз направляли и затем час переписывали, обходится дороже автономной Opus-сессии. На простом bug разницы может не быть — тогда Sonnet выигрывает. На неоднозначном legacy-инциденте более медленная и дорогая Opus может сократить общее время до доверия.
Поэтому полезная единица учёта — не миллион токенов, а принятая задача: сколько стоил agent run, сколько минут внимания потребовал и был ли PR принят без major rework.
В multi-agent workflow модели можно разводить по ролям
При нескольких agents использование Opus в каждом worker быстро умножает стоимость. При этом поиск usages, запуск тестов и подготовка документации редко требуют максимальной модели.
SONNET
├── repository research
├── implementation
├── test execution
└── documentation
OPUS
├── architecture decision
├── difficult synthesis
└── critical reviewЭто не универсальная иерархия. Coordinator для простой feature тоже может быть Sonnet, а worker, исследующий критичную платёжную гонку, может сразу получить Opus. Маршрутизировать нужно по ответственности и цене ошибки, а не по названию роли.
Особенно интересна модель consultant: Sonnet выполняет обычную работу и вызывает Opus только при архитектурной неоднозначности. После рекомендации дешёвая модель продолжает implementation и verification. Frontier compute становится редким ресурсом для трудного решения, а не фоном каждого grep.
Как проверить это на PHP-проекте
Я бы дал Sonnet 5 и Opus 4.8 одинаковый Symfony repository, одинаковые инструкции и пять задач: обычный bug, API feature, permission refactoring, legacy investigation и архитектурную migration strategy.
Финальная таблица должна содержать не только task completion:
human interventions
supervision minutes
wrong turns
review time
major rework
model cost
total engineering costРезультатом будет не один победитель, а карта границ. Sonnet может уверенно закрыть bug и feature, обе модели — refactoring, а Opus показать преимущество на legacy и architecture. Такая карта полезнее общего benchmark score, потому что подсказывает реальное правило routing.
Нужен доступ к Opus, а не Opus в каждой задаче
После Sonnet 5 обычному разработчику, вероятно, не нужна Opus-модель постоянно. Для повседневного PHP-workflow Sonnet выглядит естественным default: достаточно автономным, быстрым и экономичным, чтобы вести task от исследования до проверенного diff.
Но доступ к Opus остаётся полезным как escalation layer: для неясной архитектуры, большого legacy, высокой цены ошибки и независимого глубокого review. Зрелый выбор модели выглядит не как верность одному tier, а как управление инженерным бюджетом.
Главный вопрос уже не «какая модель лучшая?», а «какой минимальный уровень модели надёжно доведёт именно эту часть работы до результата?».
Следующий шаг — автоматический routing. Когда система видит повторные failures, рост change surface или низкую уверенность в business rule, она сама может подключить более сильную модель. Тогда разработчик проектирует не один AI-инструмент, а набор исполнителей с понятными правилами escalation.
