OpenRouter не работает? Как переключиться без изменения кода

Когда люди ищут OpenRouter Down, им обычно нужны два быстрых ответа: действительно ли OpenRouter недоступен и как продолжать отправлять запросы, не переписывая приложение?

Самый безопасный ответ — не паниковать и не переключать модели прямо в коде. Сначала подтвердите, связана ли проблема с OpenRouter в целом, с конкретным провайдером, с вашим аккаунтом или с собственной очередью повторных попыток. Затем перенесите аварийное переключение в конфигурацию: проверки статуса, бюджет повторов, резервный провайдер, резервная модель и заменяемый OpenAI-совместимый base_url.

Дата проверки: 13 октября 2026 г. Не воспринимайте эту статью как доказательство того, что OpenRouter недоступен прямо сейчас. Перед началом инцидента проверьте страницу статуса OpenRouter и собственные логи.

Короткий ответ

Если OpenRouter не работает или один из маршрутов OpenRouter дает сбой, используйте такой порядок:

1. Проверьте https://status.openrouter.ai/ и свои журналы ошибок.
2. Разделите ошибки платформы OpenRouter и ошибки нижележащей модели/провайдера.
3. Учитывайте Retry-After для ответов 429, 503 и некоторых ответов 402 по бюджету выполняющихся запросов.
4. Оставляйте provider.allow_fallbacks включенным, если иное не требуется правилом соответствия.
5. Добавляйте резервные модели через конфигурацию запроса там, где контракт качества ответа это допускает.
6. Поместите ваш API-шлюз или резервную конечную точку за переменную окружения, чтобы можно было переключать base_url без правки кода приложения.

Именно последний пункт и есть настоящее переключение «без изменения кода». Приложение должно читать конечную точку из конфигурации:

OPENAI_BASE_URL=https://openrouter.ai/api/v1
OPENAI_API_KEY=...

Во время инцидента изменение в эксплуатации выглядит так:

OPENAI_BASE_URL=https://router.flatkey.ai/v1
OPENAI_API_KEY=...

Код вашего SDK остается прежним.

OpenRouter не работает?

Не делайте вывод OpenRouter Down на основании одного неудачного запроса. Неудачный запрос может означать:

В документации OpenRouter по ошибкам указано, что 502 может означать, что выбранная модель недоступна или вернула неверный ответ, а 503 — что ни один доступный провайдер модели не соответствует требованиям маршрутизации. В тех же документах сказано, что OpenRouter может возвращать Retry-After для 429, 503 и некоторых ответов 402 по бюджету выполняющихся запросов. Источник: Ошибки и отладка OpenRouter.

У OpenRouter уже были публичные сбои. В postmortem от 17 и 19 февраля 2026 года описаны сбои API из-за сторонней зависимости кэширования и отмечено, что некоторые пользователи видели запутывающие ошибки 401 во время инцидента. Этот исторический материал полезен как контекст, но не является доказательством текущего сбоя. Источник: Postmortem сбоя OpenRouter.

Первые пять минут: triage при OpenRouter Down

Используйте этот чек-лист перед переключением трафика.

Главная ошибка во время инцидента OpenRouter Down — заставить каждый воркер немедленно повторять запрос. Шторм повторов может превратить одну ошибку провайдера в проблему очереди по всей платформе внутри вашего приложения.

Failover без изменения кода

Паттерн без изменения кода прост: сохраняйте стабильное использование SDK и делайте маршрут настраиваемым.

import OpenAI from "openai";

export const ai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
  baseURL: process.env.OPENAI_BASE_URL,
});

Затем держите выбор endpoint в переменных окружения, конфигурации деплоя, feature flags или вашем secret manager:

ai_gateway:
  primary:
    base_url: https://openrouter.ai/api/v1
    key_env: OPENROUTER_API_KEY
  backup:
    base_url: https://router.flatkey.ai/v1
    key_env: FLATKEY_API_KEY
  switch_policy:
    trigger: confirmed_platform_incident_or_error_budget_exhausted
    owner: on_call_engineer
    rollback: after_30_minutes_below_error_threshold

Это работает, потому что в quickstart OpenRouter сказано, что его API можно использовать через OpenAI SDK, указав SDK на OpenRouter. Такая же схема интеграции как раз и делает резервный OpenAI-совместимый gateway практичным. Источник: OpenRouter quickstart.

Используйте provider fallback, прежде чем менять модели

Если OpenRouter доступен, но один из провайдеров испытывает проблемы, provider fallback — это наименее рискованный шаг. Вы сохраняете тот же контракт модели и позволяете маршрутизации попробовать другого подходящего провайдера.

В документации по provider routing OpenRouter сказано, что запросы по умолчанию балансируются между топ-провайдерами, чтобы максимизировать uptime, а объект provider включает allow_fallbacks, который по умолчанию равен true. В документации также предупреждается, что установка sort или order меняет поведение балансировки нагрузки, а жесткие фильтры по провайдеру могут уменьшить пространство для маршрутизации. Источник: OpenRouter provider routing.

