Комиссии OpenRouter BYOK, fallback и ротация ключей (2026)

Даже рабочий ключ OpenAI и успешный ответ API не гарантируют, что баланс OpenRouter останется нетронутым. В BYOK у OpenRouter несколько независимых денежных потоков: отдельно оплачиваются провайдер, комиссия платформы и резервная маршрутизация. Кроме того, прежнее правило про миллион запросов уже заменено новым.

Сначала выясните, за что именно списали деньги

OpenRouter BYOK позволяет выполнять запросы через учётные данные провайдера, сохранённые в вашем workspace, сохраняя OpenRouter в роли API-шлюза и маршрутизатора. В результате расходы могут идти по трём разным каналам:

Первый вопрос при диагностике — не «Добавил ли я свой ключ?», а «Какой провайдер фактически обработал этот запрос?». Настроенный ключ может не сработать из-за rate limit, недостатка средств у провайдера, прав доступа или временного сбоя. Если включён fallback, OpenRouter способен завершить запрос через другого провайдера и списать средства с баланса OpenRouter за этот маршрут — именно такой сценарий описан в материале поддержки о списаниях при BYOK.

Что даёт BYOK в OpenRouter — и чего он не меняет

BYOK направляет подходящие запросы через учётные данные вашего провайдера, но API-слой и маршрутизация остаются у OpenRouter. В документации BYOK OpenRouter указывает, что учётные данные шифруются и используются для запросов, направленных к указанному провайдеру.

BYOK не делает инференс бесплатным: провайдер всё равно учитывает потребление модели, а OpenRouter после применимого лимита может брать отдельную комиссию платформы. Собственный ключ также не отменяет правила приватности на уровне workspace, аккаунта или отдельного запроса. Если доступных endpoint больше не осталось, запрос завершится ошибкой, даже когда сами учётные данные корректны.

Текущая комиссия BYOK зависит от стоимости инференса, а не от числа запросов

На актуальной странице тарифов OpenRouter бесплатный лимит BYOK задан стоимостью инференса по прайс-листу, а не количеством запросов:

Лимит рассчитывается по тому, сколько та же модель у того же провайдера обычно стоила бы через OpenRouter, а не обязательно по вашей договорной цене в счёте провайдера. После исчерпания лимита 5% комиссии BYOK списываются с кредитов OpenRouter; счёт провайдера при этом остаётся отдельным.

Ведите три вида расходов раздельно

1. Стоимость инференса у провайдера: её оплачивает аккаунт провайдера, к которому относится BYOK-ключ.
2. Комиссия платформы BYOK: OpenRouter списывает 5% с кредитов после текущего лимита плана.
3. Стоимость инференса при fallback: кредиты OpenRouter оплачивают маршрут, который использовал мощности провайдера за счёт OpenRouter вместо исходного пути BYOK.

Комиссии за покупку кредитов учитываются отдельно: в тарифах OpenRouter указана платформая комиссия Pay-as-you-go в 5.5%. Списание при пополнении не доказывает, что конкретный запрос ушёл в fallback.

Почему в поиске до сих пор встречается ответ про 1 млн запросов

В анонсе OpenRouter от октября 2025 года говорилось об одном миллионе BYOK-запросов в месяц без комиссии платформы, после чего применялась комиссия 5%. Это была прежняя политика, описанная в датированном анонсе; теперь на странице отмечено, что цены BYOK изменились в августе 2026 года. Для расчётов используйте текущий лимит по стоимости инференса из прайс-листа и фиксируйте дату проверки.

Fallback определяет, станет ли BYOK жёсткой границей

По умолчанию OpenRouter стремится выполнить запрос успешно. В руководстве по BYOK приоритетные ключи, общие endpoint OpenRouter и fallback-ключи описаны как разные этапы маршрута:

• Приоритетные BYOK-ключи перебираются в заданном порядке.
• Если эти попытки неудачны, OpenRouter может обратиться к общим мощностям.
• BYOK-ключи, помеченные как fallback, пробуются после общих endpoint.
• Несколько подходящих ключей одного провайдера также могут проверяться по порядку.

Есть и нюанс с порядком провайдеров: подходящие endpoint BYOK пробуются раньше общих endpoint, даже если этот провайдер расположен позже в запрошенном массиве order. Поэтому BYOK-ключ может быть использован раньше, чем предполагает ваше общее правило порядка провайдеров.

Выбирайте между надёжностью и предсказуемым биллингом

Опция панели управления Always use for this provider не позволяет OpenRouter использовать его общие учётные данные для этого же провайдера. Но это не глобальный переключатель «никогда не тратить кредиты OpenRouter». В статье поддержки OpenRouter поясняет: запрос всё ещё может перейти с BYOK-ключа Anthropic к другому совместимому провайдеру, например Google Vertex, если разрешён межпровайдерский fallback.

Если важна определённость расходов, ограничивайте сам запрос:

{
  "model": "anthropic/claude-sonnet-4.5",
  "messages": [
    { "role": "user", "content": "Summarize this document." }
  ],
  "provider": {
    "only": ["anthropic"]
  }
}

При использовании provider.only сбой Anthropic станет ошибкой API, а не незаметным переходом к другому провайдеру. Это правильный вариант для регулируемых нагрузок, соглашений о данных с конкретным провайдером или отчётности, где каждый запрос обязан соответствовать одному upstream-аккаунту. Но для интерактивного продукта, в котором доступность важнее строгой привязки к провайдеру, это плохой вариант по умолчанию.

Пользователь r/openrouter описал этот же механизм:

«you can specify order/only providers in the request itself to force it to only use your BYOK ones.» — u/Randomdotmath, обсуждение на Reddit

