🟢 Fundamentos do Opus 4.7

Curso prático em 4 trilhas para dominar o Claude Opus 4.7 no Claude Code, baseado em três referências oficiais da Anthropic de abril/2026.

O 4.7 não é "o 4.6 mais inteligente" — é um novo contrato. Quem não se atualizar vai piorar a performance com prompts antigos.

4 trilhas progressivas, ~20h totais, foco em prática imediata.

Lançamento em abril/2026 com três docs oficiais: Best Practices, Session Management e Prompting Best Practices.

Saber o contexto evita confundir quirks do modelo com bugs do seu código.

Tokenizer novo + tendência a pensar mais = mais tokens. Mas ganho em coerência, bug finding e ambiguidade.

T1 Básico (fundamentos), T2 Intermediário (produtividade), T3 Avançado (orquestração), T4 Expert (migração e produção).

Cada trilha é independente. Você pode pular se o nível já é compatível, mas a T1 calibra o vocabulário comum.

7 módulos por trilha, 6–8 tópicos por módulo, projeto final na T4.

Claude Code instalado, terminal, git básico, experiência mínima com 4.6.

Sem esses fundamentos, os exemplos práticos não rodam.

Não precisa Max para T1/T2. Auto mode exige Max na T3.

T1: reconhece diferenças. T2: escreve bons briefings. T3: orquestra autonomia. T4: audita produção.

Esperar o que não é da trilha gera frustração. Calibre expectativa.

Cada trilha tem um self-check final.

Claude Code atualizado, modelo claude-opus-4-7, effort default xhigh.

Usuários existentes são upgradeados automaticamente para xhigh se nunca setaram effort.

Verifique com /usage se está no 4.7.

Quick-check de 5 perguntas ao fim da T1 antes de abrir a T2.

Evita avançar com hábitos velhos ainda ativos.

Se erra 2+, releia a T1.

Novo nível de effort entre high e max, recomendado para 80% dos casos de coding agêntico.

Usuários que nunca configuraram effort foram upgradeados automaticamente para xhigh — entender é essencial.

Forte autonomia sem consumo descontrolado que max produz em runs longos.

O modelo decide dinamicamente quando e quanto pensar a cada passo, baseado em effort + complexidade.

budget_tokens fixo está deprecated. Código antigo precisa migrar.

thinking: {type: "adaptive"} é a única opção agora.

O 4.7 prefere raciocinar mais e delegar menos. Dispara menos tools e subagentes que o 4.6.

Se seu workflow dependia de busca agressiva, agora parece "preguiçoso" — precisa pedir explicitamente.

Na maioria dos casos, essa economia produz melhor resultado.

Se você diz "aplicar na seção 1", ele aplica só na seção 1 — não infere que queria em todas.

Upside: mais precisão. Downside: se quer amplitude, declare escopo explicitamente.

"Apply this to every section, not just the first one."

Tokenizer atualizado + tendência a pensar mais = consumo maior que 4.6 no mesmo prompt.

Não é bug, é design. Calibre orçamento.

A qualidade extra compensa na maioria dos casos.

Lida melhor com ambiguidade, +11pp de recall em bug finding, carrega contexto entre sessões com mais confiança.

São as áreas onde delegar vale mais a pena.

Tarefas com supervisão como gargalo agora rodam mais sozinhas.

3 sinais no output: respostas calibradas à complexidade, menos tool calls desnecessárias, seguimento literal.

Valida visualmente que está usando 4.7.

Se está verboso demais, provavelmente é 4.6.

Tokenizer atualizado no 4.7 — mesma string pode ter contagem diferente que no 4.6.

Comparações de token 4.6 vs 4.7 precisam contar a nova métrica.

Não é percentagem fixa — varia por conteúdo.

4.7 tende a pensar mais em turnos posteriores de sessões longas — melhora coerência mas consome mais.

Sessões curtas bem briefadas são mais eficientes em tokens que sessões longas drip-fed.

Compactar proativamente ajuda.

Slash command que mostra consumo da sessão atual e histórico.

Sem medição, não há calibração.

Rode antes e depois de mudar prompts.

4.7 consome mais mas entrega mais valor por turno. Em tarefas complexas, o custo total cai.

Olhar só tokens/sessão engana. Olhe tokens/tarefa concluída.

Unidade correta: tokens por feature entregue, não por turno.

Tabela-base: bug fix ~5–15k tokens, feature ~30–80k, refactor multi-arquivo 100k+.

Detectar consumo anormal cedo.

Consumo 3× acima da baseline = briefing ruim.

Sessões drip-fed, scaffolds antigos ("every N calls"), leituras repetidas de mesmo arquivo.

Esses padrões multiplicam consumo silenciosamente.

Auditoria periódica de prompts evita.

Effort calibrado por tarefa, briefing completo, compactação proativa.

Economia vem de combinar várias pequenas decisões, não de um único truque.

Rodar em low quando apropriado é legítimo.

