Fable 5: cinco ajustes de prompt — e o primeiro é apagar uma linha

O ajuste mais valioso que você pode fazer hoje num prompt de Fable 5 é apagar uma linha. A doc de migração da Anthropic não faz rodeio: instrução que manda o modelo repetir, transcrever ou explicar o raciocínio interno dentro da resposta pode disparar a categoria de recusa reasoning_extraction, que devolve stop_reason: "refusal" e — nas palavras deles — provoca uma alta de fallbacks pro Claude Opus 4.8. Ou seja: aquele "me explique seu raciocínio passo a passo", que era de graça em toda biblioteca de prompt desde 2022, no Fable 5 pode te tirar justamente o modelo que você está pagando a US$ 10 / US$ 50 por milhão de tokens. E você não percebe, a não ser que esteja logando o stop_reason.

Essa inversão é o fio condutor da doc inteira. A Anthropic afirma sem meio-termo que skills escritas pra modelos anteriores são prescritivas demais pro Fable 5 e podem piorar a qualidade da saída. O trabalho mudou de lugar: menos frase esperta, mais auditoria do que você já manda. Cinco ajustes abaixo — o que escrever, por que funciona segundo a doc, e onde cada um sai pela culatra.

1. Apague as instruções de "mostre seu raciocínio"

Procure nos seus system prompts e arquivos de skill por "explique seu raciocínio", "mostre como pensou", "reflita sobre", "narre sua análise". Apague. Além do risco de recusa, elas não fazem o que você imagina: no Fable 5 o raciocínio bruto nunca é devolvido. Quem decide o que chega é a configuração thinking.display — "summarized" entrega um resumo legível do raciocínio, e "omitted", que é o padrão, entrega blocos de thinking com o campo vazio.

Sai pela culatra quando: você realmente precisa ver o raciocínio pra ter rastro de auditoria. Nesse caso não peça em prosa — coloque thinking.display em "summarized" e leia os blocos estruturados.

2. Use o effort em vez de escrever "pense com mais cuidado"

O effort é o controle principal de inteligência, latência e custo no Fable 5 — e ele mora na requisição, não no prompt:

{
  "model": "claude-fable-5",
  "max_tokens": 64000,
  "output_config": { "effort": "xhigh" }
}

São cinco níveis: low, medium, high, xhigh e max. O padrão da API é high, e a doc registra que passar "high" produz exatamente o mesmo comportamento que omitir o parâmetro — então muita gente que jura estar "ajustando o effort" está entregando o padrão com passos extras. Comece em high, suba pra xhigh no trabalho mais sensível a capacidade, desça pra medium ou low na tarefa rotineira. A parte tranquilizadora: nível baixo de effort no Fable 5 ainda vai bem e, segundo a Anthropic, muitas vezes supera o que o xhigh entregava nos modelos anteriores.

Sai pela culatra quando: você varia o nível dentro da mesma conversa. O effort muda o prompt renderizado, então trocar de valor entre requisições joga fora o prompt caching que você tinha — escolha o nível no começo de uma sessão longa e mantenha. Mais duas armadilhas. Em high e xhigh você precisa de um max_tokens folgado, porque esse teto cobre o raciocínio mais o texto de resposta (a Anthropic sugere começar na casa dos 64k, contra um máximo de 128k de saída por requisição). E thinking: {"type": "disabled"} simplesmente não é aceito aqui — o raciocínio adaptativo está sempre ligado, então o effort é a única alavanca de profundidade que você tem.

3. Delimite o escopo por escrito quando rodar em effort alto

Effort alto é onde o Fable 5 sai arrumando o que ninguém pediu. A própria doc traz o contrapeso:

Não adicione funcionalidades, não refatore e não crie abstrações além do que a
tarefa exige. Correção de bug não precisa de limpeza ao redor, e uma operação de
uma vez só normalmente não precisa de função auxiliar. Faça a coisa mais simples
que funcione bem. Não adicione tratamento de erro, fallback ou validação para
cenários que não podem acontecer. Valide apenas nas fronteiras do sistema
(entrada do usuário, APIs externas).