Если fallback заложен в вашу стратегию надёжности, предусмотрите на него бюджет. Если нет — отключайте его на границе запроса.

Прежде чем винить комиссию, проверьте маршрут в Activity

Согласно FAQ OpenRouter, Activity показывает историю использования и позволяет фильтровать её по модели, провайдеру и API-ключу. Проверьте следующее:

1. Обслуживший провайдер: совпадает ли он с провайдером, к которому привязан ваш BYOK-ключ?
2. Модель и endpoint: не выбрал ли маршрутизатор другой совместимый endpoint?
3. API-ключ приложения: из какого окружения или workspace был отправлен запрос?
4. Списание кредитов: это затраты на инференс, комиссия BYOK или изменение баланса, связанное с пополнением?

Если провайдер в Activity отличается от провайдера BYOK, сначала исследуйте fallback, а не меняйте учётные данные. Если провайдер совпадает, а объём близок к лимиту плана, проверьте комиссию платформы BYOK. Такой подход избавляет от ротации валидного ключа ради решения проблемы в политике маршрутизации.

Схема ключей для production, которая переживёт ротацию

Ключ приложения OpenRouter и upstream-учётные данные BYOK — это разные секреты, за которые отвечают разные владельцы:

Как настроить и проверить учётные данные BYOK

Прежде чем разбираться с production-трафиком, пройдите короткий путь настройки:

1. Добавьте учётные данные провайдера в настройках BYOK workspace или создайте их через API управления BYOK.
2. Дайте ключу имя, в котором понятны провайдер, окружение и назначение.
3. До предоставления доступа к общему ключу workspace примените фильтры по моделям, API-ключам OpenRouter или участникам.
4. Поместите ключ в приоритетный раздел; fallback-ключ добавляйте только когда его роль в биллинге и при сбоях явно определена.
5. Отправьте тестовый запрос, посмотрите в Activity обслужившего провайдера и затем решите, должен ли оставаться включённым shared fallback.

Для облачных провайдеров учётные данные не взаимозаменяемы:

Эти ограничения приведены в документации OpenRouter по BYOK для конкретных провайдеров. Валидный секрет с неверным типом ресурса, регионом, deployment или правами означает ошибку конфигурации, а не отсутствие поддержки BYOK.

Настройки BYOK в OpenRouter поддерживают фильтры по slug моделей, хешам API-ключей OpenRouter и участникам workspace. Чтобы учётные данные могли участвовать в маршрутизации, должен совпасть каждый активный фильтр; документация допускает до 100 записей в одном фильтре. Используйте явные allowlist и разделяйте крупные команды по workspace, а не расширяйте до бесконечности один общий ключ.

Ротация ключа приложения OpenRouter без замены ключей провайдера

В рецепте по ротации API-ключей OpenRouter указано, что учётные данные BYOK-провайдеров привязаны к аккаунту OpenRouter, а не к конкретному ключу приложения. Последовательность без простоя выглядит так:

1. Создайте новый API-ключ приложения OpenRouter с понятным именем и подходящим лимитом.
2. Сохраните его в менеджере секретов и разверните во всех сервисах, задачах и окружениях, где используется старый ключ.
3. Подтвердите в Activity, что production-трафик использует новый ключ.
4. Удаляйте старый ключ только после полного завершения миграции.

В документации Management API сказано, что ключи Management API являются административными учётными данными и не могут вызывать endpoint completions. Новый ключ должен быть доступен до отзыва старого ключа приложения.

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

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

1. Создайте новые учётные данные у провайдера с минимально необходимыми правами.
2. Добавьте их в подключение OpenRouter BYOK под отдельным именем и с контролируемым приоритетом.
3. Отправьте тестовый запрос и проверьте Activity.
4. Переведите новые учётные данные в основную позицию и отслеживайте ошибки и использование у провайдера.
5. После периода перекрытия отзовите старые учётные данные у провайдера.

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

Когда BYOK в OpenRouter не стоит делать вариантом по умолчанию

Прямой доступ к API провайдера лучше подходит в случаях, когда важнее единая нативная диагностика, точное поведение endpoint или инструменты конкретного вендора. BYOK выигрывает, если вы работаете с несколькими аккаунтами провайдеров, уже имеющимися кредитами или зарезервированными мощностями, а также нуждаетесь в контроле на уровне workspace.

FAQ по OpenRouter BYOK

Берёт ли OpenRouter деньги, если я использую собственный ключ?

Да. Провайдер может выставить счёт за инференс через учётные данные BYOK; после текущего лимита плана OpenRouter может списать с кредитов комиссию платформы BYOK в 5%; а fallback способен направить оплату маршрута другого провайдера на кредиты OpenRouter.

Отключает ли «Always use for this provider» весь fallback?

Нет. Настройка запрещает OpenRouter использовать собственные общие учётные данные для названного провайдера, но не исключает переход запроса к другому совместимому провайдеру. Если межпровайдерский маршрут должен быть невозможен, используйте provider.only.

Как enterprise-команде обеспечить безопасность BYOK и контролировать бюджеты?

OpenRouter сообщает, что учётные данные шифруются, исходные ключи провайдеров не возвращаются через Management API, а расходы BYOK по умолчанию не учитываются в guardrail- и workspace-бюджетах. В документации BYOK указано: для общего бюджета включите Include BYOK spend или include_byok_in_budgets. Enterprise-командам также стоит использовать ключи с минимальными правами, разделение по workspace, фильтры, хранение в менеджере секретов, ротацию и проверку Activity.

Настройка по умолчанию должна соответствовать сбою, который вы готовы принять

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