Como escrever prompts que realmente aproveitam o Claude Opus (e parar de desperdiçar o modelo mais forte)

Pedir pro modelo mais caro da Anthropic renomear uma variável é o jeito mais elegante que existe de queimar limite de uso 😅

O Claude Opus 5 é o topo da linha da Anthropic hoje: modelo padrão do Claude Max e o mais forte disponível no Claude Pro

Só que o desperdício não está em usar Opus

Está em usar Opus numa pergunta rasa, com prompt frouxo, esperando que ele adivinhe o resto

Então bora separar as duas coisas neste post: qual tipo de tarefa realmente paga o modelo mais forte, e como estruturar o pedido pra ele render nessa tarefa

O que você precisa saber antes de escrever o prompt

Antes do prompt em si, três coisas do modelo mudam o jeito de escrever

A primeira é espaço: o Claude Opus 5 trabalha com 1 milhão de tokens de contexto (esse é o padrão e o máximo, não existe variante menor) e até 128 mil tokens de saída máxima

A segunda é o raciocínio: no Opus 5 o thinking vem ligado por padrão, e o próprio modelo decide quando e quanto pensar a cada turno

Isso é diferente do Opus 4.8, onde o thinking vinha desligado por padrão

A terceira é o effort

Que negócio é esse? É o parâmetro que controla a profundidade do pensamento, e ele tem cinco níveis: low, medium, high, xhigh e max

O Opus 5 suporta todos, o padrão da API é high, o xhigh é indicado pras tarefas de código e agênticas mais difíceis, e o max pra tarefa que justifica gasto de tokens sem restrição

Se você conhece aquele ajuste de qualidade de render, é bem parecido: mesma ferramenta, esforço diferente

E tem uma orientação da própria documentação que vale colar na parede: modelos Opus e Sonnet recentes trocam inteligência por latência e custo dentro do MESMO modelo, então ajustar effort costuma ser uma alavanca melhor do que trocar de modelo

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

Onde o Opus vive:

No Claude Max ele é o padrão, no Claude Pro é o modelo mais forte disponível

Já no Claude Code o padrão é o Sonnet, que é a escolha certa pra maior parte do trabalho de código, e o Opus entra pra problema difícil: refatoração grande que cruza o código, depuração difícil e decisão de arquitetura

E a diferença de custo na API?

No Opus 5 dá pra economizar até 90% usando prompt caching e 50% no processamento em lote

E tem um detalhe silencioso que ajuda: o comprimento mínimo pra criar cache caiu pra 512 tokens no Opus 5, contra 1.024 no Opus 4.8, ou seja, prompt que era curto demais pra cachear agora vira entrada de cache sem você mexer em uma linha de código

Em que tipo de pedido o Claude Opus realmente rende (e em qual é desperdício)

A régua é simples: o modelo maior rende onde existe muita coisa pra segurar na cabeça ao mesmo tempo

1. Tarefa com várias restrições simultâneas:

É o pedido que só está certo se TODAS as condições baterem juntas

Pedido fraco:

escreve uma função de importação de CSV

Pedido que paga o Opus:

Escreva a importação de CSV do painel respeitando tudo isto ao mesmo tempo:
- arquivos de até 200 MB, sem carregar o arquivo inteiro em memória
- linha inválida não aborta a importação, ela vai pra um relatório de erro por linha
- a importação é idempotente: rodar o mesmo arquivo duas vezes não duplica registro
- nada de dependência nova, use só o que já está no package.json

Repare que aqui não tem "faça bonito": tem condição que conflita com condição

2. Decisão com trade-off:

Quando não existe resposta certa, existe escolha com preço

Pedido fraco: "qual banco eu uso?"

Pedido que paga o Opus: descreva o cenário real (volume, time, o que já roda, o que dói hoje), peça duas ou três opções, o custo de cada uma e qual você escolheria SE o critério for X

