DEV Community

Cover image for Como Maximizar o Uso do seu Claude Fable 5 com o Prompt Perfeito
Lucas
Lucas

Posted on • Originally published at apidog.com

Como Maximizar o Uso do seu Claude Fable 5 com o Prompt Perfeito

Claude Fable 5 é mais capaz do que os modelos anteriores, mas essa capacidade precisa ser controlada no prompt. Se você enviar uma tarefa simples com esforço alto e instruções vagas, o modelo pode coletar contexto demais, deliberar além do necessário e alterar código fora do escopo. Com um prompt mais explícito, você reduz tokens, latência e ruído sem perder qualidade nas tarefas que realmente exigem raciocínio.

Experimente o Apidog hoje

Este guia transforma as orientações oficiais de prompting do Fable 5 da Anthropic em um fluxo prático: escolher esforço, limitar escopo, reduzir verbosidade e validar o impacto com o Apidog. A ideia não é “burlar limites”, mas obter mais trabalho útil por chamada.

O que “estender seu uso” realmente significa

Na prática, três variáveis definem custo e resultado em uma chamada ao Fable 5:

  • Esforço: principal alavanca de custo, latência e capacidade. Use high como padrão, xhigh apenas para tarefas difíceis, e medium ou low para trabalho rotineiro.
  • Tokens de saída: sem instruções claras, o modelo tende a explicar demais, listar alternativas que não seguirá e narrar passos óbvios.
  • Duração da execução: tarefas difíceis podem levar minutos ou mais. O prompt deve impedir gasto excessivo em tarefas simples e permitir execução mais longa onde isso faz sentido.

Imagem explicativa sobre uso do Claude Fable 5

O objetivo é simples: mais trabalho concluído por token. Para isso, trate o prompt como parte da implementação, não como texto auxiliar.

Padrões de prompt para otimizar cada chamada

Use os blocos abaixo como instruções de sistema reutilizáveis. Eles são curtos, fáceis de testar e ajudam a controlar comportamento sem criar prompts longos demais.

1. Combine o esforço com a tarefa

Não use sempre o mesmo nível de esforço. Defina uma regra operacional:

Tipo de tarefa Esforço sugerido
Resumo, formatação, pequenas correções low ou medium
Implementação comum, análise moderada high
Debug difícil, arquitetura, tarefas ambíguas xhigh

Exemplo de política:

Use the lowest effort level that completes the task correctly. Prefer medium for routine
work, high for implementation tasks, and xhigh only for difficult reasoning or ambiguous
debugging.
Enter fullscreen mode Exit fullscreen mode

Se uma tarefa retorna a resposta correta, mas demora demais, reduza o esforço antes de mudar todo o prompt.

Se você monitora custo em produção, veja também a análise de custo da API Claude e limites de taxa da API Claude.

2. Diga para agir quando houver informação suficiente

Modelos mais capazes podem planejar demais. Para tarefas de implementação, deixe claro quando parar de explorar e começar a executar:

When you have enough information to act, act. Do not re-derive facts already established
in the conversation, re-litigate a decision the user has already made, or narrate
options you will not pursue. If you are weighing a choice, give a recommendation, not an
exhaustive survey. This does not apply to thinking blocks.
Enter fullscreen mode Exit fullscreen mode

Use isso quando perceber respostas com muito contexto repetido ou análise que não altera a solução.

3. Comece pelo resultado

Para reduzir tokens de saída, peça a resposta direta primeiro:

Lead with the outcome. Your first sentence after finishing should answer "what happened"
or "what did you find": the thing the user would ask for if they said "just give me the
TLDR." Supporting detail and reasoning come after. Being readable and being concise are
different things, and readability matters more.
Enter fullscreen mode Exit fullscreen mode

Isso funciona bem para:

  • revisão de código;
  • diagnóstico de bugs;
  • respostas de API;
  • comparação entre variantes de implementação.

Exemplo de saída esperada:

O bug está no tratamento de timeout do cliente HTTP. A requisição expira antes de o Fable 5 terminar a resposta em tarefas de alto esforço.

Detalhes:
- ...
Enter fullscreen mode Exit fullscreen mode

