Fable 5.2, 5.1 ou Opus 5.5: quando vale a pena trocar?

O Fable 5.2 é o candidato de atualização com preço menor para tarefas já executadas no Fable 5.1, mas o Opus 5.5 continua sendo o ponto de partida mais barato para muitas tarefas novas. A decisão útil é saber se o modelo mais caro entrega um resultado aceito com menor custo total ou atende a uma exigência que o mais barato não consegue cumprir.

Esta é uma comparação de recursos documentados e custos, verificada em 10 de novembro de 2026, com cálculos reproduzíveis. Não é um benchmark de velocidade nem uma alegação de taxas de sucesso medidas. A Ofox publica este artigo e oferece os modelos em seu catálogo de API; essa relação não comprova que algum deles seja o melhor para sua carga de trabalho.

O que realmente muda

Fontes: tabelas oficiais dos modelos Fable 5.2 e Fable 5.1, além da referência de preços. Os limites são iguais; portanto, precisar de uma janela de contexto maior não diferencia esses três modelos.

O registro datado do catálogo Ofox lista as mesmas tarifas padrão nesses campos, sob anthropic/claude-fable-5.2, anthropic/claude-fable-5.1 e anthropic/claude-opus-5.5. Trata-se de comparação de preços de lista, não de preços de fornecedores nem de uma fatura. Tipos de provedor e disponibilidade de recursos podem variar; registre a rota junto com o nome do modelo.

O Fable 5.2 reduz as tarifas comuns de entrada e saída em 20% em relação ao 5.1. Custa o dobro do Opus 5.5 por token de entrada sem cache ou de saída, mas a tarifa de leitura de cache é igual. Nenhuma dessas observações determina o custo de uma tarefa de agente concluída: tamanho da saída, comportamento do cache, número de tentativas e uso de ferramentas podem variar.

Três cenários de custo que você pode recalcular

Os orçamentos de tokens abaixo são sintéticos, não saídas medidas. Todos usam preço padrão síncrono em USD, sem desconto de batch, modo rápido ou ferramentas cobradas separadamente. Saída significa toda a saída faturada, incluindo raciocínio quando cobrado. Os cenários de leitura de cache excluem a requisição anterior de gravação e não representam a conta de uma sessão inteira.

A última linha mostra por que a afirmação genérica “Fable custa o dobro” não vale para uma requisição dominada pelo cache. A parcela de cache custa $0.02 tanto no 5.2 quanto no Opus 5.5. Somente entrada e saída restantes recebem a tarifa maior do Fable, resultando em uma razão de custo por requisição de aproximadamente 1,23, não 2.

Use este cálculo para a linha do meio:

from decimal import Decimal as D

rates = {
    "fable52": (D("8"), D("40"), D("0.20")),
    "fable51": (D("10"), D("50"), D("0.25")),
    "opus55": (D("4"), D("20"), D("0.20")),
}
for name, (input_rate, output_rate, read_rate) in rates.items():
    cost = (1000 * input_rate + 4000 * output_rate
            + 19000 * read_rate) / D("1000000")
    print(name, cost)

A criação de cache tem cobrança própria. As tarifas publicadas de gravação por 5 minutos são, respectivamente, $10, $12.50 e $5 por milhão de tokens; por 1 hora, $16, $20 e $8. Adicione à estimativa da sessão a gravação correspondente, as falhas reais de cache e o efeito da expiração. Não precifique todos os turnos como acertos de cache só porque o código contém uma diretiva de cache.

Quanta saída adicional eliminaria a economia em relação ao 5.1?

Suponha que uma tarefa no 5.1 consuma os 20.000 tokens de entrada sem cache e 4.000 de saída da primeira linha. O custo calculado é $0.40. Com a mesma entrada no 5.2, $0.16 são gastos na entrada, deixando $0.24 até atingir esse total. A $40 por milhão de tokens de saída, isso paga 6.000 tokens de saída.

Sob essas hipóteses específicas, o 5.2 poderia usar 50% mais saída do que o exemplo do 5.1 e ainda custar o mesmo. Se entrada e saída crescessem na mesma proporção, a redução de tarifa de 20% permitiria, em vez disso, um aumento de 25% no volume de tokens antes do empate. As porcentagens respondem a perguntas diferentes; nenhuma prevê o comportamento real do modelo.

Por isso, a primeira medição da migração deve capturar categorias de tokens para a mesma tarefa. Uma tarifa mais barata e uma conta mais cara podem ser verdade ao mesmo tempo quando o modelo novo faz mais trabalho, repete tentativas ou usa ferramentas adicionais. O guia de API explica quais campos da resposta guardar.

Escolha pela tarefa e pela condição de aceitação

