Claude Sonnet 4.6: нужна ли самая дорогая модель для программирования
Как выбирать модель по неопределённости, риску и роли в workflow вместо маршрутизации всего backlog в Opus.

Что вышло 17 февраля

17 февраля 2026 года Anthropic представила Claude Sonnet 4.6. Компания обновила coding, computer use, long-context reasoning и agent planning, добавила контекстное окно до 1 млн токенов в beta и сохранила стартовую API-цену Sonnet 4.5: $3 за миллион входных и $15 за миллион выходных токенов.

В ранних тестах Claude Code пользователи Anthropic предпочитали Sonnet 4.6 модели Sonnet 4.5 примерно в 70% случаев и Opus 4.5 — в 59%. Это результаты самой Anthropic, а не универсальный рейтинг, но продуктовый сигнал понятен: часть работы Opus-класса теперь можно выполнять более доступной моделью.

При этом компания не объявляет Opus 4.6 ненужным. В том же релизе он назван сильнейшим выбором для глубокого reasoning, codebase refactoring, координации нескольких агентов и задач, где цена неточности особенно высока. Практический вопрос поэтому звучит не «кто победил», а «где дополнительные вычисления меняют результат».

Самая сильная модель — плохой автоматический default

Рабочий день PHP-разработчика редко состоит из непрерывного проектирования сложных систем. В backlog есть DTO, validation rules, CRUD, feature-тесты, документация, локальные bugfix и небольшие migrations. Для них архитектурный маршрут уже задан проектом.

Если нужно добавить phone в существующую Filament-форму, более дорогая модель может написать тот же patch. Разница проявится в latency и стоимости agent loop, а не в качестве результата. На такой работе важнее найти соседнее поле, повторить conventions и запустить правильный тест.

Я бы начинал с Sonnet для ограниченных изменений с понятным образцом. Opus здесь остаётся резервом возможностей, за который workflow платит, но почти не использует.

Маршрутизировать нужно по неопределённости и риску

Название issue плохо предсказывает сложность. «CRUD контрактов» может означать четыре стандартных экрана, а может скрывать version history, сложные permissions, несколько database connections и старый публичный API. «Bugfix» бывает заменой опечатки и поиском race condition после refresh token.

Перед выбором модели я смотрю на пять признаков:

• насколько заранее понятна точка изменения;
• сколько компонентов и bounded contexts придётся связать;
• нужно ли принять архитектурное решение, а не повторить pattern;
• сколько циклов research → command → observation ожидается;
• какова цена ошибки для денег, доступа и данных.

MODEL NEED ≈ uncertainty + context + horizon + risk

Размер diff сам по себе слабый сигнал. Изменение комиссии может занимать 50 строк и заслуживать более строгого reasoning, чем безопасная генерация сотни однотипных тестовых fixtures.

Где Sonnet выглядит рациональным выбором

Представим Laravel 13-проект, в котором нужно добавить CRUD категорий. Рядом уже существуют Filament-ресурсы тегов и серий, структура папок зафиксирована, validation и feature-тесты имеют готовые примеры.

CategoryResource
├── Schemas/CategoryForm.php
├── Tables/CategoriesTable.php
└── Pages/
    ├── ListCategories.php
    ├── CreateCategory.php
    └── EditCategory.php

Агенту нужно исследовать один эталон, адаптировать поля, создать migration и доказать результат тестами. Предельный reasoning здесь менее важен, чем instruction following и согласованность с репозиторием. Sonnet-класс хорошо подходит именно для такого потока.

То же относится к тестам, если ожидаемые сценарии уже перечислены: успешный выпуск API-токена, validation error, unauthorized и превышение лимита. Дорогая модель не исправит расплывчатый Definition of Done, а точная постановка часто уравнивает результат моделей.

Неопределённый bug меняет экономику

Задача «пользователь иногда получает 401 после refresh token» не содержит точки правки. Причина может находиться в JWT rotation, кеше, middleware, database transaction или конкурентных запросах. Большая часть работы — не код, а построение и отбрасывание гипотез.

Но я всё равно не стал бы автоматически начинать с Opus. Sonnet может восстановить flow, воспроизвести проблему и собрать факты. Если root cause найден, та же сессия делает patch. Если две проверяемые гипотезы не дали результата или контекст пересекает несколько подсистем, задача эскалируется вместе с кратким исследовательским отчётом.

SONNET
research + reproduction
        ↓
root cause found?
├── yes → implement + test
└── no  → evidence summary → OPUS

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

Цена ошибки иногда важнее сложности

Небольшое изменение в billing, permissions, authentication или migration может иметь высокий blast radius. Здесь выбор модели определяется не объёмом кода, а стоимостью пропущенного edge case.

Для простой, но рискованной правки мне нравится связка:

