Claude Fable 5.1 chegou: o quanto ele é melhor que o Opus 5 (e quando não vale a pena)

A Anthropic soltou o Claude Fable 5.1 hoje, 1º de setembro de 2026, junto com o Mythos 5.1. Ele assume o topo da linha: é o modelo mais capaz da Anthropic disponível pra qualquer cliente, e ganha do Opus 5 em praticamente todo benchmark publicado.

Só que essa não é a pergunta que interessa.

A pergunta é: ele é melhor o suficiente pra você pagar o dobro do preço por token? Porque input do Fable 5.1 é $10/MTok contra $5 do Opus 5. Output é $50 contra $25. E em boa parte dos benchmarks a diferença entre os dois é de dois, três pontos percentuais.

Neste post eu abro os números oficiais do anúncio, faço a conta real de uma sessão agentic com cache quente (spoiler: a razão de custo não é 2x), e monto a árvore de decisão entre Fable 5.1, Opus 5 e Sonnet 5 — incluindo a recomendação da própria Anthropic, que é bem menos entusiasmada do que o anúncio sugere.

TL;DR

• O que é: Claude Fable 5.1, o modelo mais capaz da Anthropic com disponibilidade geral. Sucessor do Fable 5, lançado em 01/09/2026.
• Model ID: claude-fable-5-1 · janela de 1M tokens · 128k de output · thinking adaptativo sempre ligado.
• Custo/Acesso: $10 input / $50 output por milhão de tokens. Cache read despencou pra $0.25/MTok. Disponível na Claude API, Claude Code, claude.ai, AWS, Google Cloud e Microsoft Foundry.
• Link útil: anúncio oficial e o que mudou na API.

O que mudou no Claude Fable 5.1

O Fable 5.1 é uma extensão do Fable 5, não um modelo novo do zero. Mesmo tokenizer, mesma janela de 1M, mesmo preço de input e output. O que mudou de fato:

O cache read caiu 75%. Esse é o número que mais importa e o que menos aparece nas manchetes. Em todos os modelos Claude, uma leitura de cache custa 0.1x o preço do input. No Fable 5.1 (e no Mythos 5.1) ela custa 0.025x — $0.25 por milhão de tokens, contra $1 do Fable 5. É a primeira vez que a Anthropic quebra esse multiplicador. Segundo o anúncio, isso derruba o custo em ~25% para workloads típicos e até ~45% para trabalho agentic pesado.

Capacidade concentrada em sessão longa. A documentação lista seis áreas de ganho: coding agentic em sessões de horas, trabalho com documento/planilha/slide, pesquisa multistep, visão em PDFs densos, raciocínio ao longo da janela de 1M e computer use. Note o padrão: são todas tarefas de horizonte longo. Ninguém prometeu que ele responde melhor a um prompt de classificação.

Mythos 5.1 é o mesmo modelo com outro conjunto de salvaguardas, liberado só pra participantes do Project Glasswing — pesquisa verificada em cibersegurança e ciências da vida. Se você não está no programa, esse modelo não existe pra você.

Aqui vale a nota chata que ninguém lê antes de migrar: Fable 5.1 e Mythos 5.1 exigem retenção de dados de 30 dias. Não rodam sob zero data retention sem autorização expressa da Anthropic, e uma request de org com ZDR volta com 400 invalid_request_error. Se sua empresa tem cláusula de ZDR em contrato, a discussão de modelo acabou antes de começar.

Escolher modelo virou decisão semanal, e decisão semanal errada vira linha fixa na fatura todo mês. É esse tipo de conta que a gente abre ao vivo, toda semana, no Clã Beer and Code: eval rodando em cima do código do aluno, não benchmark de anúncio.

O quão melhor que o Opus 5, de fato

Vamos aos números. Todos os que seguem vieram do anúncio oficial da Anthropic:

Olha essa tabela com olho de engenheiro, não de fã.

Uma linha é um massacre. Terminal-Bench-Science: 52.6% contra 29.0%. É quase o dobro do Opus 5, num benchmark que mede o agente executando trabalho científico real no terminal — instalar dependência, rodar experimento, interpretar erro, tentar de novo. Esse é o ganho de verdade.

