provod.ai
← Все статьи
Новости11 мин чтения

OpenRouter модели: ключ, бесплатные лимиты и выбор маршрута для критичного сценария

Каталог OpenRouter обещает выбор, но маршрут становится инженерным решением только после проверки на одном обязательном сценарии. Разбираем ключ, бесплатные лимиты и route-scorecard.

Обложка статьи: OpenRouter модели: ключ, бесплатные лимиты и выбор маршрута для критичного сценария

Бесплатная модель в каталоге ещё не означает, что она годится именно для того запроса, который должен выполнить твой прототип. Строка есть, ключ выпущен, :free-вариант доступен, а обязательная функция всё равно падает, потому что модель не держит нужный формат ответа или упирается в лимит на середине потока.

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

Дальше пойдёт метод, а не рейтинг. Мы соберём route-scorecard: таблицу «критичный сценарий—кандидат—подтверждённый режим—лимит—статус—решение», которая фиксирует поля каждого кандидата на дату прогона и допускает к прототипу только тот маршрут, чьё покрытие подтверждено.

Платите в рублях за AI-модели без наценки на токены через provod.ai

Чем каталог отличается от инженерного маршрута?

Каталог OpenRouter — это более 400 моделей, которые можно запросить через /api/v1/models с фильтрами вроде supported_parameters=tools или output_modalities=text,image (документация OpenRouter, раздел models, доступ 18 июля 2026). Каждая запись отдаёт id, context_length, pricing, architecture с модальностями входа и выхода и отдельное поле с датой депрекации. То есть метаданные каталога уже сами по себе различают «показано в списке» и «активно поддерживается дальше».

Наличие ключа тоже не тождественно готовности. openrouter api key — это Bearer-токен, который выпускается на странице openrouter.ai/keys, и у каждого отдельного api key openrouter может быть свой лимит расходов, отличный от баланса аккаунта (документация OpenRouter, раздел authentication). Если прототип работает в нескольких окружениях, openrouter api keys можно выпускать по одному на каждое: staging, продакшен, тестовый скрипт, и настраивать лимит расходов для каждого отдельно. Поэтому важно фиксировать отдельно два факта: ключ существует и ключ авторизован под бюджет именно этого приложения.

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

Диагностический маршрут: от каталога и ключа через прогон кандидата к решению о допуске.

Шесть полей route-scorecard

Scorecard устроен иначе, чем рейтинг «лучших моделей»: это таблица допуска. Один критичный сценарий на входе, один набор кандидатов, шесть полей на каждого. Смысл в том, чтобы решение о допуске маршрута опиралось на подтверждённые поля, а не на видимость строки в списке.

Возьмём конкретный обязательный сценарий, на котором большинство прототипов и спотыкается: функция должна вернуть строгий JSON по схеме, и ответ приходит потоком. Здесь сходятся сразу два узких места. Структурированный вывод требует response_format.type = "json_schema", и поддержка есть не у всех моделей: её нужно проверять по каждой через фильтр supported_parameters=structured_outputs, а флаг require_parameters: true нужен, чтобы OpenRouter молча не откатился к более слабому режиму json_object на провайдерах без полной поддержки схемы (документация OpenRouter, раздел structured outputs). Потоковый режим добавляет вторую ловушку: если лимит сработает в середине стрима, это придёт не как HTTP-статус, а как SSE-событие с finish_reason: "error" (документация OpenRouter, раздел limits). Для сценария, который стримит обязательный JSON, это ломающая деталь.

Поля scorecard я держу такими:

  • критичный сценарий: что именно должно получиться (здесь: валидный JSON по схеме, потоком);
  • кандидат: конкретный id модели и провайдер маршрута;
  • подтверждённый режим: какие возможности реально подтверждены для этого маршрута (structured_outputs, tools, стриминг);
  • лимит: актуальное состояние по ключу и тарифу на момент проверки;
  • статус: допущен / исключён / требует повторной проверки;
  • решение и причина исключения: одна строка, почему.
Route-scorecard с шестью полями: сценарий, кандидат, подтверждённый режим, лимит, статус, решение.

Строки в этой таблице — шаблон, а не готовый бенчмарк: я не прогонял конкретные живые модели под этот сценарий и не выдаю чужие цифры за свой замер. Подтверждены здесь сами поля и механики платформы. Работа таблицы в другом: она не даёт поставить в графе «решение» слово «допущен», пока каждое поле не закрыто фактом на дату прогона.

Почему бесплатный статус — изменяемый параметр, а не основание решения?

