A maioria dos guias de migração informa o que quebra em seu código. Este é sobre o que quebra em seus prompts.
O Claude Opus 5 foi lançado em 24 de julho de 2026, e a Anthropic publicou um guia de prompt dedicado juntamente com ele. Esse guia documenta algo que vale a pena prestar atenção: várias instruções que tornavam o Opus 4.8 melhor tornam o Opus 5 pior. Não sutilmente pior. Mensuravelmente mais caro, mensuravelmente mais verboso e, em um caso, ativamente quebrado.
A razão é simples. O Opus 5 já faz, por si só, várias coisas que você costumava ter que pedir. Quando seu prompt antigo pede de qualquer maneira, a instrução se acumula com o comportamento que o modelo já possui. Você obtém o dobro de passagens de verificação, não o dobro de precisão.
Este guia descreve cada mudança de comportamento documentada com um trecho de prompt de copiar e colar que você pode inserir em seu prompt de sistema hoje. Ele também aborda os dois modos de falha que aparecem quando você desabilita o pensamento, que é o único lugar onde um prompt do Opus 5 pode produzir uma saída que parece boa e corrompe silenciosamente um loop de agente. Se você ainda está trabalhando nas mudanças em nível de código, o guia de migração do Opus 4.8 para o Opus 5 os aborda separadamente. E se você quiser ver essas mudanças de comportamento em cargas úteis de solicitação e resposta reais, o Apidog é uma maneira direta de enviar o mesmo prompt com configurações diferentes e comparar os resultados.
O resumo em uma linha
O Opus 5 verifica mais, escreve mais, delega mais e se explica mais do que o Opus 4.8. Seu prompt do Opus 4.8 foi ajustado para empurrar um modelo em direção a esses comportamentos. Agora ele os ultrapassa.
Portanto, o trabalho é subtrativo. Você está principalmente excluindo instruções, não adicionando-as. As adições que você faz são restrições: seja mais curto, mantenha o escopo, não crie auxiliares.
1. Exclua suas instruções de verificação
Esta é a grande mudança, e é a razão do título.
A Anthropic afirma que o Opus 5 verifica seu próprio trabalho sem ser solicitado. Ele relê o que escreveu, verifica sua aritmética, executa novamente um teste e procura o caso de borda que você não mencionou. Esse era o comportamento exato que todos instruíam manualmente no Opus 4.8 com linhas como “verifique seu trabalho antes de responder” ou “verifique cada etapa”.
Mantenha essas linhas e você terá uma superverificação. O modelo executa passagens de verificação que ele executaria de qualquer maneira, além das que você pediu, e você paga por cada token disso. Em longas execuções agentic, isso é uma conta real, não um erro de arredondamento.
A solução é uma exclusão. Pesquise seus prompts de sistema por esses padrões e remova-os:
Double-check your work before responding.
Verify each step before moving to the next one.
Review your answer for errors, then revise it.
Check your reasoning carefully.
Make sure the output is correct before returning it.
Se você tiver uma etapa genuinamente de alto risco onde deseja uma passagem de verificação explícita, restrinja-a a essa etapa em vez de torná-la uma regra global:
Do not add general verification passes; you already verify by default.
The only exception: after writing the migration SQL, run it against the
schema dump once and report any mismatch. Do not re-verify anything else.
Essa forma importa. Uma instrução global de “verificar tudo” no Opus 5 é um multiplicador de custos. Uma única exceção com escopo é um controle.
Se você está monitorando os gastos da API durante esta migração, as alavancas de cache e lote no detalhamento de preços do Opus 5 se acumulam com esta, e nosso guia para reduzir uma conta da API Claude abrange as alavancas gerais.
2. Peça concisão explicitamente, pois o esforço não fará isso
As respostas padrão do Opus 5 são mais longas que as do Opus 4.8. O mesmo acontece com seus entregáveis escritos: os relatórios, resumos, documentos de design e READMEs que ele produz quando você solicita um documento.
Aqui está a parte que confunde as pessoas. Diminuir o parâmetro effort não resolve isso. O esforço controla o quanto o modelo pensa. Não controla o quanto o modelo escreve. Diminua de xhigh para medium e você cortará tokens de pensamento, enquanto a resposta visível permanece mais ou menos tão longa quanto era. Se você assumiu que o esforço era um dial de verbosidade, sua conta não se moverá como você esperava. O guia do parâmetro de esforço do Opus 5 abrange o que cada nível realmente muda.
O comprimento é um problema de prompt, então resolva-o no prompt. Seja específico sobre o limite máximo em vez de dizer “seja breve”, o que os modelos interpretam generosamente:
Response format: at most 150 words unless I ask for more.
No preamble, no restatement of my question, no summary at the end.
Lead with the answer, then the reasoning if it is needed.
Para entregáveis escritos, coloque o limite no artefato e nomeie o que deve ser descartado:
Write the migration doc at 800 words maximum.
Include: the breaking changes, the fix for each, and a rollback step.
Exclude: background on the old system, a glossary, and a conclusion section.
If a section would exceed its share, cut examples before cutting steps.
Para trabalhos com muito código, a restrição equivalente é sobre comentários, não código:
Return the diff and nothing else.
No explanation of what you changed unless the change is non-obvious,
in which case one sentence above the hunk.
3. Limite a delegação de subagentes
O Opus 5 delega a subagentes mais facilmente do que o Opus 4.8. Dada uma tarefa multi-partes e um framework que suporte a criação de subagentes, ele se expandirá.
Isso geralmente é a decisão certa. É também uma decisão de custo que o modelo está tomando em seu nome, e cada subagente carrega seu próprio contexto e sua própria conta de token. Para cargas de trabalho sensíveis a custos ou latência, estabeleça um número em vez de deixar a critério do modelo:
Do not spawn subagents for this task. Handle it in this conversation.
Ou, quando a expansão é genuinamente útil, mas deve ser limitada:
You may delegate to at most 2 subagents, and only for independent
file-level work that can run in parallel.
Do research, planning, and final synthesis yourself in this thread.
O padrão a ser evitado é a delegação por si só: um subagente criado para ler um arquivo, ou para tomar uma decisão que o thread principal já tinha contexto para tomar. Se você construir com subagentes deliberadamente, nosso guia para criar subagentes de código Claude abrange o lado do framework para escopo-los.
4. Restrinja explicitamente o escopo em tarefas específicas
O Opus 5 expande o escopo da tarefa. Peça para ele corrigir um teste falho e ele pode também refatorar o auxiliar que o teste chama, atualizar a assinatura do tipo e adicionar mais dois casos de teste. Peça para ele renomear uma variável e ele pode organizar a função circundante.
Às vezes, isso é um recurso. Em uma tarefa estreita e cirúrgica, não é: uma refatoração não solicitada significa um diff maior para um revisor ler e um raio de explosão maior para uma mudança que deveria ser de uma linha.
Declare o limite como um limite e nomeie o que está fora dos limites:
Scope: change only the retry-count constant in src/client/http.ts.
Do not refactor surrounding code, do not rename anything, do not add
tests, do not update docs. If you believe another change is required,
stop and tell me instead of making it.
Essa última cláusula é a metade útil. Sem ela, o modelo não tem uma maneira sancionada de levantar um problema real, então ele faz a alteração de qualquer maneira ou descarta a observação. Com ela, você obtém uma preocupação sinalizada e um diff inalterado.
5. Espere mais narração de correção e desative-a se não a quiser
O Opus 5 narra suas correções mais do que o Opus 4.8. Quando ele muda de ideia no meio da resposta, ele informa: sinaliza que uma abordagem anterior estava errada, explica o porquê e descreve a mudança.
Para trabalho interativo, isso é útil. Para um pipeline onde a resposta alimenta um parser, uma interface de usuário ou outro modelo, essa narração é ruído em um campo que deveria conter uma resposta.
A instrução é curta:
Do not narrate corrections or changes of approach.
Return only the final answer. If you revised your thinking, that
revision belongs in your reasoning, not in the response.
Se você encaminha respostas para armazenamento estruturado, combine isso com saídas estruturadas para que a forma seja imposta em vez de solicitada.
Os modos de falha com pensamento desabilitado
Tudo o que foi dito acima é um problema de ajuste. Esta parte é um problema de correção.
A Anthropic documenta dois artefatos que aparecem ocasionalmente no Opus 5 quando o pensamento é desabilitado via thinking: {type: "disabled"}. Ambos são importantes de conhecer antes de implementar um agente.
Chamadas de ferramentas escritas como texto puro. O modelo emite algo que parece uma chamada de ferramenta, mas como texto no corpo da resposta, em vez de um bloco estruturado tool_use. Nada é executado. Em um chat de uma única vez, você notaria. Em um loop de agente, muitas vezes você não nota: o loop não vê nenhuma chamada de ferramenta, então não toma nenhuma ação, e o texto vazado permanece no histórico da conversa. As próximas interações então leem esse texto como se uma chamada tivesse acontecido. A falha se acumula ao longo das interações e, quando a saída parece errada, a causa está várias interações atrás.
Tags XML internas na saída visível. Tags como <thinking> aparecem na resposta que o usuário vê. Cosmeticamente ruim por si só, e pior se você renderizar respostas como HTML ou analisá-las para estrutura.
A parte contraintuitiva: nomear as tags em seu prompt piora o vazamento, não melhora. Uma instrução como “nunca exiba tags <thinking>” coloca a sequência de tokens em contexto e aumenta a probabilidade de ela aparecer. Não escreva essa instrução.
A mitigação recomendada pela própria Anthropic não é um prompt. É manter o pensamento habilitado e controlar o custo com um nível de esforço mais baixo em vez disso:
{
"model": "claude-opus-5",
"max_tokens": 4096,
"output_config": { "effort": "low" },
"messages": [
{ "role": "user", "content": "..." }
]
}
Isso lhe dá o lado barato do intervalo sem os artefatos de pensamento desabilitado. Também evita uma armadilha relacionada: no Opus 5, combinar thinking: {type: "disabled"} com esforço xhigh ou max retorna um 400, porque desabilitar o pensamento é limitado a esforço high. Note também que o pensamento está agora ativado por padrão, então uma solicitação que simplesmente omite o campo thinking é executada com pensamento adaptativo em vez de sem ele, como teria acontecido no Opus 4.8.
Se você tem um requisito rigoroso para desativar o pensamento, adicione uma verificação defensiva em seu loop em vez de uma instrução de prompt: rejeite qualquer turno do assistente cujo corpo de texto contenha uma string com formato de chamada não executada antes de anexá-la ao histórico. Falhe ruidosamente em vez de permitir uma chamada fantasma na transcrição.
Teste as mudanças em vez de adivinhar
As mudanças nos prompts são difíceis de avaliar apenas lendo-as. Os comportamentos aqui (comprimento da resposta, passagens de verificação, contagem de subagentes) aparecem como contagens de tokens e estrutura da carga útil, o que significa que a maneira honesta de verificar seu trabalho é enviar as solicitações e comparar.
Isso é fácil de configurar no Apidog, que é uma plataforma completa de desenvolvimento e teste de API:
- Crie uma solicitação para o endpoint de Mensagens da Anthropic com
"model": "claude-opus-5"e armazene sua chave de API como uma variável de ambiente em vez de colá-la no corpo. - Salve seu antigo prompt de sistema do Opus 4.8 e sua versão truncada do Opus 5 como duas solicitações salvas para a mesma entrada.
- Compare o bloco
usageem cada resposta. Os tokens de saída informam se a restrição de concisão foi aplicada; os tokens de entrada e os campos de cache informam se suas edições de prompt quebraram um prefixo de cache. - Duplique a solicitação em diferentes níveis de esforço para ver por si mesmo que os tokens de pensamento diminuem enquanto o comprimento visível se mantém.
- Inspecione a resposta de streaming para confirmar que as chamadas de ferramentas chegam como blocos estruturados
tool_usee não como texto.
O quinto passo é o que detecta a falha de chamada de ferramenta em texto puro antes que ela chegue à produção. Baixe o Apidog se você quiser executar estes lado a lado e veja o tutorial da API Opus 5 para a forma completa da solicitação.
O limite honesto
Vale a pena dizer claramente, já que os guias de prompt tendem a parecer que o modelo é o último de que você precisará: o Opus 5 não é o topo da pilha Claude. O Fable 5 mantém a designação de "mais capaz amplamente lançado", e o Opus 5 ainda está atrás do Mythos 5 em exploração de segurança cibernética e pesquisa de biologia autônoma. A Anthropic menciona ambos em seu próprio post de lançamento. A abordagem precisa é a capacidade de classe de fronteira pela metade do preço de fronteira, com um limite nomeado acima dela.
As reivindicações de benchmark de lançamento (Frontier-Bench, ARC-AGI 3, OSWorld 2.0, CursorBench) são todos os números da própria Anthropic e não foram reproduzidos independentemente até 25 de julho de 2026. Trate-os como relatórios de fornecedores e execute suas próprias avaliações nos prompts que você realmente publica.
Juntando tudo
Um prompt de sistema Opus 5 simplificado para uma tarefa de agente sensível a custos se parece aproximadamente com isto:
Do not add verification passes; you verify by default.
Responses: 150 words maximum, no preamble, no closing summary.
Do not spawn subagents. Handle this in one thread.
Stay strictly within the task I state. If another change seems
required, stop and tell me rather than making it.
Do not narrate corrections or changes of approach.
Seis linhas, cinco das quais são restrições e nenhuma pede ao modelo para se esforçar mais. Essa é a mudança. No Opus 4.8, você usava prompts para elevar um patamar. No Opus 5, você usa prompts para definir um teto.
Comece por aí, então faça uma varredura de esforço em suas próprias avaliações, em vez de manter suas configurações do 4.8, já que os níveis foram recalibrados. Para a mecânica dos parâmetros, consulte o guia de parâmetros de esforço, para o fluxo de trabalho do lado do editor, consulte usando o Opus 5 no Claude Code, e para a imagem completa do modelo, comece em o que é o Claude Opus 5. A visão geral de modelos da Anthropic tem a tabela de especificações atual.
FAQ
Devo realmente excluir “verifique seu trabalho” dos meus prompts? Sim. O guia de prompts da Anthropic diz que o Opus 5 verifica sem ser solicitado, e as instruções de verificação herdadas causam superverificação. Exclua a regra global. Se uma etapa específica realmente precisar de uma verificação explícita, restrinja a instrução apenas a essa etapa.
Por que o Opus 5 é tão prolixo mesmo com baixo esforço? Porque o esforço controla o pensamento, não o comprimento visível da saída. Diminuir o esforço corta tokens de raciocínio enquanto as respostas permanecem aproximadamente do mesmo tamanho. Defina um limite de palavras ou formato no próprio prompt.
Como impeço que o Opus 5 crie subagentes? Diga isso diretamente: “Não crie subagentes; lide com isso nesta conversa.” Se alguma ramificação for útil, dê um limite numérico e restrinja-a a trabalhos paralelos independentes.
Por que estou vendo tags <thinking> na minha saída? Esse artefato aparece ocasionalmente quando o pensamento está desabilitado. Não adicione uma instrução de prompt nomeando as tags, pois isso torna o vazamento mais provável. A correção recomendada da Anthropic é manter o pensamento habilitado e usar um nível de esforço mais baixo para controlar os custos.
O que acontece se uma chamada de ferramenta retornar como texto simples? Nada é executado, e o texto vazado permanece no histórico da conversa, onde as interações posteriores o tratam como uma ação concluída. Valide os turnos do assistente antes de adicioná-los ao histórico e prefira manter o pensamento ativado em vez de desativá-lo.