Per-message effort no Claude Fable 5.1: dá para mudar o nível de raciocínio no meio da conversa?

Em conversa longa, subir o nível de raciocínio saía caro: o prompt cache inteiro ia junto

Fala aí, beleza? A Anthropic anunciou hoje, 01/09/2026, o Claude Fable 5.1 (junto do Mythos 5.1), primeira atualização da linha desde o Fable 5, que saiu em 9 de junho

E entre as novidades tem uma que mexe direto nessa dor: o per-message effort, que chega em beta e promete deixar você mudar o nível de raciocínio no meio da conversa sem detonar o cache

Bora entender o que isso significa na prática?

O que é o per-message effort e por que ele apareceu agora

Effort é o controle de quanto raciocínio o modelo aplica na resposta

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 116 aulas
• 4 projetos
• 9h 23min

Conhecer formação

Na Messages API ele mora dentro de output_config, assim:

{
  "model": "claude-fable-5-1",
  "output_config": { "effort": "high" },
  "messages": []
}

O padrão da API é high, e a doc de prompting do 5.1 recomenda justamente começar por aí e depois testar low, medium, xhigh e max contra as suas próprias evals

E qual era o problema? O comportamento padrão do output_config.effort é por requisição (request-level)

Como o effort molda o prompt renderizado, mudar o valor entre requisições não preserva os prefixos que já estavam em cache dos turnos anteriores

Por isso a orientação padrão da documentação sempre foi meio chata: escolhe um nível no começo e segura ele até o fim, principalmente em sessão longa que depende de cache

O beta do effort por mensagem nasce pra quebrar essa regra

Ele é um dos cinco recursos aditivos do Fable 5.1, ao lado das turn-scoped system messages (beta), das atualizações de progresso legíveis entre chamadas de ferramenta (o display: "updates", também beta), do preço menor de leitura de cache e do content provenance

Pra usar, tem header beta obrigatório: mid-conversation-output-config-2026-07-01

E só os níveis nomeados são aceitos: low, medium, high, xhigh e max

O snippet acima é o uso no nível superior da requisição, que aliás não exige header beta nenhum

Ou seja: o header é o que libera a troca no meio da conversa, o uso request-level segue funcionando do jeito de sempre

O que muda em relação ao Fable 5

No Fable 5, output_config.effort era request-level e ponto final

Trocou de nível no meio da sessão? Os prefixos em cache caíam, e você era obrigado a reescrever o histórico inteiro a preço de cache write

Em conversa agêntica, com histórico gordo, isso é aquele tipo de decisão que você evita tomar só pra não pagar a conta

No 5.1, mudar o effort parcialmente ao longo da conversa não invalida o prompt cache

Dá pra subir numa etapa difícil e baixar nas rotineiras dentro da mesma thread

E tem um segundo efeito que empilha em cima disso: a leitura de cache caiu para US$ 0,25 por milhão de tokens, contra US$ 1 por milhão no Fable 5

Queda de 75%, se liga

A Anthropic estima cerca de 25% mais barato em cargas típicas e até aproximadamente 45% em cargas altamente agênticas

O resto do preço segue igualzinho ao Fable 5: US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de tokens de saída

Fable 5 x Fable 5.1: effort, cache e preço

O identificador do 5.1 na API é claude-fable-5-1, aquele mesmo do snippet lá de cima

Quando vale subir e quando vale baixar o effort

Pensa numa sessão agêntica de verdade

Tem o momento de mapear o repositório, tem o momento de escrever um patch chato num arquivo enorme, e tem um monte de passo burocrático no meio: renomear coisa, rodar comando, formatar saída, confirmar resultado

Não faz sentido pagar raciocínio máximo em todos eles

O desenho que o beta permite é mais ou menos esse:

• Sobe pra xhigh ou max na etapa de arquitetura, na investigação de bug esquisito, na decisão que vai contaminar o resto da sessão
• Desce pra low ou medium nas tarefas mecânicas e repetitivas, tipo aplicar um padrão que já foi decidido, ou converter um script entre linguagens sem mudar o comportamento
• Volta pro high quando o trabalho pesado retorna, sem perder o histórico já cacheado

E aqui entra um detalhe que muda o cálculo: o Fable 5.1 entrega resultados similares ou melhores que o Fable 5 já em low e medium effort, com desempenho bem maior nos níveis altos

Ou seja, descer o nível no 5.1 dói MUITO menos do que descer o nível parecia doer antes

Quem quiser ver esse raciocínio montado num fluxo inteiro, a Claude Platform tem a página Build an orchestration mode, que combina effort com mensagens de sistema no meio da conversa

Detalhe importante desse exemplo: ele define o effort no nível superior de cada requisição, o que não exige header beta

Três quebras de compatibilidade para quem já chamava o Fable 5

O 5.1 é aditivo em quase tudo, mas o guia de migração lista três coisas que quebram:

1. Forced tool use retorna erro
2. Modelos anteriores não conseguem ler os thinking blocks do 5.1
3. Editar turnos anteriores invalida thinking blocks

Esse terceiro pega quem monta histórico na mão e gosta de reescrever mensagem antiga antes de mandar de novo

Vale também olhar o pacote de headers beta mid-conversation que veio junto, porque esse beta não está sozinho nessa família:

• mid-conversation-tool-changes-2026-07-01 para mudança de ferramentas no meio da conversa
• mid-conversation-system-clear-at-2026-08-21 para as turn-scoped system messages
• thinking-binding-controls-2026-08-01 para os controles de thinking block

São flags separadas, então habilitar uma não habilita as outras

Onde o Fable 5.1 já está disponível

A lista de superfícies já é ampla desde o lançamento:

• claude.ai e os apps do Claude (Pro, Max, Team e Enterprise)
• Claude Code
• Claude Cowork
• Claude Developer Platform
• Amazon Bedrock
• Google Cloud
• Microsoft Foundry

A conta ClaudeDevs anunciou o Fable 5.1 live no Claude Code e na Claude Platform, mesmo preço do Fable 5, com leituras de cache 75% mais baratas na API

Se você já passou por aquele susto de modelo aparecendo indisponível logo depois de um lançamento, vale conferir a superfície que você usa antes de sair mudando código

E tem a distinção entre os dois irmãos: o Fable 5.1 é de disponibilidade geral, enquanto o Mythos 5.1 fica restrito a empresas e pessoas dos EUA em programas de acesso confiável da Anthropic

Mesmo modelo, níveis diferentes de salvaguarda

Vale ativar o beta agora?

Resposta honesta: depende de onde você roda

O recurso está em beta e depende de header, então o ganho real aparece pra quem chama a Messages API direto e mantém conversa longa e agêntica viva por muito tempo

Quem usa o modelo pelo chat não precisa fazer nada, o benefício de preço de cache já vem embutido de qualquer jeito

O caminho mais sensato pra testar é o que a própria doc sugere: começa no high, testa low, medium, xhigh e max contra as suas evals, e mede o efeito no cache antes de assumir que ficou mais barato

E se você vive em sessão longa chamando a API na mão, esse é dos betas mais fáceis de justificar: header ligado, nível nomeado escolhido, e o histórico continua cacheado

Bora testar?

Até o próximo post! 😀