📖 Prompting Claude Fable 5

Fable 5 e Mythos 5 lançaram em 9/jun/2026; export controls do governo dos EUA em 12/jun levaram a Anthropic a suspender o acesso pra todos; a volta global aconteceu em 1/jul/2026.

Entender o contexto evita achar que o modelo "sumiu" por ser perigoso demais — ajuda a calibrar expectativa realista.

Claude Fable 5; Claude Mythos 5; export controls; Project Glasswing.

Pesquisadores da Amazon reportaram um jeito de contornar os safeguards do Fable 5. Mas o teste da própria Anthropic mostrou que modelos bem menos capazes — Opus 4.8, GPT-5.5, Kimi K2.7, até Haiku 4.5 e Sonnet 4.6 — geravam a MESMA demonstração de exploit.

Contexto acima de drama — a suspensão foi precaução regulatória, não uma falha exclusiva do Fable 5.

Vulnerabilidade de software; teste comparativo entre modelos; precaução regulatória.

Fable 5 vem incluso em até 50% do limite de uso semanal até 7/jul/2026 pros planos Pro/Max/Team/parte do Enterprise; depois disso, via usage credits.

Saber o limite evita surpresa de custo ou de cota logo na primeira semana de uso.

Limite de uso semanal; usage credits; Claude Platform, Claude.ai, Claude Code, Claude Cowork.

Mesmas capacidades do Fable 5, mas sem os safety classifiers — uso restrito só via Project Glasswing, pra cibersegurança defensiva.

Evita confundir os dois modelos e seus públicos de uso muito diferentes.

Project Glasswing; safety classifiers; cibersegurança defensiva.

A volta global do Fable 5 é o momento certo pra aprender a prompar um modelo que se comporta diferente do Opus 4.8.

Quem aprende as técnicas certas desde o início evita meses de tentativa e erro.

Janela de adoção; curva de aprendizado; migração de hábitos de prompt.

Dan Shipper (Every) deu 91/100 no benchmark interno "Senior Engineer" ao Fable 5, ante 63 do Opus 4.8. Boris Cherny (Anthropic) chamou publicamente de "o melhor modelo que já usei para código, por uma margem larga".

Sinaliza o tamanho do salto de capacidade — mesmo sendo relato de terceiros, não fato oficial da Anthropic.

Benchmark "Senior Engineer"; relato de early adopter; "warp drive para coding".

Contexto de intenção — dizer PARA QUE serve o que você está pedindo, não só O QUE fazer.

É prática consolidada de prompt engineering (o vídeo já traz esse argumento) — ajuda o modelo a tomar as micro-decisões certas sozinho.

Intenção da tarefa; contexto de propósito; prática geral, não citação oficial verbatim do doc do Fable 5.

Pedir pro Claude reproduzir o raciocínio interno na resposta pode disparar a categoria de recusa reasoning_extraction, específica do Fable 5.

Skills e system prompts antigos que pedem "mostre seu raciocínio" passam a gerar recusas e fallback pro Opus 4.8.

stop_reason: "refusal"; reasoning_extraction; adaptive thinking.

A documentação oficial recomenda auditar skills antigas em busca de instruções de "echo/transcribe/explain" do raciocínio interno.

Migrar de Opus pro Fable 5 sem essa auditoria eleva recusas sem motivo aparente pra quem não sabe o gatilho.

Harness instructions; structured thinking blocks; auditoria de system prompt.

Se a aplicação precisa de visibilidade do raciocínio, o caminho certo é ler os blocos estruturados de "adaptive thinking" — não pedir isso em texto na resposta.

Resolve a necessidade de transparência sem acionar a recusa reasoning_extraction.

Adaptive thinking; blocos estruturados; visibilidade de raciocínio.

Exemplos de como amarrar o "porquê" num prompt técnico — ex.: "estou revisando pra produção" vs "é só um rascunho".

O mesmo pedido técnico gera comportamento bem diferente dependendo do porquê declarado.

Prompt de tarefa; sinalização de contexto; comportamento condicional.

Instruções antigas que pediam "explique seu passo a passo" eram normais no Opus e quebram no Fable 5.

Encontrar esse padrão evita fallback silencioso pro Opus 4.8 e custo extra sem explicação aparente.

Skills legadas; fallback silencioso; revisão de prompt.

Dizer explicitamente o que o modelo NÃO deve fazer, não só o que deve fazer.

Em esforço alto, o Fable 5 pode reunir contexto e deliberar além do que a tarefa pede — negative prompting contém isso.

Negative prompting; over-engineering; overplanning.

