Claude Opus 4.1 ainda funciona? O que fazer se o seu código continua chamando esse modelo

Fala aí, beleza? Se você tem uma integração em produção com o nome do modelo cravado no código, esse é o tipo de coisa que quebra num domingo de manhã sem ninguém ter mexido em nada

O Claude Opus 4.1 tem data de aposentadoria na Claude API, e ela já passou: 5 de agosto de 2026

Ou seja, não é bug do seu código, não é rede instável, não é a lua

Aqui a gente vai ver o que checar ANTES de sair trocando string por string no projeto, começando pelo que a sua própria chave de API enxerga hoje

Sua chamada ao Opus 4.1 falha: por que isso acontece e o que fazer

O sintoma:

A requisição que rodava lisa, com o identificador claude-opus-4-1-20250805, passou a voltar erro em vez de resposta

Normalmente aparece em produção primeiro, porque produção é onde vive o ID antigo que ninguém revisita há meses hehe

A causa:

O Opus 4.1 entrou no estado Retired na Claude API, e Retired é o fim da linha pro fluxo normal: pela documentação da Anthropic, o modelo não está mais disponível para uso

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

E aqui vem a parte que pega muita gente de surpresa: requisições a modelos depois da data de aposentadoria falham, e a Anthropic NÃO redireciona silenciosamente pra um modelo mais novo

Não existe fallback automático

O que faz sentido, se tu pensar: trocar o modelo por baixo dos panos mudaria o comportamento, o custo e a saída do seu sistema sem você saber

Melhor falhar alto do que mentir baixo, beleza?

A solução:

Trocar o identificador pelo substituto recomendado na própria página de deprecations, que é o Claude Opus 4.8, ou ir direto pro Opus 5, que é o Opus mais recente

E, principalmente, parar de tratar erro de modelo como erro transitório

Se o seu wrapper tem retry com backoff pra tudo que é falha, ele vai ficar tentando de novo e de novo um modelo que não responde mais na sua chave, queimando tempo e log até alguém abrir o painel

Erro de modelo indisponível não melhora com retentativa

Como prevenir na próxima:

Não deixe o ID datado espalhado em dez arquivos

Centralize em configuração (variável de ambiente, arquivo de config, o que fizer sentido no seu stack) e passe o nome do modelo a partir dali

Assim a migração vira uma linha, não uma caçada

E acompanhe as notificações: a Anthropic avisou os desenvolvedores que usavam Opus 4.1 em 5 de junho de 2026, dois meses antes da retirada

Esse aviso costuma cair no email de quem tem deployment ativo, então vale conferir se ele está indo pra uma caixa que alguém realmente lê e não pro email genérico da empresa

Se o projeto for antigo e cheio de convenção própria, a mesma lógica de padrão de código em projeto legado vale aqui: mapear onde o valor está repetido antes de sair editando na mão

Como checar quais modelos a sua chave da API realmente enxerga

Antes de migrar qualquer coisa, a pergunta certa não é "qual modelo existe?"

É "o que a MINHA chave, nessa plataforma, lista agora?"

A Claude API expõe um endpoint de listagem justamente pra isso

1. Liste os modelos disponíveis na sua chave com GET https://api.anthropic.com/v1/models, que devolve os modelos disponíveis com os mais recentes primeiro

curl https://api.anthropic.com/v1/models \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01"

O erro comum deste passo: esquecer o header anthropic-version

Ele não é decoração, é obrigatório na chamada

2. Consulte um ID específico com GET https://api.anthropic.com/v1/models/{model_id} pra ver os metadados daquele modelo

curl https://api.anthropic.com/v1/models/claude-opus-4-1-20250805 \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01"

O erro comum deste passo: usar a chave da sua máquina local em vez da chave que roda em produção

São ambientes diferentes, e é a chave de produção que está quebrando, não a sua

3. Se a lista vier cortada, pagine por cursor com os parâmetros after_id, before_id e limit

O limit tem padrão 20 e aceita de 1 a 1000

curl "https://api.anthropic.com/v1/models?limit=100" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01"

O erro comum deste passo: olhar só a primeira página com o padrão de 20 itens e concluir que um modelo "sumiu"

4. Compare o resultado com o que está escrito no seu código, arquivo por arquivo, e anote todo lugar onde existe nome de modelo em texto puro

O erro comum deste passo: confiar na memória

A sua cabeça diz que o projeto usa um modelo só, o grep diz outra coisa 😅

5. Repita a checagem em CADA plataforma onde o seu código roda, e não assuma que a lista é a mesma em todas

É o gancho da próxima seção, se liga

Funciona no Bedrock mas falha na Claude API (ou o contrário)

O sintoma:

O mesmo nome de modelo responde num ambiente e explode no outro

Aí vem a dúvida clássica: "então o modelo existe ou não existe?"

A causa:

O Amazon Bedrock é plataforma parceira e tem calendário de aposentadoria próprio, definido pela AWS

A data de retirada da Claude API não se aplica automaticamente lá

