Claude 3.5 Sonnet ainda existe? O que fazer se o seu projeto ainda aponta para ele

Fala aí, beleza? Aquele serviço que rodava sozinho há meses começou a devolver erro do nada, ninguém mexeu em nada e o log não ajuda muito

Se ele chamava o Claude 3.5 Sonnet, o mistério acabou aqui: o modelo foi aposentado na API da Anthropic e requisição pra ele retorna erro

Então o problema não é mais "por que quebrou", é "como troco isso sem quebrar o resto"

E é exatamente isso que a gente vai destrinchar aqui: como descobrir onde a dependência está, o que testar antes de trocar e o que muda de comportamento quando você cai no modelo novo

O que "aposentado" significa no ciclo de vida dos modelos Claude

Antes de sair editando string de configuração, vale entender o vocabulário, porque ele explica o porquê da quebra

A Anthropic usa quatro estados no ciclo de vida dos modelos:

• Active: suportado e recomendado, é onde você quer estar
• Legacy: não recebe mais atualizações e pode ser depreciado a qualquer momento
• Deprecated: ainda funciona, mas não é recomendado, já tem substituto e já tem data de aposentadoria definida
• Retired: não está mais disponível, e a requisição retorna erro

Se você conhece aquele ciclo de versão de linguagem (suportada, em manutenção, fim de vida), é bem parecido

A diferença é que aqui não tem "deixa rodando na versão velha", beleza? Quando entra em Retired, acabou, não existe mais o endpoint pra aquele modelo

E dava pra prever? Dava

A Anthropic se compromete a dar no mínimo 60 dias de aviso antes de aposentar um modelo lançado publicamente, notificando os clientes que têm implantação ativa

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

No caso do Sonnet 3.5, a notificação de deprecação saiu em 13 de agosto de 2025, e a aposentadoria efetiva na API veio em 5 de janeiro de 2026, depois de adiamentos em relação às datas anunciadas antes

Ou seja: teve aviso, teve prazo, e ainda teve prorrogação

O que costuma acontecer é o aviso cair na caixa de e-mail de quem criou a chave de API há dois anos e não mexe mais no projeto 😅

A Anthropic também publicou uma página de compromissos sobre depreciação e preservação de modelos, e a lista de deprecações vive na documentação oficial de model deprecations

Coloca essas duas no radar, é o jeito mais barato de não ser pego de surpresa na próxima

(Pra referência histórica: o Claude 3.5 Sonnet foi lançado em 20 de junho de 2024, então ele teve uma vida bem longa pro ritmo dessa indústria)

O que ter em mãos antes de mexer no código

Nada de sair trocando ID no braço direto na produção, se liga no checklist antes:

• Acesso ao Claude Console, especificamente à página Usage, porque é de lá que sai a exportação do que cada chave andou chamando
• Acesso ao repositório onde o ID de modelo está escrito, e de preferência a todos os repositórios, não só o principal
• Saber por qual plataforma a chamada sai: API direta da Anthropic, Amazon Bedrock, Google Cloud, Microsoft Foundry, Claude Platform on AWS ou Claude Managed Agents
• Um ambiente de teste separado da produção, porque tem mudança de comportamento no meio do caminho, não é só troca de nome

Esse ponto da plataforma é o que mais confunde

O mesmo modelo tem calendário diferente em cada lugar onde ele é servido, e data de uma plataforma não vale pra outra

Então a primeira pergunta não é "qual modelo", é "por onde essa requisição sai"

Passo a passo para migrar um projeto preso no Claude 3.5 Sonnet

Bora ver na prática

1. Audite qual modelo o seu projeto realmente chama

A própria documentação da Anthropic indica o caminho: no Claude Console, vá em Usage e clique em Export

O CSV que baixa mostra o uso quebrado por chave de API e por modelo

Isso responde a pergunta que o código sozinho não responde: quem ainda estava batendo no modelo antigo, e por qual chave

• O erro comum deste passo: olhar só o serviço principal e esquecer os jobs agendados, os scripts internos, o webhook que alguém subiu em 2024 e a integração de um time vizinho. O CSV por chave existe justamente pra isso, leia ele inteiro

