O guia de prompts do Claude Fable 5.1 muda o que o dev precisa escrever

A documentação oficial de prompting do Claude Fable 5.1 traz uma frase tranquilizadora logo no começo: "seus prompts existentes do Claude Fable 5 devem funcionar bem no Claude Fable 5.1 sem alterações". Na prática, para quem constrói agentes e pipelines de código, essa frase esconde um detalhe importante: várias das instruções que o time colou no system prompt nos últimos meses agora estão empurrando o modelo na direção errada. O comportamento default mudou, e regras defensivas escritas contra os modelos antigos viraram sabotagem silenciosa.

Este texto recorta o que muda no código de quem opera esses agentes no dia a dia, não a lista inteira da doc. O foco é: o que você tira do prompt, o que você adiciona e onde o dinheiro (tokens) vaza se você não fizer nada.

O nível de esforço não é o mesmo de antes

O controle principal de custo/latência/inteligência é o parâmetro effort, com os níveis low, medium, high (padrão), xhigh e max. O ponto que a doc bate com força: os nomes dos níveis não representam a mesma quantidade de raciocínio entre modelos. Se você calibrou o esforço no Fable 5, precisa refazer a varredura no 5.1, porque o mapeamento mudou.

Dois números práticos da própria doc valem a releitura:

• Em medium, o Fable 5.1 entrega resultado "aproximadamente" equivalente ao Fable 5, só que mais barato. Ou seja: onde a qualidade se mantém nas suas avaliações, dá para descer de high para medium e cortar custo sem perder saída.
• Em low, a doc afirma que o 5.1 "costuma ser competitivo com os modelos Claude Opus e Claude Sonnet em custo por tarefa enquanto pontua mais alto". Isso é uma recomendação de arquitetura de custo: em vez de rodar um modelo menor num esforço maior, vale comparar com o 5.1 em low.

Como isso é afirmação da fabricante, a leitura honesta é tratá-la como hipótese a validar com suas próprias avaliações, não como benchmark fechado. Mas o roteiro é claro: rode a mesma suíte de avaliação em low, medium e high e deixe o número decidir.

As regras antigas que agora atrapalham

Aqui está a parte que mais rende retrabalho, e o padrão se repete em três frentes: o modelo antigo era "empolgado demais" em algo, os times escreveram regras para conter, e o 5.1 já corrige na direção oposta, então a regra antiga passa do ponto.

A orientação da doc é auditar o prompt e remover essas linhas antes de adicionar qualquer coisa nova. Só depois, se ainda faltar comportamento, você adiciona uma regra condicional ("use listas quando o conteúdo for multifacetado o suficiente para ajudar na clareza") em vez de uma proibição absoluta.

Para conter a prosa densa, a doc sugere descrever o antipadrão em vez de só pedir "escreva simples". A versão longa explica o conceito de "mannered prose" (trocar afirmação direta por metáfora), mas há uma versão curta que costuma funcionar: Please remove all mannered prose. O material enviado por quem indicou a pauta resume essa filosofia como "seja literal e simples: use palavras claras e evite metáforas", que é exatamente o eixo da recomendação oficial.

Onde os tokens vazam: batching e blocos de pensamento

Duas mudanças de plumbing merecem atenção de quem roda loop de agente.

A primeira: em loops de código e uso de computador, quando as próximas chamadas independentes estão implícitas na tarefa (e não explicitamente pedidas), o 5.1 pode emitir uma tool call por turno em vez de paralelizar. Cada turno extra é um round-trip, tokens e tempo de relógio jogados fora. O conserto é um lembrete de uma frase ao fim da requisição:

First privately list what you need next; then request every item that doesn't depend on another's result in this one response.

O detalhe fino é onde colocar esse lembrete a cada turno. A doc recomenda enviá-lo como mensagem de sistema com escopo de turno (role: "system" com clear_at: "next_user_message", beta sob o cabeçalho mid-conversation-system-clear-at-2026-08-21). Assim que existir uma nova mensagem do usuário, a API limpa as cópias antigas, e o modelo lê só a mais recente, sem custo das anteriores.

A segunda, e mais perigosa de ignorar: o histórico da conversa precisa ser somente-acréscimo. Para contas criadas a partir de 31 de agosto de 2026, os blocos thinking do Fable 5.1 são válidos apenas na conversa exata que os produziu. Se o prefixo (system prompt, lista de ferramentas ou qualquer mensagem anterior) muda entre requisições, reenviar um bloco de pensamento retorna HTTP 400, ou descarta os blocos se você setar thinking.block_binding.prefix_mismatch_behavior: "drop_block".

Espera-se que modelos futuros apliquem essa verificação a todas as contas, então adote o padrão agora mesmo que a sua não seja verificada hoje.

Documentação do Claude Fable 5.1

Na prática: injetar e remover lembretes por turno, resumir turnos antigos no lugar ou mudar o system prompt no meio da sessão são exatamente as edições que quebram isso, e são as mesmas que reiniciam o cache de prompt. A recomendação é acrescentar cada turno do assistente byte a byte como a API retornou, incluindo os blocos de pensamento, e nunca reescrever turnos anteriores. Se for compactar no cliente, o caminho mais limpo é substituir todo o histórico por um resumo mais o novo turno do usuário e não reenviar nenhum bloco de pensamento, aí nada falha porque nada de thinking é carregado.

Um efeito colateral de custo: como as leituras de cache ficaram mais baratas no 5.1, compactar cedo para economizar pode não valer mais a pena. A doc sugere experimentar pontos de compactação mais tardios.

Autonomia: mandar terminar a tarefa inteira

Em cargas assíncronas longas, o 5.1 às vezes descreve o que faria ("Em seguida, vou...") ou para para pedir permissão de algo que o pedido original já cobria ("Devo aplicar isso?"). Isso força o usuário a responder "continue", o que faz sentido em pair programming, mas desperdiça a capacidade de longo horizonte do modelo em trabalho autônomo. A doc entrega uma linha pronta para o system prompt que instrui o modelo a operar de forma autônoma, prosseguir com ações reversíveis derivadas do pedido original e parar só para ações destrutivas ou mudanças reais de escopo.

Uma ressalva importante para não exagerar na dose: isso é para trabalho autônomo, não supervisionado. Em pair programming e fluxos com humano no loop, o comportamento de pedir confirmação é desejável, e as instruções de "conclua a tarefa inteira" e as de atualização de progresso apontam para lados opostos. A escolha depende do modo do seu produto.

O que fazer hoje, e onde não vale mexer

O resumo prático para o dev brasileiro que já tem agentes no ar com Fable 5: abra o system prompt, delete as regras antiformatação e as de "guarde tudo para o final", refaça a varredura de effort com suas avaliações, ative os blocos thinking de progresso (display: "updates") se quiser que o usuário veja o que o agente está fazendo, e garanta que o harness só faz append no histórico.

Onde não vale a pena: se o seu uso é chat simples, síncrono, com prompts curtos e sem loop de ferramentas, a maioria dessas mudanças não muda nada. E migrar tudo de uma vez sem rodar avaliação antes é o erro clássico, várias dessas recomendações (esforço, densidade, formatação) só se justificam com número medido no seu caso, não com a promessa genérica da doc.

Fontes: platform.claude.com · Material enviado por quem indicou