AIREITER28 октября 2026 года OpenRouter полностью переработал маршрутизацию по умолчанию: время до первого токена сократилось на 16,9%, общее число событий 429 — на 67%, а стоимость запросов выросла примерно на 6%. Автоматический выбор по-прежнему может незаметно отправить запрос к более дорогому провайдеру, поэтому важнее не громкие проценты, а понимание компромисса.
Новый роутер OpenRouter больше не выбирает провайдера только по минимальной цене входных токенов. Он оценивает реальную стоимость успешного ответа — цену, ожидание и повторные попытки — и направляет запрос туда, где Routing Cost оказывается ниже.
Короткий вывод и цифры
Теперь маршрутизация провайдеров OpenRouter оптимизируется по показателю Routing Cost, а не по цене токенов промпта. Изменение применяется автоматически, если в запросе явно не заданы provider.sort, provider.order, provider.only или provider.ignore. Оно касается примерно 77% трафика — запросов к моделям, которые обслуживаются несколькими провайдерами, согласно объявлению OpenRouter.
Результаты получены в ходе недельного switchback-теста на 24 млн запросов и 103 млрд входных токенов. Трафик поровну разделили между старым и новым роутерами.
| Показатель | Старый роутер | Новый роутер | Изменение* |
|---|---|---|---|
| TTFT p50 | 1 007 мс | 837 мс | на 16,9% ниже |
| Пропускная способность p50 | 62,4 токена/с | 72,6 токена/с | на 16,3% выше |
| Запросы хотя бы с одним 429 | 7,1% | 3,8% | на 3,3 п. п. ниже; всего событий 429 на 67% меньше |
| Запросы, потребовавшие повторной попытки | 10,4% | 6,9% | на 3,5 п. п. ниже; всего повторов на 47% меньше |
| Стоимость 1 000 запросов | $1.25 | $1.32 | на 6,0% выше |
| Стоимость 1 млн токенов | $0.301 | $0.324 | на 7,3% выше |
\*Доли запросов и сокращение числа событий приведены в объявлении OpenRouter: 67% и 47% относятся к общему числу событий 429 и повторных попыток, а не к отношению долей запросов, поскольку один запрос может столкнуться с несколькими ошибками.
Согласно объявлению, измеренный на стороне клиента TTFT p95 снизился с 6 032 мс до 4 504 мс, p50 для полного запроса — с 4,00 с до 3,24 с, а время, потерянное на неудачных попытках, — с 349 мс до 242 мс на запрос.
Итог простой: для интерактивного чата и агентов стоит оставить новый режим, если дополнительные ~6% расходов приемлемы. Для больших пакетных задач, где важна каждая копейка, лучше вернуться к маршрутизации только по цене.
Routing Cost без сложной математики
Routing Cost отвечает на два вопроса по каждому провайдеру: сколько стоит одна попытка и как часто она заканчивается успехом. В примере OpenRouter попытка за $0.40 и ожидание стоимостью $0.60 дают $1.00. Если успех достигается в 80% случаев, итоговая стоимость хорошего ответа составляет $1.25. Больше трафика получает провайдер с минимальным значением.
В расчёт входят три составляющие:
- Фактическая цена, а не цифра в прайс-листе. OpenRouter оценивает объём входных и выходных токенов по недавнему трафику, а затем учитывает реальную долю попаданий в кэш и цены токенов у каждого провайдера. Пример из объявления: 40 000 некэшированных входных токенов по $2.00/M ($0.080), 60 000 кэшированных по $0.50/M ($0.030) и около 4 000 выходных по $8.00/M ($0.032) — всего $0.142. Поэтому провайдер с дешёвыми входными токенами может потерять преимущество из-за дорогого кэша или вывода.
- Время ожидания, переведённое в деньги. Пропускная способность — это скорость генерации выходных токенов от начала до конца, включая время до первого токена. Например, 5 секунд до первого токена и ещё 500 токенов за 5 секунд дают 50 токенов/с. Роутер переводит ожидание в стоимость по ставке для конкретной модели, рассчитанной на основе типичных цен и скоростей провайдеров. TTFT получает дополнительный вес: в цепочках вызовов инструментов агент ждёт первый токен на каждом шаге.
- Цена сбоев. Ответ 429 означает, что провайдер отклонил запрос: приложение ждёт отказ, а затем отправляет запрос другому провайдеру. В примере ожидание 2.50 при штрафе и частоте 0.4% добавляет 0.01. Ошибки надёжности штрафуются сильнее — примерно в 8 раз: уровень ошибок 1% увеличивает стоимость примерно на 8%. Провайдеры, заметно уступающие остальным, временно перестают получать трафик до восстановления. Сейчас качество также проверяется по корректности вызовов инструментов: 95% корректных вызовов увеличивают стоимость примерно на 5%, а провайдеры с проблемами переводятся на тестовый объём трафика, согласно объявлению.
От полного ухода трафика к одному победителю защищают два механизма, описанные в объявлении: каждый провайдер получает небольшой поток запросов, чтобы система видела его восстановление, а при сбоях роутер снижает его долю, одновременно обучаясь индивидуальным ограничениям пропускной способности и отправляя излишек другим провайдерам.
Почему маршрутизация по умолчанию всё ещё создаёт проблемы в продакшене
Отзывы пользователей показывают четыре повторяющихся сценария, которые цена токенов сама по себе не отражает.
Переходы между провайдерами ломают вызовы инструментов
Именно переход посреди запроса в итоге сломал у меня вызовы инструментов, а не ценник какого-то отдельного провайдера.
— u/Michael_Jeffords, обсуждение провайдеров, которых стоит избегать, в r/openrouter
Сегодня проверка качества в основном учитывает корректность вызовов инструментов и флаги точности на бенчмарках, согласно объявлению. При этом переход посреди диалога всё ещё может изменить квантизацию или поведение при отказе: качество у провайдеров различается, а некоторые используют более агрессивно квантованные варианты моделей.
Сброс кэша раздувает счёт
В одном из обсуждений описан контекст размером около 700 000 токенов: ожидаемая стоимость кэшированных запросов составляла $0.20, но после смены провайдера они начали тарифицироваться почти по $2.00. Так возникает ситуация, когда пользователи «платят в 10–32 раза больше из-за сломанного кэширования». Новый роутер закрепляет диалог за исходным провайдером, пока кэш активен, и алгоритмически выбирает провайдера только для первого запроса, согласно описанию маршрутизации с учётом кэша OpenRouter. Однако при переходе на резервного провайдера привязка нарушается. Пользователи, которым удалось решить проблему, закрепляли одного провайдера через sticky-сессии.
Мне кажется, это довольно фундаментальный недостаток OR: всё приходится заранее настраивать вручную.
— u/welcome_to_milliways, обсуждение сломанного кэширования в r/openrouter
Незаметный переход на дорогой вариант
В одном отчёте о продакшене отмечалось, что часть трафика незаметно переключалась с Sonnet на Opus — примерно в 5 раз дороже заявленной цены. При этом мониторинг доступности оставался зелёным, а общие расходы выросли с $184/ч до $412/ч, по данным @CarbonOnX. Новый роутер делает этот компромисс явным: более быстрый и надёжный провайдер вполне может обойти самого дешёвого.
429 даже на платном аккаунте
Положительный баланс OpenRouter не увеличивает доступную мощность на стороне провайдера, как отмечают участники этого обсуждения о 429. Ошибка 429 означает, что для данной модели исчерпана общая очередь или квота провайдера. В тестах после переработки число событий 429 сократилось на 67%, но в продакшене по-прежнему может понадобиться закрепить другого провайдера или исключить ограниченного. Начните с материала как исправить ошибки 429 в OpenRouter, а за описанием прежнего режима маршрутизации с учётом цены обратитесь к руководству по OpenRouter Auto Router.
Три настройки маршрутизации, которые работают на практике
Выбор зависит от приоритета: скорость без ручного контроля, жёсткое ограничение расходов или предсказуемое поведение. Во всех случаях используется один и тот же объект provider: provider.order отключает новую логику и пробует провайдеров строго по заданному порядку, provider.only и provider.ignore сначала отфильтровывают кандидатов, после чего новый алгоритм выбирает среди оставшихся, а явный параметр provider.sort (price, throughput, latency) заменяет автоматический выбор.
1. Оставить новый режим по умолчанию — для чата и агентов
Менять код не нужно. Такой вариант подходит для пользовательского чата и многошаговых агентов, где каждый вызов инструмента ждёт первый токен. Взамен вы принимаете примерно 6% дополнительных расходов ради меньшей задержки и меньшего числа повторов. В течение недели записывайте провайдера, обслужившего запрос (он возвращается в ответе API и отображается на странице активности), вместе с TTFT p50 и долей 429. Если доля 429 держится около нового базового уровня ~4%, а попадания в кэш не ухудшаются, режим можно оставить. Если один провайдер даёт большинство сбоев или кэш почти перестаёт работать, переходите к третьему сценарию.
2. Зафиксировать самый дешёвый путь — для пакетных задач
Есть три способа предпочесть маршрутизацию по цене, когда расходы важнее скорости:
{ "provider": { "sort": "price" } }Также можно добавить к идентификатору модели суффикс :floor (meta-llama/llama-4-maverick:floor) или выбрать цену в качестве сортировки по умолчанию в настройках аккаунта, согласно FAQ объявления. Учтите: :floor также допускает endpoints гибкого уровня, тогда как обычный sort этого не делает, согласно руководству OpenRouter по маршрутизации.
Добавьте верхний предел стоимости:
{ "provider": { "sort": "price", "max_price": { "prompt": 1.0, "completion": 2.0 } } }Такой вариант подходит для больших промптов, коротких ответов и недорогих повторных попыток.
3. Закрепить стабильного провайдера — для продакшена с кэшем и инструментами
Закрепляйте провайдера, если корректность, попадания в кэш или требования комплаенса важнее оптимизации каждого отдельного запроса:
{
"provider": {
"order": ["deepinfra", "together"],
"allow_fallbacks": true,
"require_parameters": true
}
}require_parameters лишь исключает endpoints, в которых отсутствуют обязательные параметры запроса; он не гарантирует одинаковое поведение вызовов инструментов или схем у разных провайдеров. Используйте order вместе с allow_fallbacks: false в сценариях комплаенса или BYOK, где простой лучше, чем переход к неразрешённому провайдеру. Для большинства приложений оставляйте резервные варианты включёнными, сужайте список через only/ignore и передавайте стабильный session_id для повторного использования тёплого кэша (sticky-маршрутизация). Если провайдер работает нестабильно, заблокируйте его в защитных настройках и сравните прямые API провайдеров: несколько пользователей сообщали, что прямое подключение устранило задержки и проблемы с кэшем после выбора подходящей модели (пример обсуждения).
| Если вы… | Используйте | Почему |
|---|---|---|
| Прототипируете или обрабатываете смешанный трафик | Новый режим без настроек | В тестах меньше повторных попыток |
| Создаёте пользовательского агента | Новый режим + require_parameters | Сохраняет выигрыш по TTFT и исключает несовместимые endpoints |
| Запускаете ночные пакетные задачи на 100+ млн токенов | sort: price или :floor + max_price | Позволяет вернуть переплату в 6–7% |
| Работаете с длинным контекстом и кэшем | Закреплённый order + session_id | Предотвращает перерасчёт цены после промаха кэша |
Автоматическая маршрутизация стала лучше. Но если один неудачный переход обходится дороже, чем неделя немного более дорогих токенов, закрепление провайдера всё ещё остаётся правильным решением.
FAQ
Нужно ли менять код, чтобы использовать новую маршрутизацию?
Нет. Запросы без явных параметров provider sort, order, only или ignore автоматически используют новый роутер.
Как сохранить маршрутизацию только по цене?
Задайте provider.sort равным "price", добавьте :floor или выберите цену в качестве сортировки по умолчанию в аккаунте.
Переопределяет ли новая маршрутизация порядок провайдеров?
Нет. order отключает её; only/ignore сначала фильтруют список, после чего новый алгоритм выбирает провайдера.
Станет ли новая маршрутизация дороже?
Смотрите таблицу: в тестах стоимость 1 000 запросов выросла на 6,0%, а стоимость 1 млн токенов — на 7,3%.
Как узнать, какой провайдер фактически обработал запрос?
Проверьте поле provider в ответе API и страницу активности, как указано в документации OpenRouter.
Почему 429 появляется даже на платном аккаунте?
Причина — ограничения общей очереди провайдера, а не состояние вашего баланса. Закрепите другого провайдера или исключите того, кто упирается в лимит.