OpenRouter está fora do ar? Como fazer failover sem mudar o código

Quando as pessoas pesquisam OpenRouter Down, geralmente precisam de duas respostas rápidas: o OpenRouter está realmente fora do ar e como mantenho as requisições em andamento sem reescrever meu app?

A resposta mais segura é não entrar em pânico e trocar modelos no código. Primeiro, confirme se o problema é em toda a OpenRouter, específico do provedor, específico da conta ou da sua própria fila de tentativas. Depois, mova o failover para a configuração: verificações de status, orçamento de retries, fallback de provedor, fallback de modelo e uma base_url compatível com OpenAI que possa ser alternada.

Data verificada: 13 de outubro de 2026. Não trate este artigo como prova de que a OpenRouter está fora do ar agora. Verifique a página de status da OpenRouter e seus próprios logs antes de iniciar um incidente.

A Resposta Curta

Se a OpenRouter estiver fora do ar, ou se uma rota da OpenRouter estiver falhando, use esta ordem:

1. Verifique https://status.openrouter.ai/ e seus logs de erro.
2. Separe erros da plataforma OpenRouter de erros do modelo/provedor upstream.
3. Respeite Retry-After em respostas 429, 503 e 402 de orçamento em voo.
4. Mantenha provider.allow_fallbacks habilitado, a menos que uma regra de conformidade exija o contrário.
5. Adicione fallbacks de modelo por meio da configuração da requisição, onde o contrato de qualidade da resposta permitir.
6. Coloque seu gateway de API ou endpoint de backup atrás de uma variável de ambiente para que você possa alternar o base_url sem editar o código da aplicação.

Esse último ponto é a verdadeira movimentação de "sem mudar o código". Sua aplicação deve ler o endpoint da configuração:

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

Durante um incidente, sua mudança operacional se torna:

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

Seu código do SDK permanece o mesmo.

A OpenRouter Está Fora do Ar?

Não conclua OpenRouter Down a partir de uma única requisição falhada. Uma requisição falhada pode significar:

A documentação de erros da OpenRouter afirma que 502 pode significar que o modelo escolhido está fora do ar ou retornou uma resposta inválida, enquanto 503 pode significar que nenhum provedor de modelo disponível atende aos requisitos de roteamento. A mesma documentação diz que a OpenRouter pode retornar Retry-After em 429, 503 e algumas respostas 402 de orçamento em voo. Fonte: Erros e depuração da OpenRouter.

A OpenRouter já teve interrupções públicas antes. Seu postmortem de 17 e 19 de fevereiro de 2026 descreve falhas de API causadas por uma dependência de cache de terceiros e observa que alguns usuários viram erros 401 confusos durante o incidente. Esse post histórico é útil como contexto, mas não é evidência de uma interrupção atual. Fonte: Postmortem da interrupção da OpenRouter.

Primeiros Cinco Minutos: Triagem de OpenRouter Down

Use esta checklist antes de redirecionar o tráfego.

O principal erro durante um incidente OpenRouter Down é fazer com que cada worker tente novamente imediatamente. Uma tempestade de retries pode transformar um erro de provedor em um problema de fila em toda a plataforma dentro do seu próprio app.

Failover Sem Mudar o Código

O padrão sem mudança de código é simples: mantenha o uso do SDK estável e torne a rota configurável.

import OpenAI from "openai";

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

Então mantenha a seleção de endpoint no ambiente, na configuração de implantação, em feature flags ou no seu gerenciador de segredos:

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

Isso funciona porque o quickstart do OpenRouter diz que sua API pode ser usada por meio do SDK da OpenAI apontando o SDK para o OpenRouter. A mesma forma de integração é exatamente o que torna prático um gateway OpenAI-compatible de backup. Fonte: OpenRouter quickstart.

Use o fallback de provedor antes de trocar modelos

Se o OpenRouter estiver acessível, mas um provedor estiver com problemas, o fallback de provedor é a opção de menor risco. Você mantém o mesmo contrato de modelo e deixa o roteamento tentar outro provedor elegível.

A documentação de roteamento de provedores do OpenRouter diz que as requisições são balanceadas entre os principais provedores por padrão para maximizar o uptime, e o objeto provider inclui allow_fallbacks, com valor padrão true. A documentação também alerta que definir sort ou order altera o comportamento de balanceamento de carga, e filtros rígidos de provedor podem reduzir a margem de roteamento. Fonte: Roteamento de provedores do OpenRouter.

Comece com isto:

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

Tenha cuidado com isto durante um incidente:

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