Modelo grande brilha quando precisa comparar caminhos, não quando precisa cuspir a opinião mais popular da internet

3. Código com dependências:

Refatoração que atravessa vários arquivos, bug que só aparece na combinação de duas camadas, decisão de arquitetura que muda o resto

Aqui o raciocínio mais profundo aparece de verdade, porque o modelo precisa segurar o mapa inteiro enquanto mexe numa peça

Uma dica de bastidor: em bug difícil, o que mais muda o resultado não é o modelo, é o insumo

Em vez de descrever o sintoma com suas palavras, vale debugar pelo log de erro e colar o material bruto

E onde é desperdício?

Em tudo que é rotina

Modelo maior consome mais tokens porque raciocina mais, então usar Opus numa tarefa que o Sonnet ou o Haiku resolveriam pode comer mais do seu limite sem necessidade

A orientação oficial é essa mesmo: modelo menor pra tarefa rotineira, modelo maior pra tarefa complexa ou ambígua

Renomear variável, gerar um CRUD já mastigado, formatar JSON, escrever um commit… isso não é trabalho de Opus, é trabalho de qualquer um 😀

Como estruturar o prompt para aproveitar o Opus, passo a passo

A base disso aqui serve pra qualquer modelo, e se você quiser o feijão com arroz de escrever prompts melhores no Claude, já tem post no blog

O que muda no Opus 5 são os últimos passos, que ninguém espera

1. Escreva TODAS as restrições explicitamente

Os modelos Claude 4.x em diante seguem instrução ao pé da letra e fazem exatamente o que foi pedido, nada mais

Quer comportamento de "ir além"? Tem que pedir isso explicitamente

Além de corrigir o bug, liste os outros lugares do código que têm o mesmo padrão

O erro comum deste passo: escrever o pedido como se o modelo fosse completar as lacunas com bom senso

2. Explique o motivo por trás da instrução

Dar contexto ou motivação, explicando por que aquele comportamento importa, ajuda o modelo a entender seu objetivo e devolver resposta mais direcionada

Não use bibliotecas novas nesta tarefa, porque este serviço roda em um ambiente sem acesso à internet no build

O erro comum deste passo: dar a regra sem o porquê, aí o modelo cumpre a letra e atropela a intenção

3. Separe as partes do prompt em tags XML

Quando o prompt mistura instrução, contexto, exemplo e entrada variável, tag XML tira a ambiguidade

A recomendação é envolver cada tipo de conteúdo na sua própria tag, com nomes consistentes e descritivos, aninhando quando existe hierarquia natural

<instructions>
Refatore o módulo de cobrança seguindo as restrições abaixo
</instructions>

<context>
Este código roda em produção e tem teste de integração em tests/billing
</context>

<input>
{cole aqui o arquivo}
</input>

O erro comum deste passo: inventar um nome de tag diferente a cada bloco, o que joga fora justamente a consistência que faz a coisa funcionar

4. Dê de 3 a 5 exemplos quando a tarefa é complexa

A recomendação é 3 a 5 exemplos diversos e relevantes, e mais exemplos tendem a melhorar o desempenho

Diversos é a palavra: três exemplos iguais ensinam um caso só

O erro comum deste passo: mandar um exemplo perfeito e nenhum caso de borda

5. Feche o escopo

Esse aqui é específico do Opus 5: ele tende a expandir a tarefa por conta própria, adicionando etapas que não foram pedidas ou aplicando o próprio julgamento sobre o que a tarefa deveria ser

Em tarefa estreita, a orientação é restringir o escopo explicitamente

Escopo desta tarefa: apenas o arquivo auth/session.ts
Não mexa em testes, não renomeie nada fora dele, não crie arquivo novo

O erro comum deste passo: pedir uma coisa pequena e receber uma reforma da cozinha inteira

6. Peça tamanho compatível com a tarefa

As respostas ao usuário e os entregáveis escritos do Opus 5 rodam mais longos por padrão que os dos Opus anteriores