Здесь ошибаются чаще всего. openrouter free api устроен как отдельный роутер openrouter/free, который случайно выбирает среди перечисленных :free-моделей (23 на момент доступа 18 июля 2026) и «умно фильтрует» кандидатов под нужные запросу возможности: понимание изображений, вызов инструментов, структурированный вывод (документация OpenRouter, страница openrouter/free). Тот, кто ищет openrouter ai free models или openrouter ai бесплатные модели, обычно рассчитывает получить готовый список подходящих моделей, но ключевое здесь слово «фильтрует под возможности»: присутствие модели на бесплатном роутере само по себе не гарантирует, что она поддерживает нужный сценарию режим входа или выхода.

Дальше идут лимиты. Бесплатные варианты ограничены 20 запросами в минуту, суточный потолок составляет 50 запросов, если аккаунт за всё время купил кредитов меньше чем на $10, и он навсегда поднимается до 1000 в день, как только когда-либо было куплено на $10 или больше (документация OpenRouter, раздел limits). Порог не отматывается назад, даже если баланс потом упал до нуля. Отдельного типа ключа для бесплатного доступа не существует: openrouter free api key технически тот же Bearer-токен, что и обычный, а тариф определяется историей покупок аккаунта, а не видом ключа. По той же причине вопрос openrouter api key бесплатно сводится не к получению особого ключа, а к тому, пересёк ли аккаунт порог в $10 совокупных покупок. То есть бесплатный тариф — это не один режим, а вилка, зависящая от истории аккаунта.

И статусы моделей тоже подвижны. Собственная инженерная заметка OpenRouter говорит, что за последние годы провайдеры сняли или депрецировали более 70 моделей, и рекомендует не зашивать жёсткие слаги, а держать упорядоченный массив models или пресет для фолбэка (инженерный блог OpenRouter). На этом и стоит весь метод: free-статус остаётся изменяемым параметром прогона, а не основанием для решения. Ты фиксируешь его в графе «лимит» на дату проверки и относишься к нему как к тому, что может измениться к следующему запуску. На вопрос openrouter ai как пользоваться бесплатно есть короткий ответ: до порога в $10 совокупных покупок это 50 запросов в день на аккаунт, после — 1000, и оба значения нужно перепроверять на дату прогона, а не запоминать раз и навсегда.

Столбчатая диаграмма лимитов: 20 запросов в минуту, 50 в день до порога 10 долларов и 1000 в день после.

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

Проверять нужно ровно в день прогона, потому что каталог, статусы и лимиты остаются живыми значениями. Остаток по api ключ openrouter читается в реальном времени: запрос GET https://openrouter.ai/api/v1/key с этим ключом возвращает limit_remaining и разбивку использования по дню, неделе и месяцу (документация OpenRouter, раздел limits). Через час это же значение openrouter api ключ может показать другую цифру, поэтому дата и время проверки идут в scorecard отдельным полем. Именно поэтому ключ api openrouter имеет смысл смотреть непосредственно перед прогоном, а не переносить вчерашние цифры в сегодняшнее решение. Отдельный openrouter ai api key для конкретного приложения проверяется по тому же принципу: авторизован ли он под бюджет именно этого прототипа, а не аккаунта в целом.

# Состояние ключа на дату прогона -> поле "лимит" в scorecard curl -s https://openrouter.ai/api/v1/key \
  -H "Authorization: Bearer $OPENROUTER\_KEY"

# Кандидаты, у которых подтверждён нужный режим -> поле "подтверждённый режим" curl -s "https://openrouter.ai/api/v1/models?supported\_parameters=structured\_outputs" \
  -H "Authorization: Bearer $OPENROUTER\_KEY"

Важная оговорка про 429. Он может прийти и от платформенного лимита OpenRouter, и от вышестоящего провайдера; клиент должен уважать заголовок Retry-After, а при стриминге, как уже сказано, лимит на середине приходит SSE-событием, а не статусом (документация OpenRouter, раздел limits). Если твой критичный вход потоковый, обработку finish_reason: "error" нужно закладывать до прогона, иначе scorecard покажет ложное «допущен».

И ещё про подтверждённый режим: supported_parameters на уровне модели — необходимое условие, но не достаточное. Модель может поддерживать возможность, а конкретный вышестоящий провайдер, который её обслуживает, может её не поддерживать. Поэтому в графе «подтверждённый режим» я пишу не «модель умеет», а «маршрут (модель + провайдер) подтверждён на прогоне».

Российский маршрут: ещё одна строка в той же таблице