O roteamento rígido pode ser o correto para conformidade, retenção de dados, região ou política de preço. Mas roteamento rígido não é uma configuração de confiabilidade. Se você precisar de roteamento rígido para cargas sensíveis, crie um caminho separado, não sensível, que possa fazer failover com mais liberdade.

Adicione fallback de modelo apenas quando as saídas forem intercambiáveis

O fallback de modelo é mais forte do que o fallback de provedor. Ele pode manter o app ativo quando o modelo primário está fora do ar, com limitação de taxa ou bloqueado, mas também pode mudar o estilo da saída, a latência, o custo, o tamanho do contexto, o comportamento de ferramentas e os resultados de avaliação.

A documentação de fallback de modelo do OpenRouter diz que o parâmetro models permite fornecer IDs de modelos em ordem de prioridade. Se o primeiro modelo retornar um erro, o OpenRouter tenta o próximo modelo. A documentação lista limitação de taxa e indisponibilidade entre os erros que podem acionar o fallback. Fonte: Fallbacks de modelo do OpenRouter.

Use fallback de modelo para tarefas com um contrato de equivalência flexível:

{
  "models": [
    "anthropic/claude-sonnet-4.5",
    "openai/gpt-4o",
    "google/gemini-2.5-pro"
  ],
  "messages": [{ "role": "user", "content": "Resuma este thread de suporte." }]
}

Evite fallback silencioso de modelo para tarefas em que o modelo exato faz parte da garantia do produto:

Uma política prática para incidentes

Esta política é intencionalmente sem graça. Ela mantém o trabalho de resposta a OpenRouter Down operacional, em vez de dramático.

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

Os campos principais para registrar são:

Onde o Flatkey se encaixa

O Flatkey é útil quando você quer que o playbook OpenRouter Down exista fora do código da aplicação. O posicionamento do projeto para o Flatkey é um gateway unificado de API de LLM: uma chave, um saldo e um endpoint compatível com OpenAI para roteamento entre modelos oficiais de texto, imagem e vídeo. Nesse padrão de incidente, o valor prático é operacional:

• Mantenha sua aplicação em um formato de cliente compatível com OpenAI.
• Roteie uma carga de trabalho por meio de um base_url de backup sem alterar a lógica da aplicação.
• Centralize listas de अनुमति de modelos, subchaves, logs de solicitações, controles de orçamento e política de fallback.
• Compare o comportamento do gateway usando evidências da solicitação, em vez de anedotas.

Não mova todas as cargas de trabalho durante um incidente pequeno. Mova primeiro uma carga de trabalho representativa, observe a taxa de erro, a latência, o modelo selecionado, o motivo do fallback e o custo; depois decida se amplia a mudança.

Leituras úteis a seguir:

• Limites de taxa do OpenRouter
• Roteamento de fallback para API de LLM
• Estratégia de fallback de modelos
• Gerenciamento de cotas de API de IA
• Início rápido da API do Flatkey

FAQ sobre OpenRouter fora do ar

O OpenRouter está fora do ar agora?

Verifique primeiro a página de status do OpenRouter. Este artigo explica como responder quando buscas por OpenRouter Down correspondem a um incidente real ou a uma falha local do provedor; ele não afirma que o OpenRouter está fora do ar neste momento.

O que devo fazer primeiro se o OpenRouter estiver fora do ar?

Pause retries agressivos, inspecione os status codes e preserve o tráfego interativo. Se o incidente for confirmado, prefira o fallback do provedor antes do fallback de modelo e prefira uma troca de configuração de base_url antes de um deploy de código.

Posso fazer failover do OpenRouter sem mudar o código?

Sim, se sua aplicação já lê o endpoint compatível com OpenAI a partir da configuração. Coloque baseURL ou base_url atrás de uma variável de ambiente, mantenha a forma da chamada do SDK estável e troque o endpoint na configuração de deployment.

Devo usar fallbacks de modelo do OpenRouter durante uma interrupção?

Use fallbacks de modelo apenas quando o modelo de fallback for aceitável para a tarefa. Eles são apropriados para muitos fluxos de trabalho internos, mas não para evals, saídas regulamentadas ou casos em que os clientes foram prometidos um modelo específico.

Qual é a solução de longo prazo mais segura para o risco de OpenRouter Down?

Projete para portabilidade no nível da rota: base_url configurável, logging no nível da requisição, orçamentos de retry, fallback de provedor, contratos de fallback de modelo testados e um caminho de gateway de backup compatível com OpenAI. O objetivo não é evitar toda interrupção; é tornar o failover algo banal.