A gente trata o nome do modelo de IA no código como dependência versionada, não como constante. Parece óbvio até você abrir um projeto e encontrar claude-opus-4-20250514 escrito direto dentro da chamada de API, em três arquivos diferentes, sem nenhuma camada no meio.
Isso funciona bem até o dia em que para de funcionar. E a data em que vai parar não é surpresa: a Anthropic avisa com antecedência mínima de 60 dias antes de aposentar um modelo, segundo a própria documentação de deprecação da Claude API. O aviso de desligamento do Claude Opus 4.1 saiu em 5 de junho de 2026, com retirada marcada para 5 de agosto. Sessenta e um dias entre o e-mail e o modelo parar de responder. Sonnet 4 e Opus 4 tiveram o mesmo ritmo: aviso em 14 de abril, desligamento em 15 de junho.
Sessenta dias parece tempo de sobra. Não é, quando ninguém no time sabe em quais arquivos o nome do modelo está escrito.
O aviso chega por e-mail, o código não lê e-mail
O fluxo de deprecação da Anthropic é bem desenhado: notificação por e-mail, prazo mínimo definido, página de auditoria de uso no Console para exportar CSV com o que ainda está rodando em modelo antigo. O problema não é a política. É a distância entre quem recebe o aviso (geralmente alguém em suporte, financeiro ou o founder que assinou a conta) e quem sabe onde o model id está hardcoded no repositório.
Em projeto pequeno isso é achar e trocar uma string. Em projeto com três ou quatro agentes rodando em produção, cada um com seu próprio arquivo de configuração, o e-mail de 60 dias vira uma corrida silenciosa em cima da data de retirada, descoberta tarde demais.
Trocar o nome não basta
Tem outro detalhe que a maioria ignora: trocar o modelo é mais do que trocar uma string. Modelos diferentes se comportam diferente com o mesmo prompt, e às vezes até os parâmetros aceitos mudam. A própria Anthropic deprecou temperature, top_p e top_k como valores não padrão a partir do Claude Opus 4.7: passar um valor diferente do default nesses modelos retorna erro 400. Um código que setava temperature=0.3 direto na chamada, sem checar o modelo de destino, quebra na troca, não por falta de aviso, por mudança de contrato.
Isso muda o tamanho do problema. Atualizar o valor antes do prazo não resolve sozinho. O que resolve é rodar o mesmo conjunto de tarefas no modelo novo, comparar a saída, e só depois promover a troca.
Trocar o modelo sem testar contra os mesmos casos é apostar que o fornecedor não mudou nada, e o histórico de deprecação mostra que ele muda.
A decisão: um ponto de troca, não um roteador de modelos
Dá para exagerar na solução. Construir um roteador de modelos com fallback automático, múltiplos provedores e lógica de retry entre eles é trabalho real, e a maioria dos projetos não precisa disso. O que a gente decidiu fazer é mais simples: o model id nunca fica espalhado no código, fica em um único lugar de configuração, e toda troca passa por um conjunto pequeno de casos de teste que representam o que o agente faz de verdade, não um "oi, tudo bem" de sanity check.
| Antes | Depois |
|---|---|
| Model id hardcoded em cada chamada | Model id em uma variável de configuração única |
| Descoberta do deprecation pelo erro em produção | Descoberta pelo e-mail, com tempo de reagir |
| Troca de modelo sem comparação de saída | Troca validada contra um conjunto de casos reais |
Parâmetro como temperature fixo por modelo | Parâmetro checado contra o contrato do modelo de destino |
O trade-off é tempo de setup contra velocidade de reação. Escrever esse ponto único de configuração e montar o conjunto de teste leva um dia, talvez dois. Não escrever custa o mesmo dia, só que em cima da hora, com o modelo já desligado e o cliente perguntando por que o agente parou.
O que fazer na segunda de manhã
Roda um grep no repositório atrás do padrão de model id (claude-, gpt-, gemini-, o que for) fora de um único arquivo de configuração. Se aparecer em mais de um lugar, esse é o primeiro problema a resolver, antes de qualquer deprecation chegar.
grep -rn "claude-opus-4\|claude-sonnet-4\|claude-haiku" --include="*.py" --include="*.ts" . | grep -v config
Depois, entra no Console da Anthropic, exporta o CSV de uso e confere se algum model id ativo no seu projeto já está na coluna "deprecated". E separa meia hora para montar os cinco ou dez casos de teste que valem como critério de troca: se o agente não passa nesses casos com o modelo novo, ele não vai para produção, ponto final.
A Overflow trata essa parte da engenharia de agentes como parte do trabalho de implementação de IA em produção, não como detalhe operacional a resolver depois. O modelo muda. A pergunta é se o seu código descobre isso pelo e-mail ou pelo erro.