Начните с этого:

{
  "model": "anthropic/claude-sonnet-4.5",
  "messages": [{ "role": "user", "content": "..." }],
  "provider": {
    "allow_fallbacks": true
  }
}

Во время инцидента с этим нужно быть осторожным:

{
  "provider": {
    "only": ["one-provider"],
    "allow_fallbacks": false
  }
}

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

Добавляйте model fallback только когда результаты взаимозаменяемы

Model fallback сильнее, чем provider fallback. Он может сохранить приложение работоспособным, когда основная модель недоступна, ограничена по rate limit или заблокирована, но он также может изменить стиль вывода, задержку, стоимость, длину контекста, поведение инструментов и результаты оценки.

В документации OpenRouter по model fallback сказано, что параметр models позволяет передавать идентификаторы моделей в порядке приоритета. Если первая модель возвращает ошибку, OpenRouter пробует следующую модель. В документации среди ошибок, которые могут вызвать fallback, указаны rate limiting и downtime. Источник: OpenRouter model fallbacks.

Используйте model fallback для задач с нестрогим контрактом эквивалентности:

{
  "models": [
    "anthropic/claude-sonnet-4.5",
    "openai/gpt-4o",
    "google/gemini-2.5-pro"
  ],
  "messages": [{ "role": "user", "content": "Кратко изложите этот тред поддержки." }]
}

Избегайте silent model fallback для задач, где точная модель является частью продуктовой гарантии:

Практичная политика на случай инцидента

Эта политика намеренно скучная. Она делает реагирование на OpenRouter Down операционным, а не драматичным.

openrouter_down_policy:
  status_checks:
    - openrouter_status_page
    - synthetic_chat_completion
    - provider_error_rate_by_model
    - queue_retry_rate

  retry_budget:
    max_attempts: 3
    honor_retry_after: true
    jitter: true
    stop_retrying_on:
      - invalid_credentials
      - spent_budget
      - moderation_block
      - bad_request

  provider_fallback:
    default_allow_fallbacks: true
    loosen_provider_constraints_for:
      - non_sensitive_batch_jobs
      - internal_tools
      - support_summaries

  model_fallback:
    require_contract: equivalent_quality_or_validated_schema
    log_selected_model: true
    disallow_for:
      - evals
      - compliance_outputs
      - customer_promises_about_exact_model

  base_url_failover:
    primary: OPENAI_BASE_URL
    backup_env: OPENAI_BACKUP_BASE_URL
    switch_owner: on_call_engineer
    switch_requires:
      - confirmed_status_incident_or_internal_error_budget
      - rollback_plan
      - public_request_log_enabled

Ключевые поля, которые нужно логировать:

Где здесь подходит Flatkey

Flatkey полезен, когда вы хотите, чтобы сценарий OpenRouter Down существовал вне кода приложения. Позиционирование проекта Flatkey — единый LLM API gateway: один ключ, один баланс и совместимая с OpenAI конечная точка для маршрутизации между официальными текстовыми, графическими и видеомоделями. В этом сценарии инцидента практическая ценность — операционная:

• Оставьте приложение на клиенте с OpenAI-compatible-структурой.
• Направьте нагрузку через резервный base_url без изменения логики приложения.
• Централизуйте allowlist моделей, sub-keys, журналы запросов, контроль бюджета и политику fallback.
• Сравнивайте поведение gateway по фактическим данным запросов, а не по анекдотам.

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

Полезно прочитать дальше:

• Лимиты OpenRouter
• LLM API fallback routing
• Стратегия fallback для моделей
• Управление квотами AI API
• Flatkey API quickstart

FAQ по OpenRouter Down

OpenRouter сейчас не работает?

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

Что мне делать первым, если OpenRouter не работает?

Приостановите агрессивные повторные попытки, проверьте коды статуса и сохраните интерактивный трафик. Если инцидент подтверждён, сначала предпочитайте fallback на провайдера, а уже потом fallback на модель; и предпочтите переключение конфигурации base_url вместо деплоя кода.

Могу ли я переключиться с OpenRouter без изменения кода?

Да, если ваше приложение уже читает endpoint, совместимый с OpenAI, из конфигурации. Поместите baseURL или base_url за переменную окружения, сохраните стабильную форму вызова SDK и переключите endpoint в конфигурации развёртывания.

Стоит ли использовать fallback-модели OpenRouter во время сбоя?

Используйте fallback-модели только тогда, когда запасная модель подходит для задачи. Они уместны для многих внутренних рабочих процессов, но не для evals, регулируемых выводов или случаев, когда клиентам была обещана конкретная модель.

Какое самое безопасное долгосрочное решение для риска OpenRouter Down?

Проектируйте с учётом переносимости на уровне маршрута: настраиваемый base_url, логирование на уровне запроса, бюджеты повторных попыток, fallback на провайдера, протестированные контракты fallback моделей и резервный путь через совместимый с OpenAI gateway. Цель не в том, чтобы избежать каждого сбоя; цель в том, чтобы failover был скучным.