2. Mapeie no código onde o ID aparece e separe snapshot datado de alias

Os IDs com data no fim (tipo claude-sonnet-4-5-20250929) são snapshots fixos: aquele modelo, aquele comportamento, sem mudar debaixo de você

Já os aliases são ponteiros de conveniência: a Anthropic migra o alias pro snapshot mais recente, tipicamente em até uma semana depois de um lançamento novo

• O erro comum deste passo: achar que usar alias te protege. É o contrário. O alias muda o modelo debaixo de você sem você pedir, e aí o comportamento vira de um dia pro outro

3. Troque o ID de modelo

O modelo padrão hoje nos produtos da Anthropic é o Claude Sonnet 5, lançado em 30 de junho de 2026, com o model ID claude-sonnet-5, que entrou no lugar do Sonnet 4.6

Na prática, a mudança no seu código é isso aqui:

# antes
model = "claude-3-5-sonnet-..."

# depois
model = "claude-sonnet-5"

Esse é o ID divulgado no lançamento, e ele resolve o problema imediato: seu serviço volta a responder

Pra produção tem um passo a mais, e ele está no Passo 7, se liga lá embaixo

Tem também o caminho automatizado: a Anthropic oferece a migração pela skill Claude API, rodando dentro do Claude Code

/claude-api migrate

Ele aplica a troca do ID de modelo e, quando necessário, as mudanças de parâmetros que quebram, a substituição de prefill e a calibração de esforço na base de código

No fim, gera uma checklist de itens pra você verificar manualmente, e antes de editar arquivo ele pede confirmação do escopo

Em base grande isso é ouro, porque a varredura pega o que o grep da sua memória não pega

Só vale um cuidado de projeto legado: se o repositório tem convenção própria de configuração, ajuda muito fazer o agente respeitar o padrão antes de deixar ele editar arquivo em série

E se a rodada parecer arrastada numa base enorme, dá pra investigar por que o Claude Code fica lento antes de culpar a migração

• O erro comum deste passo: tratar como migração idêntica à documentada. O Sonnet 5 é apresentado como substituição direta (drop-in) do Sonnet 4.6, não do 3.5. Vindo de um modelo muito mais antigo, conte com ajuste de prompt

4. Ajuste os parâmetros que passaram a retornar erro 400

São as três mudanças de comportamento que a documentação lista pro Sonnet 5:

• adaptive thinking vem ligado por padrão
• extended thinking manual passa a retornar erro 400 (isso já tinha sido depreciado no Sonnet 4.6)
• definir temperature, top_p ou top_k com valores fora do padrão retorna erro 400

E tem a regra que pega muita gente: requisição sem o campo thinking roda com adaptive thinking, e sempre que thinking está ativo a temperature precisa estar em 1 ou não definida, em todos os modelos

Traduzindo pro seu código: aquele temperature=0.2 que você botou lá em 2024 pra "deixar mais determinístico" é um candidato forte a derrubar a chamada

5. Reconte os prompts e revise o max_tokens

Esse é o mais silencioso de todos

O Sonnet 5 usa um tokenizador novo, que produz cerca de 30% mais tokens pro mesmo texto (o aumento exato depende do conteúdo e do tipo de carga)

A orientação da documentação é recontar os prompts com a contagem de tokens e revisar os limites de max_tokens que foram dimensionados perto do tamanho esperado da saída

• O erro comum deste passo: manter o max_tokens calibrado pro modelo antigo. Aí a chamada não dá erro, ela só corta a resposta no meio, e você descobre isso pelo cliente reclamando de JSON inválido 🙃

6. Teste em ambiente separado antes de liberar

Como o thinking vem ligado por padrão, o formato e o ritmo da resposta podem mudar mesmo com o prompt igualzinho

Se o seu sistema faz parse rígido da saída, é aqui que aparece

7. Fixe um snapshot datado em produção

A documentação recomenda usar versão específica de modelo (o ID com data) em aplicação de produção, em vez de alias, justamente pra garantir comportamento consistente

