У Router есть соблазнительная кнопка: «выбери модель за меня». Она снимает спор из Slack, но не снимает ответственность за результат. Автоматическая маршрутизация полезна только тогда, когда команда может доказать, что Router оптимизирует именно её задачу, а не чужую популярность.
OpenRouter запустил Auto Router Beta: он классифицирует запрос и направляет его в популярную для этого класса модель с учётом выбранного компромисса цена–качество. Одновременно появился o— инструмент, который строит Eval на реальных вызовах приложения и сравнивает модели при зафиксированном Harness.
Вместе эти релизы отвечают на два разных вопроса: Auto Router решает в runtime, Ori Eval проверяет решение до production.
Что Auto Router делает на самом деле
Модель вызывается через slug openrouter/auto-beta. Router классифицирует запрос, выбирает модель, а стоимость ответа равна тарифу фактически использованной модели. Название можно увидеть в поле model ответа и Activity.
Auto Router не создаёт фиксированный прайс. Ваш бюджет зависит от распределения задач и моделей, которые Router выбрал.
Три ситуации, где Auto Router разумен
1. Разнообразный длинный хвост. Приложение получает код, переводы, изображения и анализ, но ни одна категория не доминирует.
2. Exploration. Команда ещё не знает, какие модели подходят, и собирает данные о реальном трафике.
3. Некритичный consumer UX. Небольшое изменение стиля или задержки не нарушает бизнес-контракт.
Где автоматический выбор опасен
Сценарий | Почему нужен фиксированный профиль |
Финансовый отчёт | Необходима воспроизводимость и утверждённая модель |
Structured Output | Разные модели по-разному держат Schema |
Tool Calling | Ошибка аргумента может вызвать реальное действие |
Регулируемые данные | Маршрут ограничен политикой провайдера и региона |
Жёсткий SLA | Нужны предсказуемые latency и rate limits |
Почему «самая популярная модель для задачи» — не всегда ваша
Агрегированный расход отражает выбор рынка, но не ваш русский Support, ваши Tool Schemas и ваш стиль кода. Популярность — полезный prior, не доказательство.
Проверка должна использовать реальные примеры. OpenRouter пишет, что Ori Eval фиксирует Harness и модель, проверяет вызванные и запрещённые Tools, а открытые ответы оценивает LLM Judge. Результат можно хранить как *.eval.ts и запускать в CI.
Эксперимент на неделю
10% трафика → Auto Router
90% трафика → текущая фиксированная модель
Сравнить:
- success по бизнес-критерию;
- p50/p95 latency;
- стоимость принятой задачи;
- Schema и Tool Call errors;
- распределение выбранных моделей;
- долю запросов, где маршрут нельзя объяснить.
Не сравнивайте только средний Score. Auto Router может улучшить середину и ухудшить редкие дорогие случаи.
Auto Router или собственные правила
Начните с Auto Router, если задача неизвестна. Перейдите к собственным профилям, когда накопились стабильные категории. Оставьте автоматический слой для длинного хвоста, а ключевые маршруты закрепите.
OdiRouter.ai и другие OpenAI-compatible gateways позволяют реализовать явные профили и сравнивать модели через единый интерфейс. Важен не бренд Router, а наличие Trace: входной класс, выбранная модель, причина, стоимость и результат.
Auto Router полезен не потому, что знает «лучшую модель». Он снижает цену начального выбора. Ori Eval полезен потому, что превращает выбор обратно в проверяемое инженерное решение.
Автоматизировать можно маршрут. Критерий успеха всё равно должна определить команда.