Opus 4.8 no Claude Code: novidades, preços e como mudar em 2026

Documentação de referência do Ailoot: ailoot.ai/docs/.

O que foi lançado no Claude Code a 28 de maio#

A 28 de maio, a Anthropic lançou o Opus 4.8 — 41 dias depois do Opus 4.7. O Claude Code v2.1.154 e a publicação “Introducing dynamic workflows in Claude Code” foram lançados no mesmo dia. No dia seguinte, a v2.1.156 corrigiu um erro nos blocos de raciocínio que fazia a API falhar no Opus 4.8.

Quatro mudanças que afetam todos os que programam no Claude Code:

1. O novo modelo Opus 4.8 — os mesmos preços ($5/$25 por milhão de tokens), mas benchmarks superiores e uma probabilidade 4 vezes menor de não detetar erros no seu próprio código.
2. Dynamic Workflows — o Claude escreve um script JS que pode lançar até 1000 subagentes ao longo de uma execução, com no máximo 16 ativos em simultâneo. O gatilho é a palavra workflow no prompt.
3. xhigh effort — um novo nível de raciocínio. O predefinido no Opus 4.8 é agora high; para tarefas exigentes, pode aumentá-lo para xhigh.
4. O Fast Mode ficou 3 vezes mais barato — custava 6× o preço padrão; agora custa 2× e é 2.5× mais rápido.

A própria Anthropic fala deste lançamento com cautela:

Neste guia, vou mostrar exatamente o que mudou, quanto custa na prática e se deve mudar já ou esperar.

Em que difere o Opus 4.8 do 4.7?#

O que melhorou nos números

A Anthropic publicou benchmarks no seu anúncio oficial e na documentação da API Claude. Eis a tabela-resumo:

⚠️ Estes são valores publicados pelo fornecedor — números da Anthropic, não uma medição independente.

A principal promessa: “4× menos probabilidade de não detetar erros”

A Anthropic afirma:

Parece ótimo, mas há uma nuance subjacente: segundo o System Card da Anthropic, o Claude Opus 4.8 teve a taxa mais baixa de respostas incorretas entre seis modelos em todos os benchmarks, porque se abstém quando não tem a certeza.

Traduzido da linguagem do System Card para a linguagem de quem programa por intuição: o modelo não ficou 4 vezes mais inteligente. Passou a dizer “não tenho a certeza, confirme isto” com mais frequência, em vez de produzir uma alucinação plausível. Honestidade em vez de aumento de QI — foi assim que evoluiu.

Na prática, isto significa que, nas mesmas tarefas em que o Claude costumava mentir com confiança, agora dirá: “Não tenho a certeza disto.” Isso reduz o risco, mas não aumenta a cobertura.

O que se manteve igual

• Preço padrão ($5 por milhão de tokens de entrada, $25 por milhão de tokens de saída) — inalterado.
• Data-limite de conhecimento — janeiro de 2026, tal como no 4.7.
• Contexto predefinido — 1 milhão de tokens na API da Anthropic, AWS Bedrock e GCP Vertex AI. No Microsoft Foundry — 200K.
• Máximo de saída — 128K tokens.
• Parâmetros de amostragem (temperature, top_p, top_k) — continuam sem suporte; devolvem um erro 400.

Onde o Opus 4.8 fica aquém

Sinceramente: no Terminal-Bench 2.1, o Opus 4.8 obtém 74.6% — nada mau, mas não lidera a categoria. Se a maior parte do seu trabalho decorre no terminal, tenha isto em conta: o Codex é muitas vezes um pouco melhor em tarefas exclusivamente de terminal. O Opus 4.8 está à frente nos outros benchmarks, mas esta diferença é real.

O segundo ponto franco: em pipelines agênticos complexos com entradas não verificadas (análise de sites, leitura de RSS), a proteção contra injeção de prompts no Opus 4.8 não é garantida. Se estiver a criar automatizações que leem documentos de outras pessoas, use um sanitizador de entradas separado.