E aquele claude-sonnet-5 do Passo 3? Ele é o ID divulgado no lançamento, ótimo pra destravar o serviço e pra rodar em teste

Antes do rollout, confira na documentação de model IDs e versões qual é o snapshot datado correspondente e coloque ELE no código de produção

E se o seu Claude Code é implantado via Amazon Bedrock, Google Cloud, Microsoft Foundry ou Claude Platform on AWS, a orientação é fixar (pin) a versão do modelo antes de liberar pros usuários

Parece detalhe chato, mas é o que te salva de acordar com o comportamento diferente por causa de um lançamento que você nem viu acontecer

Erros mais comuns depois da troca de modelo e como resolver

Requisição ao 3.5 Sonnet voltando erro

Causa: o modelo está Retired, ele não existe mais como destino de requisição

O que fazer: não tem workaround, tem troca de ID mesmo

Como prevenir na próxima: acompanhar o estado do modelo no ciclo de vida e reagir quando ele entra em Deprecated, não quando vira Retired

Erro 400 ao enviar extended thinking manual

Causa: no Sonnet 5, extended thinking manual retorna erro 400, e isso já vinha depreciado desde o Sonnet 4.6

O que fazer: tirar a configuração manual e deixar rodar com adaptive thinking

Como prevenir: quando migrar de modelo, ler o guia de migração antes de subir, não depois do primeiro 400

Erro 400 ao definir temperature, top_p ou top_k

Causa: valores fora do padrão nesses parâmetros retornam erro 400 no Sonnet 5, e com thinking ativo a temperature precisa estar em 1 ou não definida

O que fazer: remover os valores customizados de amostragem

Como prevenir: procurar esses três nomes no repositório inteiro antes do rollout, inclusive em arquivo de config e variável de ambiente

Saída cortada no meio

Causa: tokenizador novo gerando cerca de 30% mais tokens pro mesmo texto, estourando um max_tokens calibrado pro modelo anterior

O que fazer: recontar os prompts com a contagem de tokens e redimensionar o limite

Como prevenir: nunca deixar max_tokens colado no tamanho esperado da saída, sempre com folga

Resposta com comportamento diferente do esperado

Causa: adaptive thinking ligado por padrão

O que fazer: revalidar os casos de uso mais sensíveis a formato antes de liberar

Como prevenir: snapshot datado em produção, pra que a troca de comportamento aconteça no dia em que VOCÊ decidir, e não no dia do lançamento seguinte

O caminho muda conforme onde a sua integração roda

Aqui mora a maior confusão da migração

O calendário do modelo é por plataforma, e data de uma não vale pra outra, ponto

O caso do Bedrock merece um parágrafo à parte, porque ele é o mais generoso de prazo

A AWS garante que um modelo permanece na plataforma por pelo menos 12 meses antes da data de EOL, e fica pelo menos 6 meses no estado Legacy antes do EOL

As datas publicadas pela AWS são as que valem pro uso no Bedrock, e elas podem divergir das datas publicadas pelo provedor do modelo

Tome cuidado com isso: ver "ainda funciona no Bedrock" e concluir que a API direta também aceita é o tipo de dedução que derruba serviço em produção

E quem usa Claude Managed Agents respira aliviado: ali não precisa de mudança além de atualizar o nome do modelo

Conclusão

No fim das contas, migrar um projeto preso no Claude 3.5 Sonnet é troca de ID mais a checagem de três pontos de comportamento: thinking, parâmetros de amostragem e contagem de tokens

O resto é disciplina de auditoria

Se eu pudesse sugerir um único próximo passo prático, seria esse: abra o Claude Console, vá em Usage, clique em Export e leia o CSV por chave de API e por modelo

É ali que aparece aquela chave esquecida ainda apontando pra modelo antigo, aquela que ninguém lembra que existe até ela quebrar num domingo 😀

Depois disso, fixe os snapshots datados em produção e você tira do caminho a categoria inteira de "mudou sozinho e ninguém sabe por quê"

Como referência de custo do destino, o Claude Sonnet 5 está em US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de tokens de saída, valor introdutório que virou o preço padrão

Até o próximo post!