A orientação é pedir que o tamanho case com a necessidade da tarefa: cobrir a substância, sem seção de enchimento, resumo redundante ou boilerplate

O erro comum deste passo: reclamar do texto longo em vez de dizer no prompt qual tamanho serve

7. Apague as instruções de verificação

Esse é o passo que dói no ego, porque todo mundo aprendeu a escrever isso

A documentação manda REMOVER instruções do tipo "inclua uma etapa final de verificação", "use um subagente para verificar", "confira sua resposta duas vezes" ou "reverifique antes de responder"

O Opus 5 verifica o próprio trabalho sem ser mandado, e essas frases causam verificação excessiva, gastam tokens à toa e não melhoram a qualidade

Dá uma olhada no guia oficial de prompting do Opus 5 se quiser ver isso na fonte

O erro comum deste passo: manter o "double check" do prompt antigo por superstição, e pagar por ele em token

8. Teste com a regra de ouro

A régua oficial é ótima: mostre seu prompt pra um colega com contexto mínimo sobre a tarefa e peça pra ele seguir o texto

Se ele ficaria confuso, o Claude também vai ficar

O erro comum deste passo: reler o próprio prompt sabendo tudo que está na sua cabeça e concluir que está claríssimo 😛

Onde isso muda no Claude Code:

No Claude Code o modelo se troca pelo comando /model, escolhendo no menu interativo

A troca vale na hora e dá pra trocar no meio da sessão sem perder a conversa

Tem também o modo híbrido /model opusplan, que usa Opus no modo de planejamento e troca automaticamente pro Sonnet na execução

E como trocar de modelo não limpa a conversa, o Sonnet continua enxergando tudo o que o Opus produziu

Se quiser fixar quais modelos entram nesse arranjo, as variáveis são ANTHROPIC_DEFAULT_OPUS_MODEL (usado como opus, e no opusplan quando o Plan Mode está ativo) e ANTHROPIC_DEFAULT_SONNET_MODEL (usado como sonnet, e no opusplan fora do Plan Mode)

O plan mode em si faz o Claude pesquisar e propor mudanças sem executar, com as edições bloqueadas até você aprovar o plano

Entra com Shift+Tab ou prefixando um único prompt com /plan, e volta ciclando com Shift+Tab de novo

Na API, se você for rodar xhigh ou max, dá espaço: a orientação é definir um max_tokens generoso pro modelo pensar e agir entre subagentes e chamadas de ferramenta, começando em 64k como padrão razoável

{
  "max_tokens": 64000,
  "effort": "xhigh"
}

Errou: é o prompt, o effort ou o modelo?

Aqui tem um critério oficial que resolve metade das discussões da internet

No Claude Code o ajuste é o comando /effort, que abre a escolha entre low (menos tokens, mais rápido), medium, high (mais tokens, mais inteligência), xhigh, max e auto (o Claude escolhe por requisição)

Repare que o menu traz uma opção a mais do que os cinco níveis do parâmetro: o auto não é um nível novo de profundidade, é o Claude escolhendo o nível a cada requisição

O nível atual aparece no cabeçalho da sessão, do lado do nome do modelo

low, medium, high e xhigh persistem entre sessões quando definidos numa sessão interativa

Já o max vale só pra sessão atual, exceto quando definido pela variável CLAUDE_CODE_EFFORT_LEVEL

E vale saber o que o effort controla ali dentro: não é só profundidade de raciocínio, é quanto trabalho o Claude faz no pedido como um todo, incluindo quantos arquivos ele lê, quantas ferramentas usa e quantos passos dá antes de voltar a falar com você

Como prevenir:

Quando o Claude erra, o primeiro instinto não deveria ser girar um botão, e sim examinar o contexto que você forneceu

Se você está subindo o effort numa tarefa que não deveria precisar disso, a correção normalmente está ANTES: no contexto, no CLAUDE.md ou em como a tarefa foi escopada

