# Fallback OpenRouter с пределом цены: как ограничить резервный маршрут

Как ограничить цену резервного маршрута OpenRouter: provider.max_price, единицы prompt/completion, совместимость целей, общий бюджет и отказ без подходящего endpoint.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/openrouter-fallback-price-cap/
Language: ru

Чтобы ограничить стоимость fallback в OpenRouter, нужно контролировать ставки допустимых исполнителей и полный бюджет задачи отдельно. Параметр цены маршрута не ограничивает автоматически длину диалога, количество попыток и все дополнительные функции приложения.

Материал проверен по официальным источникам 1 ноября 2026 года. Пример ниже показывает устройство ограничения, а не рекомендуемый тариф или актуальную цену какой-либо модели.

## Уточните единицу ограничения

[Provider Routing](https://openrouter.ai/docs/guides/routing/provider-selection) описывает `provider.max_price`. Для prompt и completion используются предельные ставки за миллион соответствующих токенов; для других компонентов предусмотрены свои поля. Единицу нужно подтвердить до переноса числа из сметы в конфигурацию.

Условный объект выглядит так:

```json
{
  "provider": {
    "max_price": { "prompt": 1, "completion": 2 }
  }
}
```

Числа иллюстрируют пределы ставок, а не стоимость одного запроса. Запрос с большим входом и продолжением будет иметь другой общий расход, чем короткий вызов при тех же разрешённых ставках.

## Сверьте весь резервный список

Запасная модель должна соответствовать требованиям качества, контекста, инструментов и обработки данных. [OpenRouter Limits](https://openrouter.ai/docs/api_reference/limits) дополнительно описывает ограничения расходов и активных запросов. Настройка маршрута работает внутри более широкой системы правил.

Для каждой цели запишите ставку, обязательные функции и причину включения. Не разрешайте резерву незаметно снимать ограничение цены или передавать данные в другой режим только ради получения любого успешного ответа. Если допустимой цели нет, понятный отказ может быть правильным результатом.

## Разделите ставку и сумму

| Ограничение | Что оно контролирует |
| --- | --- |
| `max_price` | Допустимую ставку соответствующего компонента маршрута |
| Размер входа и продолжения | Потенциальный объём одной операции |
| Число шагов и попыток | Объём всей задачи приложения |
| Бюджет ключа или рабочей области | Применимый общий предел использования |

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

## Испытайте два разных исхода

Условный пилот содержит обычный запрос с подходящим endpoint и запрос, для которого все разрешённые варианты исключены. Проверьте фактического исполнителя в первом случае и понятную обработку отказа во втором. Само присутствие JSON-поля в журнале не доказывает правильное применение политики.

Затем проверьте случай недоступности основной цели на согласованной тестовой конфигурации. Запишите, изменились ли модель, ставка, время ответа и прикладное качество. Итог нужен для выбора резервирования, а не для объявления универсального победителя среди провайдеров.

## Сверьте фактические расходы

После теста сопоставьте usage и начисления с выбранными ограничениями. Учитывайте другие компоненты операции отдельно. Расхождение следует объяснить до увеличения нагрузки, особенно если смета используется для финансирования постоянной GPU-инфраструктуры.

Дальше читайте о [полях only и order](/ru/journal/openrouter-provider-only-order/) и [полной стоимости роутинга](/ru/journal/token-router-total-cost/).