O resto é margem estreita. Terminal-Bench 4.0: 3.5 pontos. CursorBench: 3.4 pontos. OSWorld: 2.1 pontos. HLE com tools: 1.4 ponto. GDPval: 29 pontos de Elo, o que é ruído em boa parte dos casos de uso. São ganhos reais e consistentes — o Fable 5.1 ganha em todas as linhas —, mas nenhum deles justifica sozinho dobrar o preço por token.

O Vals Index, que é avaliação independente, conta a mesma história: Fable 5.1 em primeiro com 67.87%, Opus 5 em 67.21%, Fable 5 em 66.04%. Diferença de 0.66 ponto entre o melhor modelo do mundo e o irmão que custa metade.

A leitura honesta é essa: o Fable 5.1 não é um Opus 5 mais inteligente. É um Opus 5 que aguenta ficar acordado mais tempo. Quanto mais longa e mais autônoma a tarefa, maior a distância. Numa tarefa de um turno, os dois empatam.

E ganho de benchmark não é a única variável. Se você acompanhou a discussão sobre regressão percebida no Opus 5, sabe que o que muda a experiência no dia a dia raramente é o número do gráfico.

A conta que importa: preço por token vs preço por tarefa

Preço por token é a métrica errada. O que sai da sua conta no fim do mês é preço por tarefa concluída, e é aí que o cache read de $0.25 muda o jogo.

Tabela oficial de preços, em dólar por milhão de tokens:

Repara no absurdo: a leitura de cache do Fable 5.1 é metade da do Opus 5, mesmo com o input custando o dobro. E é 25% mais cara que a do Sonnet 5, um modelo cinco vezes mais barato no input.

Isso importa porque agente é máquina de reler contexto. Simula um agente de coding realista: prefixo cacheado de 120k tokens (system prompt, definições de tool, arquivos do projeto), 200 turnos, 3k de input novo e 2k de output por turno.

O Fable 5.1 custa 1.3x o Opus 5 nessa sessão, não 2x. O cache read barato come mais da metade da diferença de preço, porque as leituras de cache dominam a contagem de tokens numa sessão longa. Quanto mais longo o loop, mais essa razão encolhe.

Agora inverta: numa chamada de turno único sem cache, você paga os 2x cheios e ganha 1.4 ponto de benchmark. Aí a conta não fecha de jeito nenhum.

E o Sonnet 5 continua sendo o melhor negócio da tabela pra 80% do que a maioria constrói: um terço do preço do Opus 5 na mesma simulação. (Se você quer ver essa conta aberta camada por camada num agente real, já detalhamos onde some o dinheiro de um agente em produção.)

Quando usar Fable 5.1, Opus 5 ou Sonnet 5

A recomendação oficial da Anthropic é surpreendentemente contida. Está na doc de escolha de modelo, em inglês seco:

"For most workloads, start with Claude Opus 5. Use Claude Fable 5.1 for demanding reasoning and long-horizon agentic work, or when your evals on Claude Opus 5 at higher effort still fall short."

Traduzindo o que isso quer dizer na prática: o Fable 5.1 não é o default. Ele é o degrau que você sobe depois que o Opus 5 no effort: xhigh ou max já falhou no seu eval. Se você não tem eval, você não tem como saber se precisa dele — e provavelmente não precisa.

Se isso soa familiar, é porque é o mesmo raciocínio que fizemos uma geração atrás em Fable 5 ou Opus 4.8: qual usar. Mudam os números, não o método.

Um detalhe que muita gente ignora: o parâmetro effort é uma alavanca melhor que a troca de modelo. Ele negocia inteligência por latência e custo dentro do mesmo modelo, sem invalidar cache e sem migrar código. Antes de subir de modelo, sobe o effort.

A árvore de decisão que eu uso:

1. A tarefa é de turno único ou volume alto? Classificação, extração, resumo, roteamento, sub-agente barato. → Haiku 4.5 ou Sonnet 5. Modelo topo de linha aqui é dinheiro queimado.

2. É trabalho de dev do dia a dia? Gerar código, análise de dados, tool use agentic de escopo fechado, conteúdo. → Sonnet 5. É o ponto de equilíbrio da linha, e $2/$10 com cache read de $0.20 é difícil de bater.

3. É agentic complexo, refactor grande, sistema inteiro, computer use, vision pesado? → Opus 5. Comece aqui, otimize prompt pra ele, meça.