Quanto custa o Opus 4.8 em 2026?#

Escalões de preços

O preço padrão manteve-se igual ao do 4.7 e do 4.6. É raro — as novas gerações costumam custar mais. O Fast Mode ficou 3 vezes mais barato: no 4.6 e no 4.7, o modo rápido custava 6× o preço padrão. No 4.8, custa 2×.

O que significa por hora de trabalho

Uma hora de programação ativa no Claude Code com o Opus 4.8 corresponde a cerca de 1–2 milhões de tokens de entrada e 100–300 mil tokens de saída. Aos preços padrão, isso representa $5–10 pela entrada e $2.5–7.5 pela saída. Arredondando, são $8–15 por hora apenas na API.

Nos planos de subscrição:

• Pro ($20/mês) — chega para 1–2 horas de trabalho ativo por dia. Um único prompt exigente com um Dynamic Workflow esgota o limite.
• Max 5x ($100/mês) — 4–6 horas por dia, de forma consistente. O ponto ideal para a maioria de quem programa por intuição.
• Max 20x ($200/mês) — um dia inteiro de trabalho sem se preocupar com o limite. Faz sentido se lançar muitos workflows ou trabalhar com o Agent SDK.

Mais detalhes nos guias como não esgotar os limites do Claude Code e para onde vão os tokens.

Uma execução grande pode consumir uma parte substancial do limite, mesmo com no máximo 16 agentes em simultâneo. Verifique a utilização disponível e defina um orçamento antes de lançar; a concorrência, por si só, não determina o custo total.

⚠️ O Fast Mode não está incluído nos planos Pro / Max / Team / Enterprise. É necessário ativar créditos de utilização e é faturado à parte, a $10/$50 por milhão de tokens, além da subscrição. Se tiver o Max e ativar o Fast Mode sem créditos, receberá uma mensagem a dizer que tem de carregar o saldo. É fácil não reparar nisto ao ler a documentação.

O que são os Dynamic Workflows no Claude Code?#

Em que difere um workflow de um subagente e de uma skill

Anteriormente, tudo o que o Claude Code fazia de forma autónoma recorria à orquestração turno a turno. Em cada turno, o Claude decidia que ferramenta chamar, e os resultados intermédios ficavam no seu contexto. Isto funciona com até 4–5 subagentes; acima desse número, o contexto transborda.

Dynamic Workflow altera o padrão. O Claude escreve um script JavaScript que orquestra os próprios agentes. Os resultados intermédios ficam nas variáveis do script, não no contexto do Claude. Só o resultado final regressa ao contexto. Isto tem três efeitos:

1. Pode lançar até 16 agentes em paralelo, até 1000 no total por execução.
2. O contexto do Claude não transborda — cada subagente trabalha na sua própria sandbox.
3. O script é reutilizável — depois de uma execução bem-sucedida, prima s em /workflows para o guardar como comando de barra.

A documentação de workflows da Anthropic explica-o assim:

Limites do ambiente de execução

Três formas de ativar um workflow

1. A palavra workflow no prompt. “Executa um workflow para auditar todos os endpoints da API em src/routes/ à procura de verificações de autenticação em falta”. O Claude deteta o gatilho, escreve um script e lança-o.
2. /effort ultracode — combina o raciocínio xhigh com a orquestração automática de workflows. Aplica-se a todas as tarefas substanciais da sessão. A documentação diz:

3. /deep-research [question] — um workflow integrado para investigação com pesquisa na Web e cruzamento de fontes.

Exemplo: Bun em 750,000 linhas de Rust em 11 dias

A equipa do Bun usou Dynamic Workflows numa experiência: portar o Bun de Zig para Rust. Segundo o blogue da Anthropic:

• ~750,000 linhas de Rust geradas.
• 11 dias desde o primeiro commit até à integração.
• 99.8% dos testes da suite existente passaram.
• ~300 regras para traduzir Zig → Rust.

O padrão técnico consistiu em três workflows consecutivos:

1. O Workflow #1 mapeia o tempo de vida Rust correto para cada campo de estrutura na base de código Zig.
2. O Workflow #2 escreve cada ficheiro .rs como uma versão portada, com comportamento idêntico, do ficheiro .zig correspondente. Centenas de tarefas de ficheiros distribuídas por lotes, com no máximo 16 agentes em simultâneo e dois revisores por ficheiro.
3. O Workflow #3 é um ciclo de correções: executa a compilação + os testes até tudo passar.

A principal armadilha: os workflows esgotam o limite em tarefas pequenas

Conclusão prática: se uma tarefa puder ser resolvida por 1–2 subagentes simples, não use um workflow; recorra manualmente a subagentes. Os workflows compensam em 50+ ficheiros, não em 5.

Um workflow pode distribuir trabalho por até 1000 lançamentos de agentes no total, agendando no máximo 16 em simultâneo. Sem contexto partilhado do projeto, os erros podem acumular-se nesses lotes, porque cada agente vê apenas a sua parte.

Quando deve ativar o xhigh effort?#

Nas notas de lançamento do Claude Code v2.1.154, a Anthropic afirma explicitamente: o Opus 4.8 funciona com effort=high por predefinição — este é o novo padrão após o lançamento. Antes, o padrão era inferior. O novo nível xhigh está disponível além desse, para as tarefas mais exigentes, nas quais o modelo usa mais tokens de raciocínio em cada turno.

Quando usar xhigh:

• Migrações (novo padrão arquitetural → 50+ ficheiros).
• Auditorias de segurança (análise de segurança de 200+ endpoints).
• Refatorizações planeadas com verificações de invariantes.
• Sessões de depuração complexas e longas em que o modelo tem de se lembrar de todo o percurso.

Quando NÃO o usar:

• Alterações de rotina num ficheiro (escrever um teste, mudar o nome de um método).
• Prompts simples com uma estrutura clara.
• Documentação / comentários — o xhigh tem um custo adicional nestes casos.

No Claude Code v2.1.154, o controlo deslizante de esforço passou de “Speed/Intelligence” para “Faster/Smarter”. O /effort high predefinido é agora aplicado internamente; não precisa de o selecionar explicitamente.

Quando deve usar o Fast Mode?#

Preços:

Quando usar:

• Tarefas interativas em que o tempo de resposta é mais importante do que a precisão (revisão de código em direto durante uma transmissão).
• Alterações rápidas e teste de hipóteses.
• Uma demonstração / apresentação a um cliente.

Quando NÃO usar:

• Trabalho agêntico de longa duração — o preço 2× num contexto de 1M prejudica a economia.
• Um Dynamic Workflow grande — o Fast Mode duplica as tarifas de tokens aplicáveis e a utilização acumula-se em todos os agentes lançados. O limite total de 1000 lançamentos não é um multiplicador fixo de custo de 1000×; faça o orçamento pela entrada e saída agregadas reais.
• Sessões em segundo plano em que a velocidade não é essencial.

Como mudar para o Opus 4.8 sem perder as definições?#

Passo 1. Atualize o Claude Code

No terminal:

claude upgrade

Ou reinstale-o seguindo a documentação da Anthropic.

⚠️ A versão pretendida é v2.1.156 ou posterior. A v2.1.154 tinha um erro: ao usar o Opus 4.8, os blocos de raciocínio eram alterados, o que causava erros na API. O erro foi corrigido na v2.1.156.

Confirme a versão:

claude --version

Passo 2. Mude o modelo em /config

No Claude Code:

/model claude-opus-4-8

Ou abra /config → secção Model → selecione Opus 4.8 na lista. O ID do modelo no endpoint da API é claude-opus-4-8.

Passo 3. Ative Dynamic Workflows (plano Pro)

Dynamic Workflows estão desativados por predefinição no plano Pro. Abra /config → secção Workflows → ative-os. Estão ativados desde o início nos planos Max, Team e Enterprise pessoal. No Enterprise com administrador, este pode tê-los desativado; peça-lhe que os ative.

