Como saber o que mudou em cada versão do Claude Opus sem depender de boato

Fala aí, beleza? Toda vez que sai (ou que dizem que vai sair) uma versão nova do Opus, a timeline enche de thread de especulação antes de existir qualquer registro público do que mudou

Aí você lê três resumos de terceiros, cada um com um número diferente, e no fim não sabe o que é fato e o que é achismo

A real é que existe um conjunto de páginas oficiais que registram o que mudou de verdade, versão por versão, e elas são públicas

Neste post eu te mostro quais são e COMO ler cada uma, porque cada página responde uma pergunta diferente

Pra situar: o Opus mais recente da Anthropic é o Claude Opus 5, anunciado em 24 de julho de 2026

O que você precisa antes de começar

Nada de acesso especial, beleza? Não tem waitlist, não tem programa fechado, não precisa de PC da Nasa

Todas as fontes que eu vou citar aqui são páginas públicas da documentação oficial, do Help Center e do GitHub

O que muda tudo é OUTRA coisa: saber em qual produto você está

Porque a mesma mudança não vale pra todo mundo ao mesmo tempo

A lista curta dos contextos possíveis:

• Claude API (você chamando o modelo por código)
• Claude Code (o agente no terminal)
• Apps do Claude (interface web e mobile)
• Nuvens parceiras (Amazon Bedrock, Google Cloud)

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

Quer um exemplo verificável de por que isso importa? A seção System Prompts das release notes publica o system prompt usado pela interface web e pelos apps móveis, e a própria página avisa que essas atualizações não se aplicam à API

Ou seja: ler aquela seção e sair dizendo "o comportamento da API mudou" é errado na origem

Se você ainda não colocou a mão no modelo mais recente, o caminho de criar conta e fazer a primeira conversa resolve isso antes de você começar a rastrear mudança

Passo a passo: como rastrear o que mudou em uma versão do Opus

A ideia aqui é montar uma sequência: cada fonte responde uma pergunta específica, e cada uma tem um erro clássico de leitura

Vou explicar o porquê de cada uma antes do como, do jeito que eu gosto

1. Comece pelas release notes da plataforma

Essa é a página que reúne as mudanças por área de produto: API, Claude Code, apps e system prompts

É o registro corrido, o "diário de bordo" da plataforma

Link: release notes da Claude Platform

O erro comum deste passo: ler uma seção e aplicar o dado na área errada

Mudança listada em apps não é mudança de API, e vice versa

2. Abra a página de novidades do modelo na doc, não o anúncio de marketing

O anúncio conta a história, a doc conta os números

A doc tem uma página dedicada What’s new in Claude Opus 5, separada do post de lançamento

É ali que estão as especificações do modelo:

• janela de contexto de 1M de tokens (padrão e máximo, sem variante menor)
• até 128k tokens de saída
• thinking ligado por padrão
• parâmetro de esforço (effort) com cinco níveis: low, medium, high, xhigh e max, com padrão high na Claude API e no Claude Code

O erro comum deste passo: pegar número de post de terceiro que leu o anúncio

Se o dado é número, ele tem que sair da doc

3. Confira a Models overview pra saber o que está disponível e quanto custa

A visão geral dos modelos lista o que existe hoje na plataforma e as características de cada um

E o preço do Opus 5 é US$ 5 por milhão de tokens de entrada e US$ 25 por milhão de tokens de saída, o mesmo preço do Opus 4.8

Se liga nisso: versão nova nem sempre significa preço novo

Aqui também vale cruzar com a decisão prática de qual modelo usar em cada tarefa, porque saber o que mudou é uma coisa, escolher o que rodar é outra

4. Leia a página de Model IDs e versionamento pra não confundir alias com snapshot

Esse é o ponto onde eu já vi muita gente se perder

Cada model ID identifica uma versão fixa do modelo (o snapshot)

Já o alias é um ponteiro: ele resolve pro snapshot datado mais recente daquela versão

Se você conhece tag latest de imagem Docker, é bem semelhante: o nome fica igual, o conteúdo por baixo pode trocar

A referência é a página Model IDs and versioning

O erro comum deste passo: fixar um alias achando que travou a versão

Não travou

5. Cheque a página de deprecations pro ciclo de vida

Saber o que chegou é metade da história, a outra metade é o que vai sair

A página Model deprecations documenta os estados (deprecated e retired) e o compromisso de avisar com pelo menos 60 dias de antecedência antes de aposentar um modelo lançado publicamente

Exemplos que já estão registrados ali:

O erro comum deste passo: só olhar isso quando a chamada quebra em produção

Tome cuidado! Essa é a página que evita susto

6. Baixe o system card da versão

O system card é o documento de avaliação do modelo, e ele é público

O do Opus 5 é um PDF datado de 24 de julho de 2026

Entre as conclusões dele: o modelo não cruza o limiar de capacidade de P&D automatizado de IA definido na Responsible Scaling Policy da Anthropic

Esse tipo de afirmação é exatamente o que vira boato distorcido quando ninguém abre o documento, né?

Os system cards ficam reunidos no Transparency Hub da Anthropic, então dá pra comparar com os anteriores no mesmo formato, como o do Opus 4.8 (28 de maio de 2026) e o do Opus 4.6 (fevereiro de 2026)

