Seu fallback provavelmente não é um fallback
Uma lista ordenada de modelos parece resiliência, mas só vira fallback quando o próximo degrau consegue fazer o mesmo trabalho.
Montar fallback para IA parece fácil. Você pega o modelo preferido, coloca outro embaixo, talvez um terceiro para emergência, e pronto: se o primeiro falhar, o sistema tenta o próximo.
Essa lista quase sempre é falsa.
O erro está em tratar nome de modelo como unidade de resiliência. Na prática, cai uma cota, uma assinatura, uma capacidade, uma ferramenta, uma classe de tarefa. Se o próximo degrau não separa essas coisas, você não tem fallback. Tem uma fila bonita que desaba no mesmo lugar.
Redundância não é nome diferente
A primeira armadilha é contar redundância pelo nome na configuração. Dois clientes diferentes podem apontar para a mesma assinatura. Dois modelos podem consumir o mesmo medidor. Duas rotas podem depender do mesmo recurso administrativo.
Quando a cota acaba, os dois caem juntos.
Foi assim que eu passei a pensar em fallback por recurso e medidor, não por label. A pergunta não é "tenho dois modelos?". A pergunta é "se este limite acabar, o próximo degrau ainda tem limite independente?". Se a resposta for não, a lista só criou uma ilusão de profundidade.
Isso vale para fornecedor, projeto, tipo de conta e qualquer camada que possa negar a chamada antes do modelo raciocinar. O sistema não precisa saber detalhes privados da infraestrutura. Precisa registrar que degraus compartilham o mesmo ponto de falha.
A mesma coisa
A segunda armadilha é pior porque passa como sucesso. O primeiro degrau edita arquivos. O segundo só devolve texto. A chamada falha no primeiro, cai para o segundo, o segundo responde com um plano, talvez até com um patch formatado, e a automação marca como concluída.
Nada aconteceu.
Fallback só vale se o degrau seguinte souber fazer a mesma coisa. Se a tarefa precisava abrir ferramenta, escrever arquivo, ler imagem ou chamar um sistema externo, o fallback precisa dessa mesma capacidade. Degradar qualidade pode ser aceitável. Degradar a natureza da tarefa em silêncio não é.
Falhar alto é melhor que degradar escondido. Um erro claro interrompe a esteira e diz que faltou capacidade. Um sucesso falso segue em frente e entrega ausência como se fosse trabalho feito.
Essa é a distinção que eu uso: fallback de modelo não é fallback de capacidade. Se a capacidade muda, a rota precisa mudar de estado também. Pode virar "responder em texto", "pedir revisão" ou "bloquear". Não pode continuar com o mesmo contrato.
Transitório não é definitivo
A terceira armadilha é confundir falha momentânea com ausência. Um limite de taxa diz que a chamada não foi medida naquele momento. Não diz que o recurso acabou para sempre. Já uma resposta de não autorizado ou não encontrado fala de outra classe de problema.
Quando o roteador trata toda falha igual, ele derruba degrau saudável. Um pico temporário vira prova falsa de que a rota morreu. Depois o sistema usa um caminho pior, mesmo quando o primeiro já voltou.
Por isso o fallback precisa registrar causa, não só destino. "Caiu para o segundo modelo" é pouco. Eu preciso saber se caiu por limite, indisponibilidade, falta de permissão, ausência de recurso ou incapacidade da tarefa. Sem isso, não dá para ajustar a rota. Dá apenas para torcer.
Um ponto de passagem
O jeito mais chato, e o que mais funciona, é ter um gateway único. Toda chamada passa por um ponto que sabe qual tarefa está sendo pedida, quais capacidades ela exige, quais degraus são independentes, e qual modelo de fato respondeu.
Esse último registro é essencial. Sem ele, você acha que o sistema está usando o primeiro degrau porque foi isso que você configurou. Na realidade, pode estar sobrevivendo há semanas no último. O produto continua funcionando, mas a margem acabou.
Fallback que funciona não é uma lista. É um contrato: este trabalho exige estas capacidades; estes degraus são independentes; esta falha permite tentar de novo; esta outra precisa parar.
Onde isso quebra
Um gateway único também vira ponto único de falha. Se ele cair, tudo que dependia dele cai junto. A solução não é fingir que isso não existe; é tratar o gateway como infraestrutura de verdade, com observabilidade e caminho manual para operação crítica.
Registro de rota também é dado sensível. Ele revela o que você manda para fora, quando manda, e por qual classe de provedor passa. Precisa ser guardado como dado operacional, não como log solto.
E roteamento automático esconde degradação. Se ninguém olha a telemetria, você descobre que o degrau bom morreu no dia em que o último degrau também cair.