Como medir se o Claude Fable 5.1 melhorou o seu resultado depois da troca?

Sentir que melhorou é fácil

Provar que melhorou é outra história 🙂

Você já trocou de modelo, já sentiu que o negócio ficou mais esperto, e agora vem a pergunta chata: onde está o número que sustenta isso? A Anthropic anunciou o Claude Fable 5.1 em 01/09/2026, junto com o Claude Mythos 5.1 (mesmo modelo, salvaguardas diferentes: o Fable 5.1 geralmente disponível e o Mythos 5.1 só por programas de acesso confiável, em cibersegurança e ciências da vida)

Benchmark oficial é ótimo pra saber pra onde o modelo puxa, mas ele não roda o SEU código, na SUA base, com as SUAS manias de prompt

Então bora montar um registro simples, com métricas que você mesmo coleta, pra decidir com dado próprio se a troca fica ou volta atrás

O que você precisa antes de começar a medir

Aqui só entra o que dá pra conferir. Nada de configuração mágica inventada, beleza?

• Claude Code na versão 2.1.250 ou posterior, que é o mínimo pra usar o Fable 5.1
• Acesso ao modelo: na API o identificador é claude-fable-5-1, e a disponibilidade é na Claude Platform mais Amazon Web Services, Google Cloud e Microsoft Foundry
• Um plano pago: Fable 5 e Fable 5.1 estão em Pro, Max, Team e Enterprise
• O comando /model, que abre o seletor de modelos do Claude Code (ele também aceita o nome do modelo na própria linha do comando)
• A lista oficial de mudanças, na doc What’s new in Claude Fable 5.1, pra você saber o que esperar antes de medir

Uma ressalva importante de bolso, porque ela muda o desenho do seu teste: em planos Pro e assentos padrão, os modelos Fable rodam desde o início com usage credits pay-as-you-go, já que eles não entram nos limites do plano

Em planos Max e assentos premium a regra é outra: ao atingir até 50% do limite semanal usando modelos Fable, você segue com usage credits ou troca para outro modelo Claude dentro dos limites do plano

Ou seja, medir custo aqui não é firula, é parte do resultado

E se você usa o mesmo modelo em cloud diferente, vale lembrar que rodar o mesmo modelo em provedores diferentes muda a sua conta e o seu fluxo, então registre em qual ambiente cada rodada aconteceu

Passo a passo: montando seu registro de comparação

A lógica é a de qualquer experimento: mesma tarefa, mesmo enunciado, muda só o modelo

Se você conhece o básico de teste A/B, é isso, só que feito na unha e com uma variável só

1. Escolha de 3 a 5 tarefas-âncora repetíveis do seu dia a dia. Tem que ser coisa que você faz toda semana: criar um CRUD, caçar um bug conhecido, refatorar um módulo, subir um scaffolding. O erro comum deste passo: escolher aquela tarefa épica que você faz uma vez por ano, porque ela não gera repetição e sem repetição não tem comparação

2. Defina cada métrica em uma frase, por escrito, antes de rodar. Exemplo de definição que funciona: retrabalho é todo trecho que já tinha sido dado como pronto e precisou voltar, ida e volta é cada mensagem sua depois do enunciado inicial, intervenção manual é toda vez que você abriu o editor e corrigiu na mão, e tarefa concluída sem intervenção é a que passou no seu critério de pronto sem você tocar no código. O erro comum deste passo: mudar a definição no meio do caminho, aí o número da segunda rodada vira outro número e você compara laranja com abacaxi

3. Rode a linha de base ainda no modelo antigo, ou reaproveite registros de sessões passadas suas, se você já anotava algo. O erro comum deste passo: começar a medir só depois de trocar, e ficar sem termo de comparação (aí sobra só o "achei que ficou melhor")

4. Troque de modelo com o /model. Abrindo o seletor:

   /model

Ou já mandando o nome do modelo na linha do comando:

   /model claude-fable-5-1

O erro comum deste passo: achar que trocou e não conferir. Abre o seletor de novo e olha qual modelo está ativo antes de sair rodando. E confirme a versão, porque abaixo da 2.1.250 o modelo não é uma opção pra você

5. Rode as mesmas tarefas com o mesmo enunciado, palavra por palavra. Copia e cola mesmo, sem melhorar nada. O erro comum deste passo: caprichar no prompt na segunda rodada. Se você melhorou o prompt, o que você mediu foi você, não o modelo 😀

6. Colete tokens e custo estimado da sessão com o /usage.

   /usage

Ele mostra estatísticas de uso de tokens da sessão atual e as barras de uso do plano. O erro comum deste passo: tratar o valor em dólar como fatura. Esse número é uma estimativa calculada localmente a partir da contagem de tokens, e pode divergir da cobrança real

7. Confira o gasto real na página de Usage do Claude Console, que é a referência autoritativa de billing. O erro comum deste passo: comparar uma semana cheia de rodadas com uma semana pela metade, ou misturar no mesmo balde o uso do experimento e o uso do trabalho normal. Marque a janela de tempo de cada rodada no seu registro

8. Opcional, pra quem quer parar de anotar tudo na mão: ligue a telemetria do Claude Code.

   export CLAUDE_CODE_ENABLE_TELEMETRY=1

Com a telemetria habilitada, o Claude Code exporta via OpenTelemetry métricas de uso de tokens, sessões, edições de código, chamadas de ferramenta e custo, além de eventos e traces pelos protocolos padrão. O erro comum deste passo: ligar a telemetria e achar que ela responde sozinha se o modelo melhorou. Ela te dá volume e custo, quem julga qualidade e retrabalho ainda é você

A planilha mínima: colunas, como coletar e o que o número indica

