❓ O problema: só o "quê", nunca o "porquê"
🧠 Imagine assim: um modelo de linguagem não lê mentes — ele prevê qual é o próximo token mais provável dado o texto que já viu. Se o seu prompt só diz o QUÊ ("escreva uma função que valida email"), o Fable 5 tem que ADIVINHAR pra quê serve, quem vai usar aquilo e o que "bom" significa aqui. Ele costuma adivinhar bem... até não adivinhar.
No fundo, um LLM é uma máquina de previsão do próximo token. Ele não tem acesso ao que está na sua cabeça — só ao texto do prompt. Um pedido que descreve apenas a tarefa ("faça X") deixa um buraco: por que X importa, pra quem, com que critério de qualidade. O modelo preenche esse buraco com a interpretação estatisticamente mais comum para aquele tipo de pedido, que pode ou não ser a sua.
O custo desse "chute" cresce com a autonomia do modelo. O Fable 5 foi construído pra manter instrução em runs de longo horizonte, às vezes de múltiplos dias. Se a intenção real não foi dada no início, ele não erra rápido e pergunta — ele executa, por horas, na direção plausível errada, e você só descobre o desvio quando já custou tempo e tokens.
💡 Conceito principal
Previsão de token ≠ leitura de mente. O "porquê" não é enfeite educado no prompt — é o dado que falta pro modelo escolher entre várias execuções igualmente válidas do mesmo "quê".
✗ Só o quê
"Escreva uma função que valida email."
O modelo não sabe se falso positivo ou falso negativo é o erro mais caro aqui — e vai escolher por conta própria.
✓ Quê + porquê
"Escreva uma função que valida email porque estamos filtrando cadastros de spam antes do CRM — falso negativo é pior que falso positivo aqui."
Agora o critério de "certo" está explícito. O modelo decide na sua direção, não na média estatística.
Em 1 frase: sem o porquê, o Fable 5 não lê sua mente — ele prevê o próximo token e adivinha o contexto que falta.
🧩 A fórmula do porquê, na prática
🧠 Imagine assim: em vez de só pedir a tarefa, você entrega o briefing completo — o que está em jogo, pra quem, e o que a resposta precisa habilitar. É a diferença entre gritar uma ordem e passar um briefing de verdade.
Esta é uma prática consolidada de prompt engineering em geral — não uma citação fechada da documentação oficial do Fable 5 (o vídeo-fonte já trazia o argumento, e a pesquisa não confirmou uma frase verbatim específica pra esta técnica). Trate como recomendação sólida, não como "regra oficial gravada em pedra". A fórmula tem quatro partes: tarefa maior (o projeto em que isso se encaixa), quem (quem depende do resultado), o que a saída habilita (a decisão ou ação que vem depois) e só então o pedido concreto.
Repare na ordem: o porquê vem antes do pedido, não como nota de rodapé depois. Isso importa porque o modelo pondera mais fortemente o contexto que está mais perto (em termos de atenção) do pedido final — um "porquê" jogado no fim do prompt compete com menos peso contra o pedido em si.
Modelo/fórmula copiável — EN e PT-BR
I'm working on <bigger task, e.g. "security review of the payments API"> for <who, e.g. "the compliance team">. They need <what the output enables, e.g. "a prioritized list of vulnerabilities with severity, to decide what to fix before release">. With that: <concrete ask, e.g. "review auth.py and payments.py and list the risks found">.
Estou trabalhando em <tarefa maior, ex.: "revisão de segurança da API de pagamentos"> para <quem, ex.: "o time de compliance">. Eles precisam de <o que a saída habilita, ex.: "uma lista priorizada de vulnerabilidades com severidade, pra decidir o que corrigir antes do release">. Com isso: <pedido concreto, ex.: "revise auth.py e payments.py e liste os riscos encontrados">.
Passo 1 — Tarefa maior
Em que projeto/objetivo isso se encaixa? Não é o comando isolado, é o contexto maior dele.
Passo 2 — Quem
Quem vai usar, ler ou depender do resultado? Um time de compliance quer algo diferente de um dev solo.
Passo 3 — O que a saída habilita
Que decisão ou ação vem depois da resposta? Isso define o formato e a prioridade certos.
Passo 4 — O pedido
Só agora o pedido concreto — depois que o modelo já sabe por que ele importa.
🔬 Exemplo copy-run: prompt de sistema antes/depois
Objetivo: mostrar, num prompt de sistema real de agente de revisão de PR, como o porquê muda o que o modelo prioriza — sem mudar o "quê" pedido.
🇬🇧 EN
❌ BEFORE (what only): "You are an agent that reviews Pull Requests. Point out bugs and style suggestions." ✅ AFTER (what + why): "You are an agent that reviews Pull Requests for a team that ships to production 3 times a day and has no dedicated QA. The goal of this review is to catch what would break production — not style. They need a short, prioritized list (bugs > security > logic), because long, nitpick-heavy reviews get ignored. With that: review the attached diff and list only what would block the merge."
🇧🇷 PT-BR
❌ ANTES (só o quê): "Você é um agente que revisa Pull Requests. Aponte bugs e sugestões de estilo." ✅ DEPOIS (quê + porquê): "Você é um agente que revisa Pull Requests para um time que faz deploy 3x ao dia e não tem QA dedicado. O objetivo desta revisão é pegar o que quebraria produção — não estilo. Eles precisam de uma lista curta e priorizada (bugs > segurança > lógica), porque revisões longas e cheias de nitpick são ignoradas. Com isso: revise o diff anexado e liste só o que bloquearia o merge."
Como verificar: rode as duas versões contra o mesmo diff e compare a saída. A versão "antes" tende a voltar com uma lista longa e genérica (inclui nitpick de estilo); a versão "depois" prioriza o que quebraria produção, na ordem certa. Se a saída "depois" ainda vier genérica, o porquê não ficou explícito o suficiente — reforce com números/critérios concretos.
Em 1 frase: tarefa maior + quem + o que a saída habilita + pedido — nessa ordem, o porquê vem antes do quê.
📏 Por que isso pesa ainda mais no Fable 5
🧠 Imagine assim: é a diferença entre pedir um desejo pra um gênio literal e pedir pra um amigo que "entende o espírito" do pedido. O Fable 5 é o gênio literal — extremamente bom nisso, o que corta os dois lados da faca.
Modelos mais fracos em instruction-following costumam "suavizar" pedidos ambíguos com o senso comum aprendido no treino — às vezes acidentalmente acertam a sua intenção mesmo sem ela estar explícita. O Fable 5 segue exatamente o que foi pedido. A doc oficial descreve o ganho como: "Instruction-following is improved enough that you can steer most behaviors with a brief instruction rather than enumerating each behavior by name." (fonte: doc oficial "Prompting Claude Fable 5" — técnica 6, "diga menos, não mais", aprofundada no módulo 1.5; tradução: "o instruction-following melhorou o suficiente pra você guiar a maioria dos comportamentos com uma instrução breve, em vez de listar cada comportamento pelo nome.")
Essa força vira risco exatamente quando falta o porquê: sem ele, o Fable 5 não vai "adivinhar bem" por acidente como um modelo mais fraco às vezes faz — ele cumpre o pedido literal ao pé da letra, mesmo que isso perca o objetivo real por trás dele. Quanto mais forte o instruction-follower, mais caro fica um pedido mal-especificado.
→ Instruction-follower fraco
- • Preenche lacunas com senso comum do treino
- • Às vezes "acerta por acidente" sem o porquê
- • Desvia do pedido literal com mais frequência
✓ Instruction-follower forte (Fable 5)
- • Executa exatamente o que foi pedido
- • Sem o porquê, cumpre o pedido literal — mesmo errado
- • Com o porquê, acerta de primeira com muito mais consistência
Em 1 frase: quanto mais literal o instruction-follower, mais caro fica pedir sem o porquê.
⚠️ O gatilho oculto: pedir pra "mostrar o raciocínio"
🧠 Imagine assim: parece inofensivo pedir "explica seu raciocínio" — é o tipo de frase que qualquer skill antiga de "seja transparente" tem. No Fable 5 ela pode acionar uma recusa de segurança e trocar de modelo sem avisar.
Há uma ironia direta com o resto deste módulo: pedir pro modelo explicar por que fez algo dentro do próprio texto de resposta é a forma errada de conseguir transparência. Prompts, skills e instruções de harness que pedem pro modelo ecoar, transcrever ou narrar o raciocínio interno como parte da resposta caem numa categoria de segurança específica — e isso é específico do Fable 5, não um comportamento genérico de qualquer Claude.
Isso costuma vir de skills migradas de modelos antigos, onde "mostre seu raciocínio passo a passo" era uma técnica válida de prompting. No Fable 5, o canal certo pra isso já existe — os thinking blocks — e pedir pra duplicar isso na resposta em texto é o próprio gatilho de risco (ver tópico 5 e 6).
⚠️ Atenção: frases que parecem inofensivas
Se uma skill, system prompt ou harness instrui o modelo a "explicar", "transcrever" ou "ecoar" o próprio raciocínio dentro da resposta visível ao usuário, ela é candidata a disparar a recusa de segurança do próximo tópico — mesmo que a intenção seja só "seja transparente".
✗ Dispara o gatilho
- • "Explique seu raciocínio na resposta."
- • "Mostre como você pensou, passo a passo."
- • "Pense em voz alta e escreva tudo antes da resposta final."
✓ Seguro
- • "Responda direto com o resultado."
- • "Se precisar registrar decisões, use um changelog de ações — não uma narração do raciocínio."
- • Precisa de visibilidade real? → tópico 6: leia os thinking blocks.
Em 1 frase: pedir pro Fable 5 reproduzir o raciocínio na resposta em texto é um gatilho de segurança, não um pedido neutro.
🚦 reasoning_extraction: o fallback silencioso pro Opus 4.8
🧠 Imagine assim: não é um erro que aparece com alarme vermelho — é um stop_reason: "refusal" dentro de uma resposta HTTP 200 normal. Se você não sabe procurar por ele, seu app continua rodando, só que silenciosamente num modelo mais barato.
A documentação oficial de refusals-and-fallback define quatro categorias possíveis em stop_details.category: cyber, bio, frontier_llm e a que interessa aqui, reasoning_extraction. É exatamente o gatilho do tópico anterior.
📊 Dado oficial — definição da categoria
🇬🇧 EN (oficial, doc "refusals-and-fallback"): "The request asks the model to reproduce its internal reasoning in the response text. To get reasoning in a structured form instead, use adaptive thinking."
🇧🇷 PT-BR (tradução): "O pedido pede pro modelo reproduzir o raciocínio interno dele no texto da resposta. Pra obter o raciocínio numa forma estruturada, use o adaptive thinking."
Quando isso dispara, a recusa acontece antes de qualquer output e não é cobrada. Existem três formas de configurar um fallback automático pro Claude Opus 4.8 quando isso acontece: fallback server-side (Claude API / Claude Platform on AWS, via header beta), middleware do SDK (BetaRefusalFallbackMiddleware) ou retry manual com "fallback credit". Nos três casos, se você não audita suas skills/prompts, o fallback vira um vazamento silencioso de qualidade e custo — o app "funciona", só que num modelo diferente do que você pensa estar usando.
🔬 Exemplo copy-run: auditando skills existentes
Objetivo: ter um checklist oficial da Anthropic pra auditar prompts/skills antigas em busca de instruções que pedem pro modelo "mostrar o raciocínio" no texto — o exato gatilho do tópico 4. Este é o texto oficial do briefing, usado como exemplo do que NÃO fazer / do que auditar em skills já existentes (não é um prompt pra "rodar direto" na tarefa — é a política que você cola no topo de um CLAUDE.md, ou entrega a um agente como instrução de auditoria do próprio repositório de skills).
🇬🇧 EN (oficial — doc "Prompting Claude Fable 5")
Don't instruct Claude to reproduce its reasoning in the response. Prompts, skills, or harness instructions that tell the model to echo, transcribe, or explain its internal reasoning as response text can trigger the reasoning_extraction refusal category on Claude Fable 5, causing elevated fallbacks to Claude Opus 4.8. Audit existing skills and system prompts for reflection or show-your-thinking instructions when migrating. If your application needs reasoning visibility, read the structured thinking blocks from adaptive thinking instead.
🇧🇷 PT-BR (tradução)
Não instrua o Claude a reproduzir o raciocínio dele na resposta. Prompts, skills ou instruções de harness que pedem pro modelo ecoar, transcrever ou explicar o raciocínio interno como texto de resposta podem disparar a categoria de recusa reasoning_extraction no Claude Fable 5, causando fallbacks mais frequentes pro Claude Opus 4.8. Ao migrar, audite skills e system prompts existentes em busca de instruções de reflexão ou "mostre seu raciocínio". Se sua aplicação precisa de visibilidade do raciocínio, leia os blocos estruturados de thinking do adaptive thinking em vez disso.
Como verificar: faça um grep no seu repositório de skills/system prompts por frases como "explain your reasoning", "show your thinking", "reproduce your reasoning" (e os equivalentes em português do tópico 4). Se achar, é candidato a reasoning_extraction — troque pela leitura de thinking blocks (tópico 6) e monitore a taxa de fallback pro Opus 4.8 antes e depois da correção.
Em 1 frase: reasoning_extraction é um stop_reason: refusal em HTTP 200 — audite suas skills antes que ele vire um fallback silencioso pro Opus 4.8.
🔍 A alternativa: leia os thinking blocks, não peça pra "contar"
🧠 Imagine assim: em vez de pedir pro ator narrar os bastidores no meio da cena, você lê o roteiro de bastidores separadamente. O adaptive thinking já separa os dois canais — o trabalho é ler o canal certo, não forçar os dois em um só.
Se a sua aplicação precisa de visibilidade real do raciocínio — pra debug, auditoria ou log — a resposta certa não é pedir pro modelo reescrever o raciocínio dentro do texto que o usuário vê. É ler os thinking blocks estruturados que o adaptive thinking já produz, num canal separado da resposta final. Isso preserva as duas coisas ao mesmo tempo: o modelo pensa o quanto precisa, e você tem visibilidade — sem tocar no gatilho do tópico 5.
Na prática, isso é uma mudança de onde a instrução aponta: em vez de "explique seu raciocínio na resposta", a instrução (ou o código do seu harness) passa a ser "leia o raciocínio no bloco de thinking". Ver a documentação oficial de adaptive thinking pra configuração exata da API.
Estrutura ilustrativa da resposta (não é citação literal da doc — só ilustra onde cada canal mora)
{
"content": [
{ "type": "thinking", "thinking": "...raciocínio interno estruturado..." },
{ "type": "text", "text": "...resposta final que o usuário vê..." }
]
}
Como verificar: se sua aplicação precisa auditar decisões, leia os blocos com type === "thinking" no seu código, em vez de instruir "explique seu raciocínio" no prompt. Confirme que o type === "text" final continua limpo, direto e sem narrar os bastidores — e que a taxa de fallback pro Opus 4.8 (tópico 5) não sobe.
✗ Pedir pra reproduzir no texto
"Explique seu raciocínio antes de responder." → risco de reasoning_extraction + fallback silencioso.
✓ Ler os thinking blocks
Habilite adaptive thinking e leia type: "thinking" no seu código. Sem gatilho, com visibilidade real.
Em 1 frase: visibilidade do raciocínio mora nos thinking blocks, não no texto da resposta.
📚 Fontes deste módulo
- • Prompting Claude Fable 5 (doc oficial — técnicas e code boxes)
- • Refusals and fallback (doc oficial — categoria reasoning_extraction)
- • Adaptive thinking (doc oficial — thinking blocks)
🧾 Resumo do Modulo
Proximo modulo:
1.3 — Negative prompting + fronteiras: o que NÃO fazer e quando parar pra perguntar.