Sai pela culatra quando: você usa isso como desculpa pra cair pro medium. Effort alto é também onde a autoverificação fica mais rigorosa. Mantenha o nível e adicione a trava — a combinação recomendada pela Anthropic é uma checagem por intervalo ("estabeleça um método para checar seu próprio trabalho a cada [X] enquanto constrói"), conferida por subagents de contexto limpo, que segundo eles funcionam melhor que autocrítica.

4. Amarre toda afirmação de progresso a um resultado de ferramenta

Essa é a primeira que eu instalaria em qualquer coisa rodando sem ninguém olhando:

Antes de relatar progresso, confira cada afirmação contra um resultado de
ferramenta desta sessão. Só relate trabalho para o qual você consegue apontar
evidência; se algo ainda não foi verificado, diga isso de forma explícita. Se um
teste falhou, diga com a saída na mão; se um passo foi pulado, diga que foi; e
quando algo está pronto e verificado, afirme sem enrolação.

O que a Anthropic diz aqui é incomumente específico: nos testes deles isso quase eliminou os relatórios de progresso inventados, inclusive em tarefas montadas de propósito pra provocar esse erro. Seis linhas contra relatório de status confiante e errado é a melhor troca da doc inteira.

5. Conserte o harness, não o prompt — esconda o contador de tokens

O item mais surpreendente nem é de prompt. Bem no fundo de sessões muito longas, o Fable 5 às vezes começa a propor uma sessão nova, a oferecer um resumo pra passar o bastão ou a cortar o próprio trabalho. A doc aponta o gatilho: harness que mostra ao modelo um contador de tokens restantes. Então pare de exibir esse número. Se a sua interface for obrigada a mostrar, adicione a garantia:

Você tem contexto de sobra. Não pare, não resuma e não sugira uma nova sessão
por causa de limite de contexto. Continue o trabalho.

Sai pela culatra quando: o orçamento está apertado de verdade. O Fable 5 vem com context window de 1M tokens por padrão, então normalmente há espaço — mas se de fato não houver, o conserto honesto é compaction, não mandar o modelo seguir em frente.

A única ferramenta que vale adicionar

Pra rodadas longas e assíncronas, defina uma ferramenta send_to_user: um único campo message que a sua interface renderiza direto, devolvendo só um "ok" como resultado da ferramenta. Ela existe porque entrada de ferramenta nunca é resumida — então o material chega ao leitor idêntico, sem encerrar o turno. A metade não óbvia, direto da doc: definir a ferramenta não basta. Sem uma linha explícita no system prompt pedindo o uso, o Fable 5 quase nunca chama.

O ângulo de gestão

Se o seu time roda Claude no CI ou dentro de um harness de agente, o stop_reason pertence aos seus logs e a um painel. Recusa subindo devagar não é queda do Claude — quase sempre é uma instrução velha num arquivo de skill que ninguém releu desde o modelo anterior. Conserto de cinco minutos, desde que você esteja medindo. E esse é o movimento mais barato de credibilidade pra um dev brasileiro num time internacional: ser a pessoa que achou o rebaixamento silencioso rende muito mais que ser a pessoa com o maior arquivo de prompt.

Hoje: abra o system prompt ou o arquivo de skill mais longo que você mantém, procure por "raciocínio", "passo a passo" e "explique", e apague toda instrução que pede pro modelo narrar o próprio pensamento. Depois defina o output_config.effort de forma explícita em um lugar do seu código, pra esse nível virar uma decisão em vez de um acidente.

Fontes

• Claude Docs — Prompting Claude Fable 5
• Claude Docs — Effort
• Claude Docs — Introducing Claude Fable 5 and Claude Mythos 5