OmniRoute Auto Combo: бюджет Agent в 2026

В документации OmniRoute Auto Combo описано 14 стратегий маршрутизации, а режим auto/cheap по умолчанию ориентируется на минимальную стоимость, но это не равно жёсткому ограничению расходов. (документация Auto Combo) Поэтому для производственного AI Agent сначала задайте белый список моделей, затем установите бюджет запроса и только после этого выберите политику превышения: strict для немедленной блокировки или cheapest для разрешённого отката к самому дешёвому доступному кандидату. До общего доступа команды проверьте четыре отказа на одном тестовом клиенте.

Эта статья предназначена разработчикам, которые хотят ограничить стоимость одного запроса через OmniRoute Auto Combo. Она также пригодится платформенным инженерам, объединяющим несколько клиентов разработки под единым маршрутом, и удалённым командам, готовым перенести локальный шлюз в постоянно доступную среду.

До настройки разделите три уровня бюджета

Основная ошибка начинается с подмены разных ограничителей одним числом. В OmniRoute отдельно существуют:

Бюджет одного запроса — максимальная расчётная стоимость конкретного обращения к Auto Combo.
Лимит токенов API-ключа — ограничение по числу токенов за окно, например для одной модели, провайдера или ключа целиком.
Периодический денежный бюджет ключа — дневной, недельный или месячный предел с отслеживанием фактического использования.

В справочнике API денежный бюджет ключа и токеновые лимиты описаны как разные механизмы: первый использует поля dailyLimitUsd, weeklyLimitUsd и monthlyLimitUsd, а второй может применяться с областью model, provider или global. При достижении токенового предела OmniRoute отклоняет запрос с 429 Too Many Requests. (справочник API)

Это различие важно по трём причинам:

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

Перед созданием комбинации зафиксируйте для каждого типа Agent четыре решения:

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

Для финансово чувствительного производственного Agent безопасной базовой политикой является strict. Мягкий откат оставляйте для тестовых или низкорисковых задач, где задержка и доступность важнее точного потолка расходов.

Важное ограничение. Бюджет Auto Combo — это фильтр кандидатов по оценённой стоимости, а не гарантия точного списания до последней единицы валюты. Реальная сумма может зависеть от итогового числа входных и выходных токенов, настроек контекста и расчёта upstream-провайдера. Поэтому периодический бюджет ключа должен оставаться вторым уровнем защиты.

Первый этап: создайте короткий белый список

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

Начните с минимальной комбинации из моделей, которые уже прошли:

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

Количество моделей не следует использовать как показатель качества конфигурации. Важнее, чтобы у каждой записи было назначение:

Элемент конфигурации	Что зафиксировать	Если проверка не пройдена
Основная модель	Задачи, качество, ожидаемый профиль стоимости	Исключить из пула до повторной проверки
Резервная модель	Допустимое снижение качества и совместимость инструментов	Заменить только на заранее проверенный вариант
Модель для быстрых задач	Ограничения контекста и допустимые типы Agent	Не использовать для длинных автономных циклов
Идентификатор провайдера	Статус ключа, лимиты и время последней проверки	Отметить кандидата как временно недоступного
Причина выбора	Цена, задержка, качество или устойчивость	Добавить пояснение в журнал маршрута

Сохранённая комбинация должна содержать только проверенные кандидаты и понятный порядок возврата. Если основная модель недоступна, резервная должна быть не просто «дешевле», а совместима с форматом инструментов, потоковыми событиями и требуемым контекстом.

Вместо реальных данных используйте переменные:

export OMNIROUTE_URL="https://<OMNIROUTE_ENDPOINT>"
export OMNIROUTE_KEY="<TEST_API_KEY>"
export PRIMARY_MODEL="<PRIMARY_MODEL_ID>"
export FALLBACK_MODEL="<FALLBACK_MODEL_ID>"
export REQUEST_BUDGET_USD="<REQUEST_BUDGET_USD>"

Не подставляйте в общий репозиторий реальные ключи, внутренние адреса и значения бюджета. Для разных AI Agent лучше создавать отдельные ключи или отдельные прокси-профили. Так проще понять, какой клиент расходует лимит, и нельзя случайно перенести тестовую политику на всю команду.

Второй этап: задайте бюджет и режим превышения

В версии документации, проверенной для этой настройки, для Auto Combo используются два запроса уровня операции:

X-OmniRoute-Budget — положительное число, задающее максимальную стоимость запроса в долларах;
X-OmniRoute-Budget-Fallback — политика поведения, если все кандидаты превышают установленный потолок.

