Olá, Lena está chegando~ Claude Code Opus 5.5 é uma daquelas escolhas de modelo que eu faria explicitamente, em vez de assumir que já está ativo. O motivo é simples: o alias opus não é resolvido da mesma maneira em todos os provedores e uma sessão Claude Code retomada pode reabrir com o modelo usado anteriormente.

Portanto, antes de testar qualquer coisa significativa, quero alinhar três coisas: o modelo Claude Code diz que está em execução, o repositório que permiti que ele tocasse e o resultado que usarei para julgar o teste.

Nota de evidência: Antrópico anunciado Opus 5.5 em 22 de setembro de 2026. Verifiquei a documentação atual em 24 de setembro. Claude Code não está instalado aqui, portanto o exercício abaixo é um procedimento reproduzível, não um teste de modelo completo.

Verifique o acesso e atualize Claude Code

Comece com:

claude --version

Anthropic diz que o Opus 5.5 requer Claude Code v2.1.280 ou posterior. Se sua instalação for mais antiga, execute:

claude update

Em seguida, verifique a versão novamente. Se a instalação se comportar de maneira estranha, claude doctor é a próxima etapa mais útil do que reinstalar ou alterar repetidamente as configurações do modelo.

A disponibilidade do modelo também depende da conta por trás do Claude Code. Você precisa de um plano Claude pago elegível, uma conta de console ou acesso por meio de um provedor de nuvem compatível. Uma conta Claude.ai gratuita por si só não é suficiente.

As configurações da organização também são importantes aqui. Se o Opus 5.5 simplesmente não aparecer, eu verificaria as restrições de conta, provedor e modelo gerenciado antes de assumir que a instalação local do Claude Code está interrompida.

Selecione Opus 5.5 para a sessão

Use o seletor de modelo atual

Dentro de Claude Code, digite:

/model

Então procure pelo Opus 5.5.

O guia de configuração do modelo Claude Code da Anthropic oferece ao seletor dois comportamentos ligeiramente diferentes:

s alterna a sessão atual sem alterar o padrão salvo.
Enter seleciona o modelo e também o salva para sessões futuras.

Para teste, prefiro s. Não quero que uma sessão de avaliação mude silenciosamente o modelo que normalmente utilizo.

Você também pode inserir:

/model claude-opus-5-5

Isso salva a seleção.

Um detalhe é fácil de perder: opus é um alias, não um pin de versão.

No momento em que este artigo foi escrito, ele mapeava para Opus 5.5 na API da Anthropic, Claude Platform na AWS, Amazon Bedrock e Agent Platform do Google, enquanto o Microsoft Foundry ainda o resolve de forma diferente. Se o objetivo do exercício for avaliar especificamente o Opus 5.5, eu usaria o nome completo do modelo em vez de confiar no alias.

Use o nome completo do modelo na CLI

Para uma nova sessão na API da Anthropic:

claude --model claude-opus-5-5

Isso aplica o modelo a esse lançamento sem reescrever o padrão salvo.

As implantações na nuvem podem ser menos organizadas. Dependendo do provedor, o equivalente pode ser um ARN do perfil de inferência, um nome de implantação ou uma versão do modelo específico do provedor, em vez da string de modelo simples da Anthropic. Nesse caso, a configuração do provedor faz parte da configuração do teste e não é um detalhe de implementação a ser ignorado.

Verifique qual modelo está ativo

Após selecionar o modelo, execute:

/status

Este é o cheque em que eu confiaria. Ele mostra o modelo ativo, a versão e a conta, e uma linha de status configurada também pode expor o modelo.

A distinção é importante porque pedir ao Claude Code para usar um modelo não é exatamente a mesma coisa que provar que a sessão realmente começou nele. Listas de permissões da organização, configuração do provedor, substitutos e sessões retomadas podem complicar essa suposição.

Se /status mostrar algo inesperado, pare por aí e corrija a seleção primeiro. Eu não tentaria identificar o modelo por seu estilo de escrita, comportamento de codificação ou um rótulo lembrado de uma sessão anterior.

Eu também registraria o fornecedor junto com o nome do modelo. Duas sessões podem mostrar nomes de modelos legíveis semelhantes enquanto resolvem diferentes identificadores de implantação de provedor abaixo.

Dê a ele uma tarefa de repositório pequena e reversível

Para o primeiro teste, eu evitaria a criação de recursos.

Use um repositório descartável ou uma ramificação de teste segura, sem segredos, credenciais de produção ou dados de clientes. Primeiro confirme a árvore de trabalho:

git status --short

Em seguida, execute o comando de teste local normal do repositório. Depois de saber que o estado inicial está íntegro, crie um branch:

git switch -c trial/opus-5-5

Isso fornece um ponto de comparação claro, sem fingir que uma ramificação do Git é um limite de segurança.

Um primeiro resumo útil pode ser assim:

"Adicione um teste de regressão para entrada vazia na função nomeada. Altere sua implementação somente se o teste falhar. Toque apenas nessa função e no arquivo de teste. Não adicione dependências, não use rede e pare antes de confirmar ou enviar por push. Execute o comando de teste local existente; relate arquivos e resultados alterados."

Eu substituiria as referências genéricas por caminhos reais, o nome exato da função e o comando de teste conhecido antes de executá-lo.

A tarefa é intencionalmente chata. Isso é útil.