4. O eval do Opus 5 em xhigh/max ainda não fecha? A sessão roda por horas sem supervisão? É pesquisa multistep profunda ou trabalho científico no terminal? → Fable 5.1. Aqui a diferença de 23 pontos no Terminal-Bench-Science paga o preço.

Uma última alavanca antes de subir de modelo: estratégia multi-modelo. Executor barato que escala decisão difícil pra um advisor caro, ou orquestrador que delega bulk pra worker. A maior parte dos tokens é faturada na tarifa baixa. Isso costuma render mais que trocar o modelo inteiro.

O que quebra se você trocar o model id hoje

Migrar do Fable 5 ou do Opus 5 pro Fable 5.1 não é só editar a string. Tem três breaking changes reais.

1. Tool use forçado retorna 400

Se seu código força uma tool, ele quebra. tool_choice com {"type": "any"} ou {"type": "tool", "name": "..."} devolve 400 invalid_request_error — inclusive no endpoint de contagem de tokens.

# QUEBRA no Fable 5.1
response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=8192,
    tools=[extrair_pedido],
    tool_choice={"type": "tool", "name": "extrair_pedido"},  # 400
    messages=[{"role": "user", "content": texto}],
)
# tool_choice: type "tool" and "any" are not supported for this model.

O motivo é interessante: thinking está sempre ligado nesses modelos, e uma tool call forçada pularia o raciocínio. O modelo acabaria escrevendo o raciocínio dentro dos argumentos da tool, o que piora a qualidade do argumento.

A correção é auto + instrução explícita + strict: true:

extrair_pedido = {
    "name": "extrair_pedido",
    "description": "Extrai os itens do pedido a partir do texto do cliente.",
    "strict": True,
    "input_schema": {
        "type": "object",
        "properties": {
            "itens": {"type": "array", "items": {"type": "string"}},
        },
        "required": ["itens"],
        "additionalProperties": False,
    },
}

response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=8192,
    tools=[extrair_pedido],
    tool_choice={"type": "auto"},
    messages=[{
        "role": "user",
        "content": f"Use a tool extrair_pedido para responder.\n\n{texto}",
    }],
)

Se a tool forçada existia só pra te devolver JSON, o caminho certo é structured outputs (output_config.format), não tool use.

2. Thinking blocks agora são presos ao modelo

Todo thinking block registra qual modelo o produziu, e a preservação é de mão única: o Fable 5.1 lê thinking de modelos anteriores, mas nenhum modelo anterior lê o dele. Se você tem um router que troca de modelo no meio da conversa, os blocos são descartados silenciosamente antes do modelo ver. Não são cobrados, mas o raciocínio some.

3. Editar turnos anteriores invalida o thinking

Esse é o que mais vai pegar gente desprevenida. Mexer em qualquer coisa antes de um thinking block do Fable 5.1 — o system, o array de tools, ou uma mensagem antiga — derruba a request seguinte com 400 The block is bound to a different conversation.

Padrões que invalidam tudo dali pra frente:

• editar, reordenar ou remover um turno antigo mantendo os posteriores;
• injetar um lembrete por request num turno antigo e remover na request seguinte;
• reconstruir o system ou o array de tools entre requests da mesma conversa;
• URL de imagem/documento que serve bytes diferentes numa request posterior.

A regra é tratar a conversa como append-only. Claude Code, claude.ai, Managed Agents e o Agent SDK já cuidam disso. Se o seu código monta o array de messages na mão, roda a verificação antes de migrar. A checagem é obrigatória para contas criadas a partir de 31 de agosto de 2026; contas mais antigas só sofrem se setarem thinking.block_binding.prefix_mismatch_behavior.

Pra lembrete de um turno só, o caminho novo é system message com escopo de turno em vez de injetar-e-deletar:

{
    "role": "system",
    "clear_at": "next_user_message",
    "content": "Os resultados chegaram na sua inbox. Verifique antes de rodar mais código.",
}

E dá pra mudar o effort no meio da conversa sem estourar o cache — sobe pro passo difícil, desce pro trivial:

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=8192,
    output_config={"effort": "high"},
    messages=[
        {"role": "user", "content": "Refatora o módulo de billing."},
        {"role": "assistant", "content": "..."},
        # daqui pra frente, effort baixo
        {"role": "system", "content": [], "output_config": {"effort": "low"}},
        {"role": "user", "content": "Agora só resume o que mudou."},
    ],
    betas=["mid-conversation-output-config-2026-07-01"],
)