Документация указывает, что значения заголовков действуют только для запроса, который их содержит. Если заголовки отсутствуют, используются сохранённые параметры комбинации budgetCap и budgetFallback. Для жёсткой блокировки применяется strict; для прежнего мягкого поведения — cheapest. При strict запрос завершается с HTTP 402 вместо выбора кандидата, который всё ещё превышает бюджет. (описание бюджетного режима)

Пример одноразовой проверки:

curl -sS "$OMNIROUTE_URL/v1/chat/completions" \
  -H "Authorization: Bearer $OMNIROUTE_KEY" \
  -H "Content-Type: application/json" \
  -H "X-OmniRoute-Budget: $REQUEST_BUDGET_USD" \
  -H "X-OmniRoute-Budget-Fallback: strict" \
  -d '{
    "model": "auto",
    "messages": [
      {
        "role": "user",
        "content": "<TEST_PROMPT>"
      }
    ],
    "stream": false
  }'

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

Если приложение получает HTTP 402 и повторяет операцию самостоятельно, бюджетная политика может быть фактически обойдена на уровне клиента. В настройках Agent необходимо проверить:

число автоматических повторов;
изменение модели между попытками;
повторную отправку потокового запроса;
наличие собственной цепочки отката;
журналирование исходного и повторного запроса.

Для разных Agent устанавливайте бюджет через разные ключи, прокси-профили или передаваемые заголовки. Если клиент не умеет надёжно добавлять заголовок, сохранённая комбинация с budgetFallback: "strict" безопаснее, чем надежда на локальную настройку IDE или скрипта.

Почему превышение бюджета не всегда блокирует запрос

Если используется cheapest, Auto Combo может выбрать глобально самый дешёвый кандидат даже тогда, когда его расчётная стоимость выше заданного потолка. Это исторически совместимо с мягким откатом, но противоречит требованию «никогда не превышать бюджет». При strict OmniRoute не выбирает модель после того, как все кандидаты отфильтрованы по бюджету. (описание Auto Combo)

Решение для production Agent можно принять по условиям:

Если запрос можно безопасно отменить, используйте strict, возвращайте ошибку вызывающему сервису и показывайте оператору причину отказа.
Если задача допускает ухудшение качества, добавьте заранее проверенную недорогую модель в белый список и оставьте strict; тогда откат произойдёт не за пределы бюджета, а внутри допустимого пула.
Если важнее непрерывность тестовой среды, допускайте cheapest, но регистрируйте каждый случай выхода за потолок и не переносите такую политику в производственную комбинацию.
Если требуется разная стоимость для разных Agent, разделите ключи или сохранённые комбинации, а не используйте один общий лимит с неявным определением клиента.
Если нужно понять причину выбора, включите сбор журналов уровня запроса и сохраните идентификатор операции, стратегию, рассмотренных кандидатов и итоговую модель.

Именно так закрываются основные сценарии: превышение бюджета либо блокируется через strict, либо мягко обрабатывается через cheapest; разные Agent получают разные правила через раздельные уровни конфигурации; переход к более дорогой модели не происходит, если такой кандидат исключён белым списком и бюджетным фильтром.

Третий этап: проведите четыре отказных теста

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

Все кандидаты дороже потолка

Укажите бюджет ниже расчётной стоимости всех разрешённых моделей. Ожидается HTTP 402 при strict. Если возвращается успешный ответ, проверьте, не применился ли сохранённый режим cheapest, не был ли заголовок удалён обратным прокси и не изменил ли клиент запрос при повторе.

Первый поставщик недоступен

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

Учётные данные потеряли действительность

Сделайте отдельный тест с просроченным или отозванным ключом в изолированной среде. Здесь необходимо отличить ошибку аутентификации от превышения бюджета. Результат должен содержать понятный код или сообщение, а недействительный кандидат не должен бесконечно вызываться повторно.

Лимит или квота исчерпаны

Для токенового лимита ожидайте 429 Too Many Requests, поскольку этот механизм работает отдельно от долларового потолка запроса. В справочнике API также указано, что лимит может применяться к конкретной модели, провайдеру или ключу глобально, причём при совпадении нескольких правил действует наиболее строгое. (описание лимитов API)

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

Четвёртый этап: подключите один тестовый клиент

Не подключайте сразу всю команду. Выберите один тестовый клиент, который выполняет реальные операции Agent, но не влияет на производственные задачи. Сначала укажите совместимый OpenAI-style endpoint и тестовый ключ:

Адрес API: <OMNIROUTE_ENDPOINT>/v1
Ключ: <TEST_API_KEY>
Модель: auto
Название проекта: <PROJECT_NAME>

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

обычный короткий запрос без инструментов;
потоковая выдача;
вызов одного инструмента;
длинная задача с несколькими шагами;
превышение бюджета;
отказ основной модели;
повтор после HTTP 402 или HTTP 429.