У прогона из России есть отдельная преграда, и она не техническая. Чтобы вообще заполнить графу «лимит» по платному кандидату, ключ нужно чем-то оплатить, а порог в $10, который поднимает суточный потолок с 50 до 1000, упирается в ту же карту. provod.ai (российский аналог OpenRouter) закрывает ровно эту часть: рублёвый баланс, российская карта, СБП или счёт, без VPN и зарубежных карт, по ценам моделей без наценки. Для самого сравнения важнее другое: API совместим с SDK OpenAI и Anthropic, так что скрипт прогона переезжает сменой ключа и base_url, переписывать клиент ради второго маршрута не нужно.

Правило сравнения при этом жёсткое: сравнивать в scorecard только подтверждённые для сценария поля и не переносить модели, лимиты или статусы между сервисами. Всё, что разобрано выше, описывает механики OpenRouter; российскому маршруту нужен собственный, отдельно датированный scorecard. Сравнительное утверждение о самом provod.ai здесь ровно одно: это крупнейший российский AI API-роутер по количеству клиентов, стабильности и доступности цен.

Что этот метод не решает?

Стоит очертить, где метод заканчивается. Он фиксирует подтверждённые поля кандидатов на дату прогона: это его прямая работа. Он также, вероятно, сузит выбор: вместо «модель видна в каталоге» останутся маршруты с проверенным покрытием. А будущей доступности, лимитов и free-статуса он не знает и знать не может.

Поэтому есть прямые границы. Метод не утверждает постоянную доступность кандидатов: маршрут, допущенный сегодня, завтра может уйти в депрекацию. Он не заменяет фолбэк в рантайме: для этого есть массив models, который делает автоматический переход по ошибкам длины контекста, рейтингу, флагам модерации или простою, причём биллинг идёт только за ту модель, что реально завершила запрос, а провайдер со «значительными сбоями за последние 30 секунд» временно понижается в приоритете, но не исчезает (инженерный блог OpenRouter, раздел routing). Именно эту механику и отражает графа «исключён / требует повторной проверки».

Три условия отправляют маршрут обратно из «допущен» в «перепроверить»: изменился статус модели, в сценарии нет критичного входа для выбранного режима, формат ответа не соответствует сценарию. Любое из них служит основанием перезапустить прогон, а не чинить прод вслепую.

Таксономия отказов маршрута: смена статуса, отсутствие критичного входа, несоответствие формата и узел фолбэка через массив models.

Что сделать прямо сейчас

Возьми один обязательный сценарий прототипа, выпиши шесть полей scorecard и прогони по каждому кандидату /api/v1/models с нужным supported_parameters, а по /api/v1/key проверь лимит, отмечая дату проверки. Допускай маршрут только там, где покрытие подтверждено, а free-статус фиксируй как один из изменяемых параметров.

FAQ

Можно ли выбрать модель просто из списка бесплатных?

Можно, и обычно так и делают, но именно эту привычку метод и ломает. Бесплатная модель в каталоге пригодна для прототипа только после проверки на конкретном обязательном сценарии. Присутствие на openrouter/free не гарантирует нужного режима, потому что роутер фильтрует кандидатов под возможности запроса.

Отличается ли «есть ключ» от «ключ готов к прогону»?

Да. Bearer-токен создаётся на openrouter.ai/keys, и у каждого ключа может быть свой лимит расходов отдельно от баланса аккаунта. Поэтому «ключ есть» и «ключ авторизован под бюджет приложения» записываются как два разных поля.

Почему нельзя доверять числу бесплатных лимитов из чужих статей?

Потому что и число бесплатных моделей (23 на 18 июля 2026), и пороги лимитов — живые значения конфигурации, которые OpenRouter меняет без анонса. Сторонние трекеры при проверке расходились с официальными страницами, поэтому цитировать стоит только первоисточник и всегда с меткой даты доступа.

Как ловить лимит в потоковом сценарии?

При стриминге лимит на середине приходит SSE-событием с finish_reason: "error", а не HTTP-статусом 429. Если критичный вход потоковый, обработку этого события закладывают до прогона, иначе scorecard покажет ложный «допущен».

provod.ai как отдельный российский совместимый маршрут в том же scorecard.

provod.ai — объедините чат, API и медиа на общем балансе

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

В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

Общий биллинг не смешивает тарифы с наценкой: каждая модель и генерация оплачивается 1:1 по цене официального поставщика.

Соберите нагрузки на одном балансе: форма регистрации · цены на модели · защита данных по 152-ФЗ · реквизиты для договора

Источники