Passo 4. Faça um teste

No Claude Code, peça uma tarefa simples com um resultado claro para confirmar que o modelo responde corretamente:

Write a TypeScript function that splits an array into chunks of a fixed length.
Give me tests in vitest.

Se a resposta for adequada e a expressão “using claude-opus-4-8” aparecer no início, a mudança foi bem-sucedida. Se surgir um erro 400, confirme a versão do Claude Code (volte ao passo 1).

O que NÃO precisa de migrar

• CLAUDE.md funciona com qualquer modelo sem alterações. Mais detalhes no guia como configurar CLAUDE.md.
• Skills são reconhecidas automaticamente pelo Opus 4.8. Mais detalhes no guia Claude Code Skills.
• Servidores MCP funcionam da mesma forma. O guia de MCP inclui 7 combinações prontas a usar.
• Subagentes e Plan Mode não mudaram. Um resumo da escolha entre Skills, Subagents, MCP e Plugins está na página de referência.

Deve mudar do Sonnet 4.6 ou do Haiku 4.5?#

Já abordei a escolha entre Sonnet e Opus num guia anterior, mas era sobre o 4.7. As regras mudam um pouco com o Opus 4.8.

Matriz de decisão para 2026:

Para a maioria de quem programa por intuição, o ponto ideal é o Sonnet 4.6 como modelo predefinido, mais o Opus 4.8 para tarefas exigentes através do seletor /model. Assim, paga menos e continua a tratar corretamente das tarefas exigentes.

O que NÃO funciona no Opus 4.8?#

Três áreas em que o Opus 4.8 fica aquém, segundo relatos práticos:

1. Estratégia e roadmaps com muitos dados. Relatos práticos indicam que o 4.7 continua a ser preferível para análise. Se o seu principal caso de utilização for criar uma tabela de métricas e propor um roadmap, experimente primeiro o 4.8; se não resultar, volte ao 4.7 usando /model claude-opus-4-7.

2. “Os últimos 10%” em bases de código existentes. O modelo trabalha muito bem em projetos greenfield (um projeto novo, desde o início), mas tem dificuldades ao amadurecer código antigo — casos-limite e particularidades específicas da arquitetura. É uma fragilidade típica dos modelos de raciocínio: geram bem, mas têm dificuldade em “acabar” algo que já existe.

3. As alucinações persistem. “4× menos probabilidade de não detetar erros” significa que o modelo diz “não sei” com mais frequência, mas, quando o contexto é insuficiente, ainda pode produzir uma invenção plausível. A proteção é o contexto do projeto: quanto mais completo for o CLAUDE.md, menos espaço há para alucinações.

Isto não significa “não atualize”. Significa: compreenda as limitações e mantenha o Sonnet 4.6 e o Opus 4.7 como alternativas de recurso.

O que vem depois do Opus 4.8?#

Na formulação da Anthropic, “próximas semanas” costuma significar 4–8 semanas. Por outras palavras, é muito provável que um modelo da classe Mythos seja lançado em junho–julho de 2026. Isto altera a estratégia:

• Se os seus projetos atuais usam o Sonnet 4.6 ou o Opus 4.7 — atualize para o 4.8 e experimente o xhigh e os workflows em tarefas específicas. É uma atualização gratuita em termos de preço.
• Se planeou uma grande migração com um workflow — não tenha pressa. Poderá surgir dentro de um ou dois meses um modelo ainda melhor para o fazer. Pode começar por uma experiência num módulo para perceber como funciona.
• Se ia reconstruir a infraestrutura à volta de Dynamic Workflows — espere. O Mythos pode alterar os padrões subjacentes.

Essa incerteza é o principal conselho: mantenha-se flexível. O Opus 4.8 é uma boa atualização incremental. O Mythos poderá representar um salto. Não invista numa reformulação importante um mês antes de um possível novo modelo.

Continue a explorar o Ailoot em ailoot.ai.