E a calibração é por tipo de trabalho, não tarefa a tarefa: começa nos níveis padrão de cada modelo e ajusta como preferência geral

Use low e medium liberalmente onde a qualidade se mantém, porque eles entregam qualidade forte a uma fração dos tokens, e sobe pra xhigh no trabalho de código e agêntico exigente

O que mudou na prática quando parei de mandar tudo para o Opus

No vídeo abaixo eu testo justamente esse arranjo: Opus planejando e outro modelo executando dentro do Claude Code

Entrei em plan mode pelo Shift+Tab ANTES de escrever o prompt, e o prompt inicial foi longo e específico de propósito

Descrevi o produto (um app de resenhas de livros), as telas, os cards com capa, título, autor e nota, o formulário campo por campo (título, autor, URL da capa, nota de 1 a 5, texto da resenha, nome de quem resenha) e o comportamento esperado do botão de like: incrementar e ficar salvo

No mesmo prompt eu já declarei os requisitos de qualidade e de infra: queria banco de dados real pros dados persistirem, queria visual profissional e não algo básico, e fechei pedindo pro modelo começar a planejar

E indiquei a stack (Next, Prisma e SQLite) em vez de deixar a escolha em aberto, justamente pra não complicar

Durante o planejamento ele me fez as perguntas de escopo e eu respondi curto e direto: sem abas, contador global anônimo, português do Brasil

Desenho fechado ANTES de qualquer execução

Depois saí do plan mode com Shift+Tab e deixei a execução seguir com o modelo de execução, aproveitando o alinhamento que já tinha sido feito no planejamento

O resultado apareceu funcionando na tela: cadastrei um livro com capa, publiquei a resenha, cliquei no like, o contador incrementou e os dados persistiram

Ao abrir o projeto eu bati num erro do Next e pedi a correção com um prompt curto, coisa que às vezes acontece de qualquer jeito

A criação inicial levou quase meia hora na minha máquina, e eu atribuo isso ao fato de ser o começo do projeto, não ao modelo: já fiz muito projeto e o prompt inicial sempre demora

Minha leitura honesta é essa: o ganho maior veio de reescrever o pedido, não de subir o modelo

Bom prompt economiza token e performa melhor em todos os sentidos

O Opus funciona bem como arquiteto que planeja e revisa, e quando ele encaminha bem o trabalho o modelo de execução erra menos nas tarefas simples

Mas tem o outro lado: quando o modelo de execução fica brigando com um problema e não resolve, o gasto pode acabar igual ou maior do que ter usado o Opus e resolvido de uma vez

Pra mim o Opus deveria preparar ainda mais o caminho, ou intervir no meio quando a execução trava

E tarefa trivial, tipo reiniciar o servidor (que eu mesmo tive que digitar), deveria cair num modelo menor, principalmente pra quem é leigo

O arranjo hoje ainda é manual e provavelmente temporário, tem bastante espaço pro próprio Claude Code escolher o modelo sozinho lá na frente…

No vídeo você vê o prompt de planejamento inteiro sendo escrito, as perguntas de escopo sendo respondidas e o app rodando no final

Resumo e o próximo passo

A régua cabe em três linhas:

• tarefa rasa e rotineira vai pra modelo menor, porque modelo maior raciocina mais e come mais do seu limite à toa
• tarefa com várias restrições, trade-off ou dependência entre partes do código vai pro Opus, com prompt explícito e escopo fechado
• erro de execução (pulou arquivo, não rodou teste, largou no meio) se corrige no effort e no contexto, não trocando de modelo

O próximo passo é bem concreto: pega o último prompt caro que você escreveu

Reescreve com as restrições todas declaradas, com o motivo de cada uma e com o escopo fechado

Apaga as instruções de verificação que você colou por hábito

E compara o resultado rodando em medium antes de sair subindo de modelo

É o teste mais barato que existe pra descobrir se o problema era o Claude ou o pedido 😀

até o próximo post!