No 4.6, guiava linha a linha funcionava — "olha isso, faz aquilo, ajusta isso".

Reconhecer esse estilo é o primeiro passo para aposentá-lo.

Muitos turnos, cada um curto — o oposto do novo contrato.

Briefing completo + autonomia calibrada. Você vira "gerente", o Claude vira "sênior delegado".

Extrai 2–3× mais valor por hora com menos tokens.

Menos turnos, cada um denso.

Drip-feed: 4 turnos curtos. Briefing: 1 turno com intent+constraints+critério+arquivos.

Ver lado a lado dissolve a tentação de voltar ao drip.

Menos turnos ≠ menos detalhe. É mesmo detalhe condensado.

"Olha isso", "double-check", "MUST use", "every N calls", "be conservative", budget_tokens.

Cada um hoje ativamente atrapalha.

Audite e aposente.

ICCA no turno 1, effort calibrado, adaptive thinking com frases-gatilho, rewind em vez de corrigir, subagente explícito, safety prompt.

São os 6 eixos do resto do curso.

Adote progressivamente, 1 por semana.

Pegue seu último prompt real, diagnostique qual contrato estava em jogo e reescreva no novo.

Teoria sem prática não muda hábito.

Execute ambos e compare turnos + tokens.

Exploração aberta, aprendizado de domínio novo, decisão de arquitetura em aberto.

A regra não é absoluta — há casos reais em que diálogo iterativo ganha.

Minoria dos casos, mas existem.

Claude Code atualizado, modelo 4.7, effort xhigh (default).

Ambiente pronto = exercício flui.

Verifique com /usage.

Template ICCA aplicado a um bug fix real do seu backlog.

Primeira vitória curta gera confiança.

Se não tem bug real, use um do repo opus47.

Envie o briefing e não interrompa — observe o 4.7 executar sozinho.

Interromper cedo é o hábito mais difícil de largar.

Só fale se ele perguntar ou terminar.

Marque: quantas tool calls, quantos arquivos lidos, se pediu confirmação.

Entender o padrão do 4.7 calibra expectativas.

Documente para comparar depois.

Rode o mesmo prompt 2 vezes: uma em low, outra em xhigh.

Sentir a diferença na pele vale mais que ler sobre ela.

Em low, 4.7 pode parar mais cedo — é respeito a effort.

"Play a sound when you finish this task" — o Claude cria seus próprios hooks.

Libera você para outras coisas enquanto ele trabalha.

Especialmente útil em tarefas de 5+ minutos.

Pergunte ao Claude: "o que você decidiu sozinho que eu poderia ter especificado?".

Ele te ajuda a melhorar seus próximos briefings.

Loop de feedback rápido.

Prepare um briefing ICCA e rode em 4.6 e 4.7 com configs equivalentes.

Comparar estilos e decisões nativas dos dois.

Congele tudo menos o modelo.

Turnos humanos, tokens totais, tempo até concluir, tamanho do diff final.

Sem métricas, "parece melhor" é ilusão.

Anote antes de rodar.

Em xhigh, a primeira resposta demora mais — mas entrega mais sem precisar de turnos extras.

Trocar latência por conclusão sem drip é ganho.

Medir por tarefa, não por resposta.

Ambiguidade alta, bug finding, refactor multi-arquivo, code review profundo.

Esses são os casos onde o upgrade se paga.

Priorize 4.7 nessas tarefas.

Usar prompt antigo (4.6) no 4.7 e chamar de "regressão" — o prompt é o problema, não o modelo.

Evita conclusões erradas.

Refatore o prompt antes de comparar.

Tabela: modelo, turnos, tokens, tempo, qualidade percebida, surpresas.

Um relatório = consolidação do aprendizado.

Guarde para revisitar em 3 meses.

3 mudanças que você fará no seu próximo prompt real, direto do experimento.

Experimento sem ação = tempo perdido.

Sempre saia com 3 ações.

10 perguntas objetivas sobre seu workflow atual.

Mapeia exatamente onde você está em relação ao 4.7.

Mais de 4 "sim" = dívida técnica de prompts.

Você manda arquivos "conforme Claude pede" em vez de listar no turno 1.

Dobra ou triplica tokens por tarefa.

Cura: seção "A" do ICCA.

Seus prompts têm linguagem agressiva herdada do 4.6.

Hoje causa over-trigger e over-thinking.

Cura: linguagem normal ("Use tool X when…").

Código que ainda usa extended thinking com budget fixo.

Deprecated — precisa migrar.

Cura: thinking: adaptive + effort.

1 hábito novo por dia, cumulativo. Dia 7 = todos ativos.

Mudança gradual sustenta.

Marcador diário simples.

Turnos por tarefa (↓), tokens por tarefa (↓), tempo de supervisão (↓).

Dashboard pessoal = motor de melhoria contínua.

Baseline vem da T1. Compare após T2.

5 perguntas rápidas sobre conceitos-chave da T1.

Valida entendimento antes de avançar.

Errou 2+? Revisite antes de ir para T2.