O texto oficial pede pra não adicionar features/refactors/abstrações além do escopo, não limpar código ao redor de um bug fix e não criar helper pra uma operação única.

É a citação oficial mais direta contra "tidying" (arrumação) não pedido.

Anti-tidying; abstração prematura; validação só nas fronteiras do sistema.

O mesmo prompt oficial cobre não desenhar pra requisitos hipotéticos futuros — fazer a coisa mais simples que funciona bem.

Fable 5 tende a ser mais completo por padrão; conter isso economiza tokens e revisão.

Simplicidade deliberada; feature flags; shims de compatibilidade retroativa.

Quando o usuário está descrevendo um problema ou pensando alto, o entregável é a avaliação — reportar e parar, não aplicar fix sem pedir.

Evita mudanças de estado do sistema (restart, delete, config) sem que a evidência realmente sustente a ação.

Deliverable = assessment; ação destrutiva/irreversível; confirmação antes de agir.

O bloco de negative prompting funciona bem colado no CLAUDE.md, no system prompt, ou no início da sessão.

Colar uma vez resolve a tendência de "arrumação" em todas as tarefas seguintes daquele projeto.

CLAUDE.md; system prompt; escopo por sessão/projeto.

Depois de colar o prompt, observar se tarefas de bug fix passam a vir sem refactor extra nas sessões seguintes.

Fecha o ciclo de "testei e confirmei", não só "acho que ajudou".

Verificação empírica; comparação antes/depois; escopo da mudança entregue.

O prompt oficial diz pra só pausar pro usuário quando a tarefa realmente exige — ação destrutiva/irreversível, mudança real de escopo, ou input que só ele pode dar.

Elimina o hábito de "perguntar demais" que trava o loop autônomo em tarefas que já tinham informação suficiente.

Anti-overplanning; ação irreversível; fim de turno.

Se bater um dos casos que exige o usuário, o certo é perguntar e encerrar o turno ali — nunca terminar "prometendo" fazer depois.

Elimina o "early stopping" de intenção sem ação — raro, mas relatado em sessões longas.

Fim de turno; promessa vs ação; early stopping raro.

Antes de reportar progresso, auditar cada afirmação contra um resultado de ferramenta da própria sessão; só reportar o que dá pra apontar evidência.

No teste da Anthropic, isso quase eliminou relatos de status fabricados, até em tarefas desenhadas pra induzir isso.

Evidência de tool result; relato fiel; ausência de hedging.

Se um teste falha, reportar com o output; se um passo foi pulado, dizer isso; quando algo está pronto e verificado, afirmar sem rodeio.

É o oposto do "relatório de status bonito" que o prompt tenta erradicar.

Falha reportada com output; passo pulado; afirmação sem hedging.

Em tarefas longas, um subagent verificador com contexto fresco confere o trabalho contra a especificação em intervalos definidos.

Verificadores fresh-context tendem a superar a auto-crítica do mesmo agente que fez o trabalho.

Verificador fresh-context; intervalo de checagem; especificação como referência.

Comparar relatórios de progresso antes e depois de colar os dois prompts (agir + provar) em tarefas de vários passos.

Fecha o ciclo prático — não basta colar o prompt, tem que confirmar a mudança real de comportamento.

Comparação antes/depois; tarefa multi-passo; confirmação de comportamento.

O Fable 5 segue instrução o bastante bem pra você guiar comportamento com uma frase curta, em vez de listar cada regra pelo nome.

Prompts e system prompts gigantes viram peso morto — o modelo já entende a intenção com bem menos texto.

Instruction-following; instrução breve; enumeração desnecessária.

A primeira frase da resposta deve responder "o que aconteceu" ou "o que você encontrou" — o TLDR que o usuário pediria; detalhe e raciocínio vêm depois.

É a citação oficial mais direta sobre como estruturar a resposta final pro leitor.

Outcome-first; TLDR; detalhe de suporte depois do resultado.

O prompt oficial distingue ser legível de ser conciso: cortar detalhe que não muda a próxima ação do leitor, não comprimir a escrita em fragmentos ou abreviação.

Economizar token virando telegrama piora a leitura; economizar por seleção de conteúdo não.

Legibilidade; seleção de conteúdo; fragmentação de texto.

Depois de trabalhar muito tempo sem o usuário observando, o resumo final deve ser uma re-fundamentação — abre pelo resultado e explica cada identificador (arquivo, commit, flag) como se fosse novo.

É o prompt oficial que evita o usuário se perder ao voltar de uma sessão longa e autônoma.

Re-grounding; taquigrafia entre tool calls; clareza acima de brevidade.

