🎛️ Esforço é o primeiro botão
No Fable 5.1 o raciocínio interno está sempre ligado. O que você controla é a profundidade, com o parâmetro de esforço. Ele escala quanto o modelo pensa e quantas ferramentas chama. Custa saída (que é a parte cara), mas não muda o modelo.
| Nível | Quando faz sentido | Efeito típico |
|---|---|---|
| low | Subagentes, tarefas simples, alto volume, latência importa | Menos chamadas de ferramenta, menos preâmbulo, confirmações curtas |
| medium | Passo de economia onde a qualidade se mantém | Em pesquisa, igualou o padrão a 70–85% do custo |
| high (padrão) | Trabalho sensível a inteligência | Equilíbrio entre qualidade e eficiência |
| xhigh | Código e agentes de longo horizonte (padrão do Claude Code) | Mais uso de ferramentas, mais profundidade |
| max | Quando acertar importa mais que custar | Só depois de medir que há ganho acima de xhigh |
⚠️ Regra que não pode ser quebrada
Varra o esforço no modelo atual antes de descer de modelo. Se em esforço baixo a tarefa ainda passa, aí sim desça um degrau, redefina o esforço para o padrão daquele modelo e varra de novo. Uma alavanca por vez.
📉 Curva plana: pesquisa e conhecimento
📊 Medições publicadas (Fable 5, pesquisa e conhecimento)
- •medium: mesma acurácia do padrão em quatro benchmarks, a 70% a 85% do custo.
- •low: 1 a 3 pontos a menos, um terço a metade a menos de custo por tarefa.
- •O padrão não comprou nada mensurável acima de medium em nenhum dos quatro.
- •Tempo: 4,5 minutos por problema em low contra 7,9 no padrão, num benchmark de pesquisa.
Copie e rode
Varredura mínima de esforço para uma tarefa sua de pesquisa (Claude Code ou API)
1. Escolha 10 pedidos reais de pesquisa/resumo que você faz (inclua 2 difíceis).
2. Rode os 10 em esforço LOW, em sessão separada. Anote custo (ou tokens) e se a resposta serviu.
3. Rode os mesmos 10 em MEDIUM, sessão separada. Anote.
4. Rode em HIGH. Anote.
5. Monte a tabela: nível | serviu (de 10) | custo médio.
Leia: se "serviu" for igual em low e high, a curva é plana. Fique no low.📈 Curva íngreme: código longo
📊 Medições publicadas
- •Código de horizonte longo (Opus 5): medium perdeu ~2 pontos por metade do custo; low perdeu ~8 pontos por um quarto.
- •Trabalho no teto de raciocínio (pesquisa profunda com vários subtemas): cada degrau de esforço comprou ~2,4 pontos de rubrica. Não há corte grátis nessa curva.
✓ Sinais de que sua tarefa tem curva íngreme
- ✓Muitas etapas encadeadas, uma depende da outra.
- ✓Erros só aparecem no fim (teste que quebra, arquivo que não abre).
- ✓A tarefa difícil é a regra, não a exceção.
✗ Sinais de curva plana
- ✗Ler, resumir, comparar, classificar.
- ✗Cada pedido é independente.
- ✗Você consegue julgar a resposta em segundos.
💡 Inclua a tarefa difícil na varredura
Curvas são mais planas em tarefas fáceis. É na cauda difícil que o esforço alto paga o próprio custo. Se sua amostra só tem tarefas fáceis, ela vai dizer que tudo é plano, e você vai descobrir a curva íngreme em produção.
♻️ Rode barato e refaça só o que falhou
Se a curva é íngreme mas você consegue detectar quando falhou (um teste, um validador de formato, um checador), existe uma saída: rode tudo em baixo e refaça no padrão só o que falhou.
| Política | Taxa de acerto | Custo por tarefa |
|---|---|---|
| Tudo no padrão | 91,7% | $1,39 |
| Tudo em low, refazer falhas no padrão | ~93% | ~$0,70 |
| Tudo em medium, refazer falhas no padrão | ~94% | ~$0,95 |
Copie e rode
Molde de verificador simples para a política (exemplo com um arquivo gerado)
# 1) tarefa em esforço baixo gera saida.json
# 2) verificador: o arquivo existe, é JSON válido e tem os campos exigidos?
python3 - <<'EOF'
import json, sys
try:
d = json.load(open("saida.json"))
faltando = [k for k in ("titulo", "resumo", "data") if k not in d]
sys.exit(1 if faltando else 0)
except Exception:
sys.exit(1)
EOF
# 3) se saiu com código 1, refaça a tarefa no esforço padrão🦎 Precifique a cauda, não a mediana
Compare modelos na décima parte mais difícil do seu trabalho. Na tarefa típica todos parecem parecidos e o mais barato parece o melhor; a conta é decidida pelas tarefas que o modelo barato erra. E mesmo sem falha nenhuma, a cauda concentra o gasto.
Como precificar a cauda
Identifique os 10% mais difíceis
Do seu fluxo real
Quais tarefas mais demoram, mais voltam com erro, mais exigem correção? Liste-as. São elas que vão decidir.
Rode só essas nos candidatos
Modelo A × modelo B
Não gaste amostra com as fáceis. Nas fáceis todo mundo passa.
Conte custo e falhas na cauda
Aqui aparece a diferença
Um modelo barato que falha em 3 das 5 difíceis custou 3 refações. Some.
Decida pela cauda
Não pela média
Se o modelo mais caro vence na cauda e empata no resto, ele é mais barato no total, porque a cauda é onde o dinheiro está.
📏 Regras de medição que evitam decisão errada
✓ Faça
- ✓Células idênticas exceto o esforço; mesmo modelo; mesma ordem de pedidos.
- ✓Um nível por sessão. Complete todos os pedidos num nível antes de ir ao próximo.
- ✓Inclua uma tarefa difícil que você conhece.
- ✓Repita a rodada quando a diferença for de uma ou duas tarefas.
- ✓Aplique uma alavanca por vez, meça, mantenha ou reverta.
✗ Não faça
- ✗Trocar esforço no meio da sessão (invalida cache, distorce).
- ✗Decidir por uma rodada só quando está apertado.
- ✗Amostra só de tarefas fáceis.
- ✗Aplicar cache + esforço + modelo juntos e não saber o que ajudou.
- ✗Guardar uma alavanca que economizou mas devolveu acurácia: isso não é otimização.
🧪 Receita mínima de avaliação (para quem não tem nenhuma)
- •Entradas: 20 a 30 pedidos reais, congelados. Toda configuração roda o mesmo conjunto.
- •Julgamento: o mais barato que sirva: resposta-gabarito, uma rubrica curta que você pontua, ou um checador automático (teste passa, JSON válido).
- •Executor: um roteiro que roda o conjunto numa configuração, grava saída e uso de tokens, e reporta acerto e custo por tarefa.
- •Aprovação: estime o custo (entradas × configurações × custo por tarefa) antes de rodar.
🧪 Teste rápido do módulo
Três perguntas. Clique numa opção para ver a resposta.
1. Qual é a ordem correta das alavancas de custo, da primeira para a última?
2. Sua tarefa é código longo com curva íngreme, mas você tem testes automatizados. Qual política economiza?
3. Por que comparar modelos pela mediana das tarefas leva a erro?
📋 Resumo do módulo
Próximo módulo:
3.3 - Alavancas do 5.1 para quem usa a API