Sonnet → implementation + tests
Opus   → independent review
Human  → decision and merge

Так Opus не тратится на поиск каждого файла и механическое редактирование, но применяется там, где дополнительный reasoning наиболее ценен: проверяет инварианты, regression risks, security и достаточность тестов. Для сложной и одновременно рискованной задачи Opus разумно подключить раньше — уже на research и architecture plan.

Модель можно выбирать для этапа, а не для всей задачи

Один issue не обязан целиком выполняться одной моделью. Большой рефакторинг можно разделить по характеру работы:

RESEARCH        Sonnet
ARCHITECTURE    Opus
IMPLEMENTATION  Sonnet
TESTING         Sonnet
FINAL REVIEW    Opus

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

Обратная схема тоже бывает полезна. Sonnet исследует legacy-модуль и возвращает карту flow, а Opus подключается только к найденному узлу с высокой неоднозначностью. Router должен реагировать на фактическую сложность, а не поддерживать красивую симметрию workflow.

У агента стоимость умножается на количество циклов

Обычный чат может ограничиться одним ответом. Coding agent читает файлы, ищет связи, вызывает shell, анализирует failure, редактирует код и повторяет тесты. Long-running задача проходит десятки таких циклов.

workflow cost =
cost per inference
× tool/reasoning steps
× agents and reviewers

В multi-agent системе разница масштабируется ещё быстрее. Назначить Opus планировщиком и финальным reviewer может быть оправданно. Запускать на Opus четырёх параллельных агентов для сбора файлов, написания стандартных тестов и форматирования — уже сомнительная экономика.

Latency влияет не меньше цены. Если модель дольше принимает решение на каждом шаге, медленнее становится весь feedback loop. Более быстрый агент иногда выигрывает за счёт дополнительных проверяемых итераций за то же рабочее время.

Миллион токенов не отменяет отбор контекста

Sonnet 4.6 получил beta-контекст до 1 млн токенов. Для большого репозитория это полезный запас: исходный код, тесты, документация и логи реже вытесняют друг друга из разговора.

Но возможность загрузить весь repository не означает, что это нужно делать. Случайные vendor-файлы, сгенерированные assets и нерелевантная история увеличивают стоимость и добавляют шум. Repository search, project rules и compaction остаются частью harness.

Я воспринимаю длинный контекст как страховку для найденных важных связей, а не как замену research. Хороший агент сначала определяет рабочий набор, затем удерживает его достаточно долго.

Простая routing policy для команды

Автоматический classifier для начала не нужен. Достаточно договориться о default и причинах эскалации:

DEFAULT
Sonnet 4.6

ESCALATE TO OPUS IF
- две проверяемые гипотезы не нашли root cause
- нужен architecture decision
- затронуто несколько bounded contexts
- migration трудно или невозможно откатить
- код связан с billing, auth или permissions
- требуется независимый deep review
- несколько agents нужно координировать одним планом

Эта policy не делает Sonnet «junior-разработчиком», а Opus — «архитектором». Поведение моделей нестабильно между задачами, и обе способны ошибиться в простой детали. Routing распределяет вычислительный ресурс, но не заменяет tests, constraints и человеческую ответственность.

Проверять нужно на своём backlog

Чтобы policy не осталась мнением, я бы взял шесть реальных задач: CRUD, набор feature-тестов, локальный bugfix, исследование legacy-модуля, большой refactoring и architecture review. Для каждого запуска фиксируются время, число tool calls, успешность внешних тестов, размер лишнего diff и объём человеческих исправлений.

Сначала все задачи получает Sonnet. Opus повторяет только случаи, где Sonnet не дошёл до приемлемого результата или потребовал много коррекций. Цель эксперимента — найти точку, где более дорогая модель действительно окупила себя, а не определить победителя «шесть из шести».

На одном PHP-проекте Sonnet может закрыть почти весь обычный backlog. В другом legacy-код и слабые тесты будут чаще требовать эскалации. Универсальная таблица из интернета этого не предскажет.

Модель становится выбираемым ресурсом

Sonnet 4.6 сокращает число задач, для которых Opus нужен по умолчанию. Это не повод объявлять модели взаимозаменяемыми. Anthropic сама оставляет Opus 4.6 для глубочайшего reasoning и работы, где особенно важно попасть в правильное решение.

Более зрелый workflow не ищет одну модель для всего. Он начинает с достаточно сильного и быстрого default, повышает capability после фактов из research и ставит дорогой reasoning в точки максимального риска — architecture и review.

Так model routing превращается из настройки интерфейса в инженерную policy. Вопрос уже не в том, какая модель «лучшая для PHP». Важнее знать, на каком этапе конкретной задачи дополнительная сила модели изменит решение.