Como fazer seu app de IA sobreviver quando um modelo some de repente

Todo desenvolvedor que constrói sobre IA acaba aprendendo a mesma lição do jeito difícil: o modelo do qual você depende não está garantido. Ele pode ser limitado por taxa no pico de tráfego, retornar uma recusa, dar um erro de sobrecarga ou — como aconteceu com o Claude Fable 5 em junho de 2026 — ser desligado por completo por razões que não têm nada a ver com o seu código. Os apps que sobrevivem a esses momentos não são os que têm o melhor prompt. São os que se planejaram para o modelo não estar lá.

Este guia percorre uma abordagem prática e em camadas de resiliência que funciona tanto se você chama um provedor diretamente quanto se roteia por um gateway.

Passo 1: Nunca fixe um único modelo no código

A fragilidade mais comum é um nome de modelo cravado diretamente numa requisição. No momento em que aquela string para de funcionar, toda chamada falha. Em vez disso, defina seus modelos como configuração — uma pequena lista de prioridade, não uma constante:

MODEL_CHAIN = [
    "claude-opus-4-8",      # primary
    "claude-sonnet-4-6",    # same provider, cheaper/faster
    "gpt-5.5",              # different provider entirely
]

Essa única mudança significa que trocar de provedor durante um incidente é uma edição de configuração, não um deploy de código. Note que a terceira entrada é de um fornecedor diferente. Fallbacks do mesmo provedor te protegem de um único modelo cair; fallbacks entre provedores te protegem do provedor inteiro cair — ou ser mandado para fora do ar.

Passo 2: Use uma cadeia de fallback, não uma única tentativa

O padrão é simples: tente cada modelo em ordem, passe ao próximo em caso de falha e só apresente um erro se a cadeia inteira se esgotar.

def call_with_fallback(messages):
    last_error = None
    for model in MODEL_CHAIN:
        try:
            return client.complete(model=model, messages=messages)
        except (RateLimitError, OverloadError, RefusalError) as e:
            last_error = e
            continue  # try the next model
    raise AllModelsFailedError(last_error)

O que você usa como base do fallback importa. Repetir o mesmo modelo num erro transitório de overloaded (HTTP 529) faz sentido após um pequeno backoff. Mas um erro de autenticação ou uma requisição malformada vai falhar de forma idêntica em todos os modelos — esses devem aparecer imediatamente, em vez de queimar a cadeia inteira.

Passo 3: Apoie-se na plataforma quando ela oferece fallbacks nativamente

Nem sempre você precisa fazer isso na mão. Várias plataformas agora fazem do lado do servidor:

• A API da Anthropic adicionou um parâmetro beta fallbacks que repete uma requisição recusada em um modelo alternativo numa única ida e volta — o Fable 5, por exemplo, foi configurado para recorrer ao Opus 4.8 quando seus classificadores recusavam uma requisição. A cobrança segue o modelo que de fato serviu a resposta.
• OpenRouter permite passar um array models em ordem de prioridade; ele faz failover automaticamente em erros de tamanho de contexto, flags de moderação, limites de taxa e indisponibilidade, cobrando você à taxa do modelo que respondeu.
• LiteLLM entrega um Router com retries, fallbacks e balanceamento de carga embutidos entre deployments e fornecedores, que você hospeda por conta própria para controle máximo.

Um gateway como OpenRouter ou LiteLLM te dá um endpoint unificado entre vários provedores, então um fallback entre provedores é só mais uma entrada numa lista, em vez de um segundo SDK para integrar.

Passo 4: Adicione um disjuntor (circuit breaker) para falhar rápido

Se um modelo está claramente fora do ar, você não quer que cada requisição espere o timeout dele antes de cair para o próximo. Um disjuntor acompanha as falhas recentes e, uma vez cruzado um limite, pula o modelo quebrado por completo durante um período de resfriamento. As equipes em produção em 2026 costumam ficar em torno de cinco falhas consecutivas para acionar o disjuntor e um resfriamento de ~60 segundos antes de testar a recuperação. Enquanto o disjuntor está aberto, o tráfego vai direto para o próximo modelo da cadeia — sem latência desperdiçada.

Passo 5: Decida o que "degradado" significa para o seu produto

Cair para um modelo mais barato não é de graça — a qualidade cai e seus prompts podem se comportar de forma diferente. Planeje-se:

• Teste seus prompts contra cada modelo da cadeia. Um prompt ajustado para um modelo pode produzir uma saída visivelmente pior no seu fallback.
• Avise o usuário quando você degradou se isso importa (ex.: "rodando em modo rápido"), em vez de entregar resultados de qualidade inferior em silêncio.
• Registre qual modelo de fato serviu cada requisição para que você possa ver, após um incidente, quanto tráfego os fallbacks absorveram.

A conclusão

Resiliência não é um recurso que você parafusa depois do lançamento — é uma pequena quantidade de estrutura que você adiciona cedo: configuração em vez de constantes, uma cadeia de prioridade em vez de uma única chamada, um disjuntor para falhar rápido e prompts testados em todos os níveis. As equipes cujos apps continuaram no ar durante o desligamento do Fable 5 em junho não tiveram sorte. Elas simplesmente já tinham respondido a pergunta que todo construtor de IA deveria fazer no primeiro dia: o que acontece quando esse modelo não estiver lá amanhã?