4. Restrinja o escopo da alteração

Para tarefas de código, limite explicitamente o que pode ser alterado:

Don't add features, refactor, or introduce abstractions beyond what the task requires. A
bug fix doesn't need surrounding cleanup. Don't add error handling, fallbacks, or
validation for scenarios that cannot happen. Only validate at system boundaries (user
input, external APIs). Do the simplest thing that works well.
Enter fullscreen mode Exit fullscreen mode

Esse bloco é útil quando o modelo começa a “melhorar” código não relacionado ao pedido.

5. Baseie status em evidências durante execuções longas

Em tarefas autônomas ou com ferramentas, evite progresso inventado:

Before reporting progress, audit each claim against a tool result from this session.
Only report work you can point to evidence for; if something is not yet verified, say so
explicitly.
Enter fullscreen mode Exit fullscreen mode

Use essa instrução em fluxos com:

  • testes automatizados;
  • chamadas de API;
  • leitura de arquivos;
  • execução de comandos;
  • pipelines de CI.

6. Explique o motivo da tarefa

O Fable 5 tende a responder melhor quando entende o objetivo maior. Use um formato simples:

I'm working on [the larger task] for [who it's for]. They need [what the output
enables]. With that in mind: [request].
Enter fullscreen mode Exit fullscreen mode

Exemplo:

Estou criando testes de contrato para uma API interna usada pelo time de pagamentos.
Eles precisam detectar mudanças incompatíveis antes do deploy. Com isso em mente:
gere casos de teste para os endpoints abaixo, priorizando campos obrigatórios,
códigos de erro e compatibilidade de schema.
Enter fullscreen mode Exit fullscreen mode

7. Crie um arquivo de memória para fluxos repetitivos

Para tarefas recorrentes, mantenha um arquivo Markdown com aprendizados. Estrutura sugerida:

# Memória do projeto

Resumo:
- A API usa autenticação via header x-api-key.
- Timeouts acima de 60s devem usar streaming.
- Não alterar contratos sem atualizar testes.

## Lições

### 2026-06-10 — Timeout em chamadas longas
Em tarefas com esforço alto, o cliente HTTP precisa aceitar respostas lentas ou streaming.

### 2026-06-11 — Validação de entrada
Validar apenas nas bordas: input do usuário e APIs externas.
Enter fullscreen mode Exit fullscreen mode

Regra prática: atualize entradas existentes em vez de duplicar aprendizados.

Teste e ajuste seus prompts no Apidog

A parte crítica é medir. Um prompt que parece mais curto pode gerar a mesma quantidade de tokens. Uma instrução agressiva de concisão pode reduzir qualidade ou aumentar recusas.

O Apidog ajuda nesse fluxo porque permite salvar requisições, parametrizar variáveis, comparar respostas, validar campos e simular endpoints. É o mesmo princípio de teste de API sem Postman, aplicado ao endpoint de Mensagens.

Interface do Apidog para testes de API

1. Parametrize prompt, tarefa e chave da API

Crie uma requisição para a API de Mensagens e mova os valores variáveis para o ambiente do Apidog:

  • ANTHROPIC_API_KEY
  • SYSTEM_PROMPT
  • TASK
  • MODEL
  • MAX_TOKENS

Exemplo:

POST https://api.anthropic.com/v1/messages
x-api-key: {{ANTHROPIC_API_KEY}}
anthropic-version: 2023-06-01
content-type: application/json

