Какую модель дать агенту: метрики вместо интуиции

Проблема

Запускаешь команду из трёх агентов. Одному даёшь opus, другому sonnet, третьему haiku. Почему именно так? Потому что “opus — умный, haiku — дешёвый”. Интуиция вместо данных.

Мы собрали бенчмарки, изучили паттерны маршрутизации в реальных системах и нашли несколько контринтуитивных результатов. Главный: выбор модели — это не вопрос “умнее/дешевле”. Это вопрос контекста задачи.

Контекст

Когда работаешь с одной моделью, выбор не стоит. Когда запускаешь пять параллельных агентов — каждый неправильный выбор умножается. Opus на задаче “посчитай файлы в директории” — выброшенные деньги. Haiku на задаче “спланируй архитектуру” — выброшенное время и токены на переделку.

Проблема усугубляется тем, что бенчмарки не отражают агентную реальность. SWE-bench измеряет решение GitHub-issues, но не измеряет надёжность вызова инструментов в цикле из 50 шагов. А именно там модели ломаются по-разному.

Мы провели исследование по трём направлениям: бенчмарки Anthropic, паттерны маршрутизации в существующих системах (oh-my-claudecode, claude-flow, RouteLLM), и практические failure modes каждой модели в агентных workflow.

Решение

Sonnet 4.6 ≈ Opus 4.6 на большинстве агентных задач

Это главный сюрприз из бенчмарков. На задачах, релевантных для кодинг-агентов, разница минимальна:

OSWorld (управление десктопом):  Sonnet 72.5% vs Opus 72.7%
SWE-bench (GitHub issues):       Sonnet 79.6% vs Opus 80.8%
TAU-bench retail (агентные):     Sonnet 91.7% vs Opus 91.9%
GDPVal (офисные задачи, Elo):    Sonnet 1633  vs Opus 1606

Sonnet даже обгоняет Opus на GDPVal и MCP Atlas (оркестрация инструментов: 61.3% vs 59.5%). Opus лидирует убедительно только на глубоком рассуждении: GPQA Diamond 91.3% vs 74.1%, ARC-AGI-2 68.8% vs 58.3%.

Opus может быть дешевле Sonnet

Самый контринтуитивный результат. Opus использует на 48-76% меньше токенов, чем Sonnet на сложных задачах. Там, где Sonnet генерирует 500 токенов, Opus решает ту же задачу за ~120.

При ценах $25 (Opus output) vs $15 (Sonnet output) за миллион токенов: если Opus тратит вдвое меньше токенов, итоговая стоимость примерно одинакова. А с учётом того, что Opus чаще решает с первой попытки (без retry-циклов), на сложных задачах он может выходить дешевле.

Это работает только для задач, требующих рассуждения: архитектура, ревью, планирование. На механических задачах Opus просто дороже без выгоды.

Haiku опасен для агентных задач

У Haiku 4.5 есть подтверждённый баг (GitHub issue #10029): модель входит в бесконечные циклы вызовов инструментов. Вызывает read_file на тот же файл снова и снова, игнорируя feedback “этот инструмент уже вызван”. Модель не обновляет внутреннее состояние на основе результатов.

Дополнительные проблемы:

First-try tool success: 87% у Haiku vs 94% у Sonnet
Деградация после 75 ходов в разговоре
Нет adaptive thinking (не может динамически увеличить глубину рассуждения)
Планирование в 3-4 раза менее детальное, чем у Sonnet

Haiku безопасен ровно для одного класса задач: stateless одношаговые операции. Посчитать строки, найти файл, отформатировать текст. Всё, что требует состояния между вызовами инструментов — Sonnet minimum.

Статическая маршрутизация побеждает

oh-my-claudecode, claude-flow, и практически все production-системы используют один и тот же паттерн: модель назначается по роли агента, а не по анализу каждого запроса.

Haiku  → retrieval, formatting (механика)
Sonnet → implementation, research, debugging (объём)
Opus   → architecture, review, planning (суждение)

Существуют динамические роутеры (RouteLLM, Martian, Not Diamond), которые анализируют каждый запрос и выбирают модель. Они снижают стоимость на 40-85% при сохранении 95% качества. Но требуют training data и инфраструктуру. Для агентных команд из 3-5 участников static routing проще и достаточен.

Интересная находка из проекта Anthropic по созданию C-компилятора (16 агентов, 100K строк кода, ~2000 сессий): они использовали Opus для всех 16 агентов. Без model routing вообще. Специализация была по функции (лексер, парсер, оптимизация), а не по модели.

Три правила для выбора

Задача требует суждения (корректность, trade-offs, архитектура)? Opus.

Задача требует объёма (чтение, написание, код, исследование)? Sonnet.

Задача чисто механическая и одношаговая? Haiku.

При сомнении — Sonnet. Haiku провалится молча, Opus будет overkill. Sonnet покрывает ~90% агентных задач с лучшим соотношением цены и надёжности.

Инсайт

Выбор модели — это задача context engineering. Не “какая модель умнее”, а “какой контекст получит этот агент и что от него требуется”.

Исследование AgentIF (Tsinghua, EMNLP 2025) показало: даже лучшие модели выполняют менее 30% сложных агентных инструкций безошибочно. Разница между Sonnet и Opus на этом фоне — шум. Что действительно определяет результат — качество декомпозиции задачи, чёткость промпта и правильные границы ответственности агента.

Модель — это ресурс. Как CPU time или память. Её нужно аллоцировать по потребности задачи, а не по престижу названия.