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

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

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!