Para uma primeira verificação do modelo, me importo menos se o modelo pode inventar uma implementação impressionante e mais se ele respeita o escopo, percebe a estrutura de teste existente, faz a menor mudança necessária e para onde eu disse para parar.

Mantenha os prompts de permissão ativados e aprove apenas o que a tarefa realmente exige.

Revise a diferença, não apenas o resultado do teste

Assim que o Claude Code terminar, eu inspecionaria:

git status --short

git diff --check

git diff

A documentação atual de diferenças do Git explica exatamente o que essas comparações mostram, mas a revisão importante ainda pertence a você: o modelo tocou nos arquivos que você permitiu e a alteração realmente corresponde ao briefing?

Uma armadilha aqui é que o git diff simples não mostra arquivos não rastreados. Verifique-os separadamente, em vez de tratar uma diferença de aparência limpa como prova de que nada mais apareceu.

Em seguida, execute você mesmo o comando de teste local e registre o status de saída.

A aprovação no teste é uma evidência útil, mas não é suficiente. Um modelo pode passar no teste solicitado e ainda assim criar um arquivo desnecessário, editar algo fora do escopo acordado ou introduzir uma dependência que o brief excluiu explicitamente.

Se o teste não sobreviver à revisão, eu restauraria apenas os arquivos envolvidos no experimento, inspecionaria e removeria quaisquer arquivos recém-criados e retornaria ao branch inicial.

Mantenha a saída do teste mesmo se você jogar o código fora. Os testes fracassados costumam ser mais informativos do que as demonstrações limpas porque mostram onde o modelo ignorou o escopo ou onde o briefing foi subespecificado.

Para uma revisão do código EvoX, os artefatos que eu traria são simples: o nome da filial, a diferença real e o log de teste. O material EvoX local pode suportar a revisão do repositório, mas isso não implica uma transferência automática da sessão Claude Code.

Retorne ao seu modelo normal

Se o teste usou s ou --model, inicie uma nova sessão Claude Code sem substituição e execute /status novamente.

Se você pressionou Enter em /model, escolha seu modelo normal – ou Padrão – e pressione Enter para que a seleção se torne o padrão salvo novamente.

As configurações do projeto e da organização ainda podem substituir as preferências no nível do usuário, portanto, eu verificaria a nova sessão em vez de presumir que a redefinição funcionou.

O mesmo se aplica ao reabrir o teste posteriormente. Uma sessão Claude Code retomada pode restaurar o modelo associado a essa sessão anterior.

Perguntas frequentes

Os administradores da organização podem restringir quais modelos os usuários selecionam no Claude Code?

Sim. As configurações gerenciadas do availableModels e os controles corporativos podem limitar o que aparece no seletor de modelo.

Se o Opus 5.5 estiver ausente em um ambiente gerenciado, verifique com o administrador antes de solucionar problemas na instalação local.

Um projeto pode fixar o Opus 5.5 sem alterar o padrão global do usuário?

Sim. O .claude/settings.json de um projeto pode especificar:

"model": "claude-opus-5-5"

Isso é útil quando um repositório é intencionalmente padronizado em um modelo, embora as configurações compartilhadas do projeto devam ser revisadas com o restante da equipe.

Para uma avaliação única, ainda prefiro --model porque deixa o padrão global intacto.

A retomada de uma sessão Claude Code mais antiga preserva seu modelo original?

Muitas vezes, sim, ao usar a API da Anthropic.

Existem exceções. Modelos obsoletos, restrições da organização, substituições explícitas de inicialização e comportamento de implantação específico do provedor podem alterar o que está realmente disponível quando a sessão for retomada.

É por isso que /status também pertence ao início de um teste retomado.

Como os limites de uso diferem entre o Opus 5.5 e outros modelos Claude?

A Anthropic anunciou limites de uso mais altos de cinco horas para os planos Pro, Max e Team, mas não existe um número universal de “X tarefas por modelo” que se aplique de forma clara a todas as cargas de trabalho.

Use /usage para verificar o subsídio vinculado à sua própria conta. Eu não presumiria que dois modelos consomem esse subsídio de forma idêntica simplesmente porque estão disponíveis no mesmo seletor.

O Opus 5.5 está disponível em todos os provedores de nuvem suportados?

A Anthropic lista sua própria plataforma, AWS, Google Cloud e Microsoft Foundry.

Isso não significa que todas as contas, regiões, implantações ou organizações tenham acesso automaticamente. A nomenclatura do provedor também difere, e o alias opus não resolve para Opus 5.5 em todos os lugares.

Para uma comparação real, verifique o identificador de implementação do provedor e o modelo mostrado em /status antes de começar a julgar a saída.

Postagens anteriores:

Se você quiser outro fluxo de trabalho Claude Code construído em torno de uma tarefa de repositório limitada, fluxo de trabalho do vault-to-code Obsidian Claude Code mostra como recuperar o contexto controlado, aplicá-lo ao código, executar verificações e escrever de volta somente após revisão.
Para avaliar se uma configuração de raciocínio mais forte realmente melhora o trabalho do repositório, raciocínio do agente Muse Spark 1.3 compara a qualidade de conclusão, intervenção, latência e custo da tarefa em uma tarefa de codificação fixa.
Se sua principal preocupação é manter o trabalho do agente de codificação passível de revisão, Revisão do código T3 concentra-se no escopo do repositório, controle de sessão, inspeção de diferenças e transferência humana em torno de uma superfície de codificação.