São critérios de seleção, não resultados de desempenho de um torneio próprio entre modelos. Por exemplo, uma tarefa de extração de faturas deve rejeitar uma saída sem ID de fatura ou com total incorreto, mesmo que a redação seja fluente. Um reparo de repositório deve passar nos testes relevantes e evitar mudanças sem relação com a tarefa. Um relatório de pesquisa deve associar uma fonte acessível a cada afirmação importante e preservar conflitos de evidência ainda não resolvidos.

A orientação oficial de seleção de modelos recomenda começar com Opus na maioria das cargas e avançar quando as avaliações continuarem insuficientes. O valor da linha Fable está no trabalho que consegue entregar com aceitação, não em um número de versão maior por si só.

Compare custo por tarefa aceita, não apenas por chamada

Em um conjunto de tarefas comparáveis, registre o gasto total com API e ferramentas dividido pelo número de entregas aceitas. Mantenha tarefas rejeitadas, incompletas e corrigidas manualmente na contabilidade. Excluir falhas faz um modelo fraco parecer artificialmente barato.

Como ilustração, suponha custo de $0.16 por tentativa com Opus e $0.32 com Fable, como na primeira linha sintética. Se as taxas de aceitação fossem 50% e 90%, respectivamente, os custos simplificados por tentativa aceita seriam $0.32 e cerca de $0.356. A aceitação maior não compensaria automaticamente a diferença de preço. Essas taxas foram inventadas para o cálculo e não são resultados medidos dos modelos.

Esse modelo simplificado supõe tentativas independentes e comparáveis e exclui reparo humano, tempo de fila e ferramentas externas. Um fluxo real pode preferir um modelo com menos tentativas porque cada falha exige revisão cara. Informe esse custo separadamente, com uma hipótese explícita de valor por hora, em vez de escondê-lo em uma alegação de desempenho por token.

Em um roteador por etapas, meça o caminho inteiro: tentativa no Opus, validação, escalonamento, tentativa no Fable e validação final. Começar pelo modelo mais barato não é gratuito se quase todas as tarefas forem escaladas. Nunca repita o mesmo efeito colateral não idempotente ao comparar rotas.

Considere o custo de migração antes de mover o tráfego

O Fable 5.2 verifica prefixos de conversa em todas as contas. Um cliente legado que reescreve prompts de sistema ou ferramentas pode precisar de correções mesmo que as chamadas ao 5.1 fossem aceitas. O esforço padrão também difere do Opus 5.5: deixar effort sem configuração muda a comparação de medium para high. Configure o valor explicitamente e informe a configuração.

O guia de migração também aponta diferenças de retenção, ferramenta de computador, advisor e compatibilidade de thinking. Em particular, a ferramenta antiga de computer use tem uma exceção para Amazon Bedrock; não aplique uma incompatibilidade específica de plataforma a todas as rotas Ofox. O diagnóstico de 400 apresenta os caminhos de correção.

Ao fazer fallback do 5.2 para um modelo antigo, uma requisição bem-sucedida não necessariamente preserva o raciocínio do 5.2. Salve fatos verificados da tarefa e resultados de ferramentas separadamente. Nosso guia de checkpoint para agentes explica o que o modelo de destino precisa para concluir o trabalho.

Faça uma comparação pequena o suficiente para inspecionar

Use um conjunto fixo de tarefas representativas, reservando uma parte para teste. Fixe prompt, arquivos de entrada, ferramentas e critérios de aceitação antes de examinar resultados. Para cada modelo, registre ID exato, rota, effort, limite de tokens, versão do SDK, timestamps, uso de entrada/saída/cache, gasto com ferramentas, status de conclusão e veredito de aceitação.

Comece pela configuração normal de produção de cada candidato e depois compare níveis de esforço explicitamente se precisar ajustar custo ou qualidade. Rótulos iguais de effort são um controle de configuração, não prova de computação interna equivalente. Preserve também o registro de timeouts, novas tentativas, recusas e ausência de saída; não substitua esses casos silenciosamente por novas execuções bem-sucedidas.

Adote o 5.2 quando ele atingir sua qualidade mínima e melhorar um objetivo explícito, como custo por tarefa aceita, conclusão de casos difíceis ou esforço de revisão. Mantenha o 5.1 disponível somente enquanto for necessário para um rollback testado, distinguindo retorno à versão do modelo de restauração do estado assinado da conversa.

Documentação relacionada: catálogo de modelos da Ofox, acompanhamento de uso e Messages nativo. Se uma execução comparativa falhar após uma chamada de ferramenta, resolva o erro de associação do resultado, guia em inglês antes de interpretar a execução como evidência da qualidade do raciocínio.