Ou seja, um mesmo modelo pode estar fora numa ponta e ainda de pé na outra, cada uma seguindo o seu ciclo de vida

A solução:

Verificar o ciclo de vida na plataforma onde o código roda de fato, não na documentação genérica que você achou primeiro no Google

Se a integração fala com a Claude API, é a página de deprecations da Anthropic que manda

Se fala com o Bedrock, é o calendário da AWS que manda

Como prevenir:

Antes de planejar a migração, faça o mapa: qual integração vive na Claude API, qual vive no Amazon Bedrock, qual no Google Cloud Vertex AI e qual no Microsoft Foundry

Parece burocracia, mas é isso que evita você migrar o serviço errado e deixar o que estava quebrado exatamente como estava haha

Os quatro estados de um modelo Claude e o que cada um significa

A Anthropic trabalha com quatro estados de ciclo de vida, e entender isso muda a forma como você lê qualquer aviso:

• Active: o modelo está em circulação normal
• Legacy: geração anterior, ainda em pé
• Deprecated: ainda funciona, mas não é recomendado
• Retired: não está mais disponível para uso

A diferença entre os dois últimos é onde mora a dor

Deprecated é aviso, o código continua rodando

Retired é fim de linha no fluxo normal, o código para

"E nunca mais dá pra tocar nesse modelo?" Existe exceção documentada, o Claude Opus 3 é o caso, e eu volto nele mais pra frente

Mas pro seu código que chama o ID datado direto na Claude API, o efeito prático é esse mesmo: a requisição falha

E tem uma política pública por trás disso: no mínimo 60 dias de aviso antes de aposentar um modelo lançado publicamente, com notificação aos clientes que têm deployments ativos

No caso do Claude Opus 4.1, o aviso saiu em 5 de junho de 2026 e a retirada veio em 5 de agosto de 2026

E olha, não é caso isolado

Só em 2026 já saíram de circulação o Claude Sonnet 4 e o Claude Opus 4 (15 de junho), o Claude Haiku 3 (20 de abril), o Claude Haiku 3.5 e o Claude Sonnet 3.7 (19 de fevereiro)

Ou seja: ID de modelo cravado no código não é dívida técnica futura, é dívida técnica com data marcada

Para onde migrar: Opus 4.8 ou Opus 5

Os dois caminhos são válidos, e a boa notícia é que nenhum dos dois é mais caro que o modelo que você estava usando

Repara no preço: o Opus 4.8 custa um terço do que custava o Opus 4.1, tanto na entrada quanto na saída

E o Opus 5 tem o mesmo preço de tabela do 4.8

Então a migração aqui não é aquele upgrade que chega com a fatura junto, é o contrário

Se o critério for "menor atrito com o que a documentação indica", vai de Opus 4.8, que é o substituto apontado na própria página de deprecations

Se o critério for "quero o mais novo e quero mexer nisso uma vez só", o Opus 5 chegou com disponibilidade no dia do lançamento nas quatro plataformas: Claude API, Amazon Bedrock, Google Cloud Vertex AI e Microsoft Foundry

De qualquer forma, teste o comportamento antes de virar a chave em produção

Modelo novo é modelo novo: prompt que estava afiado pro 4.1 pode responder diferente, e isso não se descobre no dia do deploy 😀

O que muda para quem usa API e para quem usa assinatura

São dois mundos, e misturar os dois é fonte garantida de confusão

Na API, aposentadoria é ruptura

O ID sai de circulação, a chamada falha, alguém precisa editar código

Na assinatura, a conversa é outra

O Claude Opus 5 é o modelo padrão no Claude Max e o modelo mais forte disponível no Claude Pro, então quem usa pela interface simplesmente segue trabalhando com o topo da linha sem tocar em nada

E lembra da exceção que eu prometi lá em cima? É o Claude Opus 3, precedente documentado pela própria Anthropic

Ele foi aposentado em 5 de janeiro de 2026, mas segue acessível a todos os assinantes pagos do claude.ai e disponível na API mediante solicitação

Ou seja: aposentar é sair do fluxo normal, não necessariamente sumir de todos os produtos

Só não confunda exceção com regra: o padrão que você deve planejar é a chamada falhando, e a via alternativa depende de pedir

Cada plataforma tem a sua régua, e é por isso que a checagem tem que ser feita onde o seu código roda, não onde você leu a notícia

Conclusão

Se a sua integração parou, o roteiro é curto

Rode a consulta ao endpoint de modelos com a chave de PRODUÇÃO e veja o que ela lista de verdade hoje

Troque o claude-opus-4-1-20250805 pelo substituto (Opus 4.8) ou pelo Opus 5, e leve a string pra um lugar só, de preferência configuração

Depois faça a varredura completa: onde mais nesse projeto existe nome de modelo cravado no código? Script antigo, job agendado, aquele microserviço que ninguém abre desde o ano passado…

É meia hora de trabalho agora que evita o mesmo susto na próxima aposentadoria, e vai ter próxima

até o próximo post!