{
  "model": "{{MODEL}}",
  "max_tokens": {{MAX_TOKENS}},
  "system": "{{SYSTEM_PROMPT}}",
  "messages": [
    {
      "role": "user",
      "content": "{{TASK}}"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Com isso, você troca o prompt ou a tarefa sem editar o corpo da requisição.

2. Faça um teste A/B com duas variantes

Crie duas versões da mesma requisição:

  • Variante A: prompt base.
  • Variante B: prompt com instruções de concisão, escopo e ação.

Execute as duas contra a mesma tarefa e compare:

  • usage.output_tokens
  • tempo de resposta
  • stop_reason
  • qualidade da resposta
  • aderência ao escopo

Exemplo de checklist:

[ ] A resposta resolveu a tarefa?
[ ] Alterou apenas o que foi pedido?
[ ] Reduziu output_tokens?
[ ] Reduziu latência?
[ ] Manteve stop_reason como end_turn?
Enter fullscreen mode Exit fullscreen mode

Mantenha a variante que entrega o mesmo resultado com menos custo e menor latência.

3. Valide stop_reason

O Fable 5 pode retornar:

{
  "stop_reason": "refusal"
}
Enter fullscreen mode Exit fullscreen mode

Isso pode indicar recusa acionada por classificadores de segurança ou por um prompt mal formulado. No Apidog, adicione uma asserção para validar que o fluxo esperado termina com:

{
  "stop_reason": "end_turn"
}
Enter fullscreen mode Exit fullscreen mode

Exemplo de regra:

$.stop_reason == "end_turn"
Enter fullscreen mode Exit fullscreen mode

Assim, recusas viram falhas visíveis no teste em vez de comportamento silencioso em produção. Trate essa validação como parte do contrato do seu prompt.

4. Planeje timeouts para execuções longas

O Fable 5 pode levar mais tempo em tarefas difíceis. Antes de usar em produção:

  1. Defina um timeout realista no cliente.
  2. Teste respostas lentas.
  3. Considere streaming quando aplicável.
  4. Reduza esforço se a tarefa for correta, mas lenta demais.

Se os timeouts começarem a aparecer no gateway ou upstream, o guia para corrigir tempos limite de requisição upstream se aplica diretamente.

5. Simule a API para iterar sem gastar tokens

Durante o ajuste, você pode executar dezenas de testes. Para não gastar tokens em cada iteração:

  1. Salve uma resposta real como exemplo.
  2. Configure o mock server do Apidog.
  3. Retorne respostas simuladas para sucesso, recusa e erro.
  4. Teste o cliente, asserções e lógica de timeout contra o mock.
  5. Volte para a API real apenas nas medições finais.

Exemplo de resposta simulada:

{
  "id": "msg_mock_001",
  "type": "message",
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "O prompt B reduziu a saída e manteve o mesmo resultado."
    }
  ],
  "model": "claude-fable-5",
  "stop_reason": "end_turn",
  "usage": {
    "input_tokens": 420,
    "output_tokens": 180
  }
}
Enter fullscreen mode Exit fullscreen mode

Se você quiser automatizar isso em CI, veja o guia de CLI do Apidog e habilidades Claude.

Perguntas frequentes

Um prompt melhor significa menos tokens no Fable 5?

Muitas vezes, sim. Instruções como “comece pelo resultado” e “não narre opções que não seguirá” reduzem preâmbulo e explicações desnecessárias. Mesmo assim, meça usage.output_tokens; nem toda reformulação reduz custo.

Qual é a maneira mais rápida de reduzir custo?

Diminuir o esforço em tarefas rotineiras. Use medium ou low quando a tarefa for simples e reserve high ou xhigh para trabalho realmente difícil.

Por que minha requisição está dando timeout?

O Fable 5 pode executar por mais tempo em tarefas complexas. Aumente o timeout, use streaming quando possível ou reduza o esforço se a resposta estiver correta, mas lenta demais.

Por que recebi stop_reason: "refusal"?

Pode ser efeito de classificadores de segurança ou de um prompt que pede algo problemático, como reproduzir raciocínio interno. Valide stop_reason nos testes para detectar isso cedo.

Posso testar mudanças de prompt sem gastar dinheiro?

Sim. Use o mock server do Apidog para testar cliente, timeout, asserções e tratamento de erro. Use a API real apenas para medir tokens, latência e qualidade final.

Conclusão

Estender o uso do Fable 5 é uma questão de engenharia de prompt: escolha o esforço certo, limite escopo, peça concisão, exija evidências em execuções longas e forneça contexto suficiente. Depois, valide tudo com testes.

No Apidog, transforme cada prompt em uma requisição parametrizada, rode testes A/B, compare output_tokens, latência e stop_reason, e mantenha apenas as variantes que entregam o mesmo resultado com menos custo.

Top comments (0)