Pensar em voz alta de forma abreviada entre tool calls é normal — diferente do resumo final, que precisa ser completo pro leitor que não viu nada daquilo.

Evita achar que "ser telegráfico o tempo todo" é o comportamento correto em toda a interação.

Pensamento intermediário; resumo final; audiência do leitor.

Testar o mesmo pedido com e sem o prompt de "diga menos" e comparar se a resposta ficou mais direta sem virar fragmento incompreensível.

Fecha o ciclo — "diga menos" não é sinônimo de "diga menos claro".

Clareza acima de brevidade; comparação de resposta; calibração pessoal.

max, xhigh, high (default), medium e low — cada um com caso de uso oficial, de "raciocínio mais profundo" até "tarefas simples, ex. subagents".

Escolher o nível certo economiza tokens sem perder qualidade onde ela não é necessária.

output_config.effort; max/xhigh/high/medium/low; comportamento vs orçamento de token.

Citação oficial: em níveis de esforço mais baixos, o Claude ainda pensa em problemas suficientemente difíceis, só que pensa menos do que pensaria num nível mais alto pro mesmo problema.

Derruba o mito de que esforço baixo significa sempre respostas fracas.

Sinal comportamental; orçamento de token; problema suficientemente difícil.

A recomendação prática da doc: níveis baixos no Fable 5 ainda performam bem — não assuma que "esforço baixo = fraco" só porque era assim ao migrar de Opus.

Evita setar "high"/"max" em tudo por hábito antigo, gastando o dobro do preço à toa.

Migração de hábito; custo vs desempenho; subagents rodando em low.

Não é "roteamento" com nome de produto — é um HTTP 200 com stop_reason: "refusal" e uma categoria em stop_details.category.

Tratar como erro genérico (retry cego) é o jeito errado de lidar; tratar como resposta válida com metadado é o certo.

HTTP 200; stop_reason; stop_details.category.

cyber, bio, frontier_llm e reasoning_extraction — cada uma com o texto oficial do que dispara aquela categoria.

Saber a categoria orienta o ajuste certo no prompt — ex.: reasoning_extraction se resolve tirando o "mostre seu raciocínio".

cyber; bio; frontier_llm; reasoning_extraction.

Recusa antes de qualquer output não é cobrada; recusa no meio do stream cobra o input e o output já emitido. Fallback pro Opus 4.8 tem 3 formas: server-side, middleware do SDK (BetaRefusalFallbackMiddleware) ou retry manual com "fallback credit".

Decidir a estratégia de fallback evita interrupção de produto quando uma recusa acontece em produção.

Billing de recusa; BetaRefusalFallbackMiddleware; fallback credit.

O Fable 5 despacha subagents paralelos mais prontamente que modelos anteriores; o prompt oficial recomenda delegar subtarefas independentes e continuar trabalhando enquanto rodam.

Comunicação assíncrona entre orquestrador e subagent troca "esperar bloqueado" por paralelismo real.

Subagents paralelos; comunicação assíncrona; intervenção se um subagent desviar.

Subagents que mantêm contexto entre subtarefas economizam tempo e custo via cache reads.

Reaproveitar contexto entre subtarefas é mais barato do que recriar tudo do zero a cada chamada.

Subagent de vida longa; cache reads; custo por subtarefa.

O prompt oficial recomenda guardar 1 lição por arquivo, com resumo de 1 linha no topo, registrando correções e acertos confirmados — e por que importaram.

Memória desorganizada vira ruído; 1 lição por arquivo mantém tudo buscável e atualizável.

1 lição por arquivo; atualizar nota existente; apagar nota que der errado.

O prompt oficial de bootstrap pede pra refletir sobre sessões anteriores, usar subagents pra identificar temas e lições centrais, e guardar num destino específico, referenciado no futuro.

Começa o sistema de memória com sinal real em vez de nota vazia.

Bootstrap; subagents de identificação; referência futura ao destino de memória.

Dá ao agente uma tool cujo input é mostrado ao usuário exatamente como escrito, sem terminar o turno — útil pra deliverable parcial, update de progresso com números específicos, ou responder uma pergunta feita no meio do loop.

Em agentes longos/assíncronos, resolve o problema de "o usuário fica sem notícia até o fim".

Input exibido verbatim; sem fim de turno; update parcial de progresso.

Skills feitas pra modelos anteriores costumam ser prescritivas demais e degradam a qualidade do Fable 5; a recomendação é revisar e considerar remover instrução antiga se o desempenho padrão já é melhor.

Fecha o ciclo do curso — migrar não é só aprender técnica nova, é também tirar prompt velho do caminho.

Prescrição excessiva; desempenho padrão; revisão de skill.