На четвёртом шаге особенно часто обнаруживается скрытая проблема: клиентский Agent самостоятельно увеличивает контекст, повторяет неудачный вызов или отправляет новый запрос после частичного потокового ответа. Поэтому стоимость нужно оценивать не только по одной команде пользователя, но и по всей цепочке действий.

Для каждого теста сохраните:

время и идентификатор запроса;
применённый бюджет;
режим strict или cheapest;
выбранный кандидат;
причину выбора;
результат инструмента;
количество повторов;
итоговый код ответа.

Смысл маршрутизации не в том, чтобы всегда выбирать самую дешёвую модель, а в том, чтобы выбор оставался объяснимым и ограниченным заранее заданными условиями. Документация Auto Combo описывает динамическое оценивание кандидатов, а для анализа доступны сведения о стратегии и причине решения. (репозиторий OmniRoute)

Первая неделя: проведите серый запуск и настройте контроль

После успешных тестов увеличивайте доступ постепенно — по одному клиенту, проекту или участнику команды. Для каждого этапа сравнивайте не только среднюю стоимость, но и распределение маршрутов:

сколько запросов прошло к основной модели;
как часто использовался резерв;
сколько запросов заблокировано по бюджету;
сколько завершилось из-за лимита токенов;
сколько раз клиент повторил операцию;
изменилась ли доля длинных задач после подключения Auto Combo.

Полезно назначить три уровня реакции:

предупреждение — бюджет приближается к установленному порогу;
операционное вмешательство — резко растёт доля откатов или отказов;
блокировка — обнаружен выход за согласованный предел либо неизвестный кандидат.

Для периодического контроля OmniRoute предоставляет API бюджетов и журналы использования; отдельные endpoints предназначены для общих журналов, журналов уровня запроса и статуса бюджетов. (руководство пользователя) Конфигурацию следует хранить как версионируемый файл без секретов, а изменение списка моделей проводить через ревью. Обязательны также ручной откат и контакт ответственного оператора.

Если удалённой команде требуется постоянно доступный шлюз, не переносите конфигурацию в онлайн-среду до завершения недели наблюдений. Сначала зафиксируйте рабочий набор правил, затем оцените сетевую доступность, хранение секретов и способ резервного восстановления. Для такого сценария полезно заранее сравнить требования к облачной среде Mac и к локальному запуску OmniRoute.

Долгосрочное обслуживание: цена и доступность меняются

Исторически самый дешёвый кандидат не обязан оставаться самым выгодным. Могут измениться цена поставщика, доступная квота, состояние ключа, задержка, поддержка инструментов или качество длинных ответов. Поэтому Auto Combo нельзя настроить один раз и считать вопрос закрытым.

Минимальный цикл пересмотра включает:

проверку актуальной документации OmniRoute;
сверку схемы API и заголовков;
проверку журнала изменений версии;
повторный тест всех четырёх отказных сценариев;
сравнение фактического распределения маршрутов с ожидаемым;
проверку быстрого возврата к предыдущей комбинации.

Перед обновлением изучите историю релизов OmniRoute. Названия заголовков, псевдонимы режимов и значения по умолчанию могут измениться, поэтому старые примеры из командных чатов нельзя считать источником истины. Для каждой новой версии нужно заново проверить схему, сохранённые комбинации и реакцию на HTTP 402 и HTTP 429.

Текущая схема выбора достаточно ясна: белый список ограничивает пространство кандидатов, бюджетный заголовок ограничивает конкретный запрос, strict предотвращает выход за потолок, а журналы объясняют результат. Но каждый слой решает отдельную задачу. Нельзя заменить периодический бюджет ключа заголовком запроса, а нельзя считать мягкий cheapest эквивалентом финансовой блокировки.

Если OmniRoute пока работает на одном рабочем компьютере, у этого подхода есть реальные недостатки: шлюз недоступен при выключении устройства, сетевой адрес может быть нестабилен, а общий доступ для удалённых участников требует отдельного контроля ключей и резервного восстановления. Для нескольких постоянных пользователей практичнее заранее оценить варианты аренды Mac и тарифные конфигурации, сравнив их с самостоятельным поддержанием узла. Аренда Zilmac имеет смысл прежде всего как среда для временного тестирования, удалённого Agent или переходного этапа, а не как обязательная замена локальному серверу для любой команды.

Перед подключением постоянных пользователей стоит выполнить последний прогон на одном тестовом Agent: проверить блокировку по бюджету, объяснение маршрута, отказ поставщика и ситуацию без доступных кандидатов. Если все четыре результата соответствуют проектной политике, правила можно передавать команде; если хотя бы один сценарий приводит к неявному повтору или выбору более дорогой модели, конфигурацию следует вернуть на тестовый этап.