7. Se você usa Claude Code, leia o changelog dele

O Claude Code tem changelog próprio, publicado na doc oficial: Claude Code changelog

O mesmo changelog é mantido como arquivo CHANGELOG.md na branch main do repositório oficial anthropics/claude-code no GitHub

O erro comum deste passo: procurar mudança de CLI nas release notes do modelo

São registros diferentes, com ritmos diferentes

8. Se o seu uso é pelo app, vá no Help Center

As mudanças dos apps do Claude (web e mobile) têm página própria de release notes no support.claude.com

É o registro de quem usa o produto pela interface e não pela API

9. Se você chama por SDK, acompanhe o changelog do SDK

Os SDKs oficiais mantêm changelog próprio no GitHub, separado das release notes da plataforma

São o CHANGELOG.md na main do anthropic-sdk-python e do anthropic-sdk-typescript

O erro comum deste passo: culpar o modelo por um comportamento que mudou na biblioteca

10. Se você roda em nuvem parceira, confirme o identificador

O Opus 5 também está disponível fora da Claude API, com identificador próprio em cada nuvem:

Amazon Bedrock:  anthropic.claude-opus-5
Google Cloud:    claude-opus-5

O erro comum deste passo: copiar o identificador de um tutorial da nuvem errada e passar meia hora debugando um nome

Já me ferrei uma vez com esse tipo de coisa haha

O que só aparece no changelog e nunca no anúncio

Agora o pulo do gato deste post

Post de lançamento existe pra contar o que é bom

Changelog existe pra registrar o que mudou, inclusive o que ninguém ia anunciar com fogos de artifício

Exemplo real que está nas release notes da plataforma: a depreciação do fast mode do Claude Opus 4.6

As requisições que usavam o modo passaram a rodar em velocidade padrão e a ser cobradas com preço padrão

Repare no tamanho disso: é uma mudança que mexe em latência E em conta, e ela vive no registro, não na manchete

Tem também o posicionamento por plano, que muda o que chega até você sem você mexer em nada

O anúncio oficial do Opus 5 posiciona o modelo como novo modelo padrão no plano Claude Max e como o modelo mais forte disponível no Claude Pro

Ou seja: um dia você abre a ferramenta e o padrão é outro

Quem lê só thread acha que "mudaram o modelo escondido", quem lê o registro sabe que estava escrito

O que aprendi testando versão nova na prática

Aqui eu falo por experiência própria, com material meu

Quando saiu o Claude Opus 4.7, eu passei algumas horas testando dentro do Claude Code antes de gravar, e o que eu trouxe foram primeiras impressões, não conclusão fechada

Montei um infográfico pra organizar o que tinha mudado (preço, benchmarks, novidades de API e de Claude Code), abri o material oficial na tela e fui percorrendo seção por seção pra achar o que interessava

E fui até o seletor de modelo da interface pra confirmar qual versão estava ativa, em vez de acreditar em print de terceiro

Na parte de teste na mão, foram 3 projetos com 1 prompt em cada:

• um clone de gerenciador de tarefas em kanban com UI moderna e animações: ficou bonito, mas com funções que não funcionavam e a tela recarregando a cada tarefa concluída
• um esqueleto de blog com autenticação, contagem de visualizações, menu de âncora, troca de tema e criação de post pelo admin: esse foi o melhor resultado
• um painel administrativo, só pra avaliar qualidade de interface, que era o ponto que o material oficial destacava

E eu reconheço o limite do meu próprio teste: projeto padronizado tipo clone e dashboard pode sair bem por peso do dado de treinamento, não por mérito da versão nova

Minha régua com benchmark é essa: benchmark não é prova

O que decide é testar por conta própria e ver se melhorou de verdade, e se o consumo de tokens não explode numa mensagem simples

Uma coisa que aumentou minha confiança no material oficial, inclusive: eles compararem o modelo novo com os anteriores e admitirem cenários em que a versão antiga foi melhor

E aí chega a conexão com o tema deste post: teste próprio mostra como a coisa se comporta NO SEU fluxo, mas ele não te diz o que mudou

O registro oficial te diz o que mudou, mas não te diz se serve pra você

As duas leituras se completam, uma não substitui a outra

No vídeo abaixo eu mostro esse teste na prática, do infográfico até os projetos rodando:

Próximo passo: monte sua rotina de checagem

Não precisa virar tarefa diária, beleza? A rotina é enxuta

Deixa salvo:

• a página de release notes da plataforma
• a página de novidades do modelo na doc
• a página de deprecations
• o changelog do produto que VOCÊ usa (Claude Code, apps ou SDK)

E quando sair versão nova, abre o system card daquela versão no Transparency Hub, que é onde mora a parte de avaliação

O próximo passo concreto é bem simples: escolha as duas ou três fontes que correspondem ao seu uso real (API, Claude Code ou apps) e confira ELAS antes de acreditar em qualquer resumo de terceiros

Depois disso, teste na mão e tire sua conclusão

Boato tem previsão, doc tem registro… fica com o registro 😀

até o próximo post!