Não precisa de ferramenta nova. Uma planilha de nove colunas resolve, e ela cabe numa aba só

O importante é separar o que é medição direta do que é estimativa, senão daqui a duas semanas você não sabe mais qual número confiar

As quatro colunas de contagem e marcação são as que mais dizem sobre o seu dia a dia, e são justamente as que nenhum benchmark de terceiro tem

Já as colunas de custo têm um contexto que ajuda a ler o resultado: o preço base de tokens do Fable 5.1 continua igual ao do Fable 5, US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de tokens de saída

O que mudou foi a leitura de cache, que caiu para US$ 0,25 por milhão de tokens em cache reads, 75% mais barato que no Fable 5

A Anthropic estima que isso dê cerca de 25% menos custo em cargas típicas, e até aproximadamente 45% em cargas altamente agênticas

Repare no detalhe: isso é estimativa da fornecedora sobre cargas genéricas, não é promessa sobre a sua conta. Por isso a coluna de custo confirmado existe 😀

Que tipos de tarefa valem como termômetro da troca

Nem toda tarefa serve de âncora. Tem tarefa que gera sinal claro e tem tarefa que só gera discussão

Tarefa longa e agêntica, de várias etapas no terminal. É onde o ganho de cache mais aparece na conta, porque o contexto é relido várias vezes ao longo da sessão. Aqui você mede custo E idas e vindas ao mesmo tempo

Tarefa de bug com critério de pronto objetivo. Aquele bug que ou o teste passa ou não passa. Como o veredito é binário, a contagem de retrabalho fica honesta, sem aquele "ficou mais ou menos bom"

Scaffolding de projeto do zero. Enunciado grande, resultado visível, fácil de repetir com o mesmo texto. Você consegue contar funcionalidades entregues e tempo até estar de pé

Manutenção repetitiva. Ajustar um formulário, adicionar um campo, atualizar uma tela. É o tipo de coisa que você faz várias vezes na semana, então o volume de rodadas cresce rápido e a média fica confiável

E o que NÃO serve? Tarefa vaga e tarefa criativa demais

Se o enunciado é "melhora a arquitetura aí", cada rodada entrega uma coisa diferente e não existe critério de pronto, então a comparação vira gosto pessoal

Um empurrãozinho pra escolher a âncora: os benchmarks divulgados pela Anthropic apontam pra tarefas de terminal. No Terminal-Bench-Science 0.1 o Fable 5.1 marcou 52,6%, contra 24,7% do Fable 5 e 29,0% do Opus 5

No Terminal-Bench 4.0 foram 55,8% do Fable 5.1 contra 42,0% do Fable 5

Isso ajuda a decidir onde procurar diferença, mas não promete que o seu número vai ser esse. O seu número é o que a sua planilha disser

Como usei uma tarefa única como referência de comparação

Quando testei o Fable no Claude Code, eu não fiquei conversando com o modelo pra ver se ele era esperto

Eu montei uma tarefa-âncora e mandei bala: um prompt único pedindo um sistema de e-commerce completo, com homepage, carrinho, checkout, autenticação e painel admin já populado com produtos

O critério de medição era duplo e definido ANTES: entregou todas as funcionalidades pedidas? E quanto tempo levou?

Deu 1 prompt (one shot) e 30 minutos até o projeto estar gerado

Só que código gerado não é resultado medido, então eu não parei aí. Subi a aplicação e percorri o fluxo real de compra: escolhi um produto, joguei no carrinho, criei conta, fui pro pagamento e simulei a aprovação

O fluxo funcionou de ponta a ponta na minha máquina, sem quebrar no meio, e os campos de cadastro já vinham preenchidos pelo autocomplete do próprio sistema gerado. Massa demais 🙂

Repara no formato, que é o que interessa pra você aqui: enunciado escrito uma vez e reaproveitado, contagem de prompts, tempo até estar de pé, e uma verificação manual do fluxo pra contar intervenções de verdade

Duas ressalvas honestas, porque impressão não vira dado

A primeira: resultado desse tipo não cai do céu. Tem preparo e teste por trás do prompt, não é pedir e esperar milagre

A segunda: eu vi muita reclamação de gente com pedido comum sendo bloqueado, e a camada de segurança mais rígida realmente pode barrar requisição que não teria problema nenhum, o que atrapalha quem estava fazendo algo totalmente legítimo

E olha só como isso encaixa na planilha: bloqueio de pedido legítimo é ida e volta, é intervenção manual, é tempo. Ou seja, é medível no SEU registro, não precisa virar briga de opinião na timeline

Vídeo: o teste na prática

No vídeo abaixo eu mostro esse teste rodando dentro do Claude Code, do seletor de modelo até o fluxo de compra funcionando no navegador

Vale ver justamente como modelo de tarefa-âncora: enunciado único, critério de pronto definido antes, e verificação na mão depois que o código ficou pronto

Conclusão

Três rodadas anotadas por você valem mais que qualquer benchmark de terceiro, porque elas rodam na sua base, com as suas tarefas e a sua conta

O caminho é simples: escolhe hoje UMA tarefa-âncora, roda, anota as quatro métricas de contagem (prompts, intervenções manuais, retrabalho, tarefas concluídas sem intervenção), pega tokens e custo estimado no /usage

No fim da semana você confere o gasto real na página de Usage do Claude Console e compara o que apareceu no seu registro com a doc oficial de mudanças do Fable 5.1

Aí sim dá pra decidir com cara limpa se a troca fica ou se você volta pro modelo anterior, sem depender de achismo de ninguém (nem do meu 😀)

Bora medir? Anota a primeira rodada ainda hoje, que semana que vem você já tem gráfico…

até o próximo post!