Limitações e pontos de atenção

O anúncio não fala disso, mas a documentação fala. São diferenças de comportamento que aparecem sem você mudar uma linha de código:

• Tool calls paralelas ficaram mais variáveis. Onde o Fable 5 disparava várias leituras independentes de uma vez, o 5.1 às vezes faz uma por turno. A qualidade não cai, mas você paga mais turnos, mais round trips e mais tempo de parede. A correção é uma linha no prompt pedindo pra agrupar tool calls independentes.
• Menos progress update durante tool run longo. Ele escreve menos texto entre tool calls, ainda mais em effort alto. E como o thinking.display padrão é "omitted", um turno agentic longo parece travado pro usuário. Se sua UI depende de narração, use display: "updates" (beta thinking-display-updates-2026-08-18) e peça explicitamente por linha de abertura, updates e recap.
• Em effort: low, ele responde de memória. Chama menos ferramenta de busca. Se o turno precisa de informação fresca, sobe o effort ou adiciona instrução de verificação. Num agente com RAG, isso é o tipo de bug que passa no teste e falha em produção.
• Reescreve arquivo inteiro pra mudança pequena. Editando texto, ele tende a reescrever o arquivo todo em vez de fazer edição pontual. Resultado costuma ser o mesmo, custo de output não.
• Prosa mais densa e menos formatação em chat. Frases mais longas, menos quebra de parágrafo, menos negrito e lista. Regra anti-formatação escrita pra modelo antigo agora suprime estrutura que o conteúdo precisa.
• Citações não marcadas em resumo. Resumindo documento, ele reproduz trechos da fonte sem marcar como citação com mais frequência. Se você publica esse output, isso é risco.
• Watermark e provenance. Todo texto gerado pelo Fable 5.1 carrega o watermark estatístico da Anthropic, e imagem/vídeo produzidos via code execution vêm com Content Credentials C2PA. Não muda qualidade nem adiciona token, mas existe.

FAQ rápido

Por que minha request voltou com 400 invalid_request_error só por trocar o model id? Três suspeitos, nessa ordem: tool_choice forçado (any/tool), thinking com budget_tokens ou {"type": "disabled"}, e prefill da última mensagem assistant. Os três são removidos no Fable 5.1. Também cai aqui temperature/top_p/top_k em valor não-padrão.

Vale migrar do Opus 5 pro Fable 5.1 agora? Só se você tem eval e ele está falhando no Opus 5 em xhigh ou max. A própria Anthropic recomenda começar pelo Opus 5. Sem eval, você vai trocar 3 pontos de benchmark por 30% a 100% de aumento de custo sem saber medir o retorno.

O cache read mais barato compensa o input 2x mais caro? Depende do formato da carga. Em sessão agentic longa que relê um prefixo grande, compensa boa parte — no exemplo deste post a razão de custo caiu de 2x pra 1.3x. Em chamada de turno único sem cache, não compensa nada.

Consigo usar Fable 5.1 com contrato de zero data retention? Não, salvo autorização expressa da Anthropic. Ele exige retenção de 30 dias e é Covered Model. Request de org com ZDR retorna 400. Nesse cenário, Opus 5 é o teto prático.

Conclusão

O Claude Fable 5.1 é o melhor modelo disponível hoje pra quem paga por ele, e o número do Terminal-Bench-Science mostra que a distância pro Opus 5 é real onde ela importa: tarefa longa, autônoma, sem alguém olhando.

Mas a decisão de modelo deixou de ser sobre quem ganha no gráfico. É sobre formato de carga. Prefixo grande relido muitas vezes muda a conta inteira, e o cache read a $0.25 é a novidade de verdade dessa release — mais que qualquer ponto percentual de benchmark.

O próximo movimento previsível é esse multiplicador de cache descer no resto da linha. Quando descer, a conversa sobre custo de agente muda outra vez, e quem tiver eval montado vai descobrir isso em uma tarde. Quem não tiver vai descobrir na fatura.

Monta o eval primeiro. Depois escolhe o modelo.