# Claude Fable 5.2 vs Opus 5.5: código e tarefas de agente > Fable 5.2 e Opus 5.5 nas mesmas tarefas de código e ferramentas: qualidade das respostas, tempo, tokens usados e custo estimado pelas tarifas oficiais. - Canonical HTML: https://omniakey.com/pt-BR/blog/fable-5-2-vs-opus-5-5 - Markdown: https://omniakey.com/pt-BR/blog/fable-5-2-vs-opus-5-5.md - Published: 2026-11-12 (updated 2026-11-12) - Author: Kiki, COO at OmniaKey - Language: pt-BR - Category: Comparison - Reading time: 9 min - All posts: https://omniakey.com/blog/llms.txt --- Nestas quatro tarefas pequenas de código e ferramentas, o prêmio do Fable 5.2 não se paga: [Claude Fable 5.2](https://omniakey.com/pt-BR/claude-fable-5-2) e [Claude Opus 5.5](https://omniakey.com/pt-BR/claude-opus-5-5) passaram nas 29 verificações de código, e a estimativa pela tarifa padrão ficou em $0,031 para o Opus no conjunto, contra $0,146 do Fable. Considere o Fable para raciocínio mais difícil ou execuções longas de agente quando o Opus com esforço maior não der conta. - **Claude Opus 5.5** (Comece por ele nas correções pequenas): Escolha padrão para tarefas curtas de código e ferramentas: 29/29 verificações e uma estimativa pela tarifa padrão de $0,031 para quatro tarefas. - **Claude Fable 5.2** (Avalie quando o Opus não bastar): Avalie o Fable para raciocínio mais difícil ou execuções longas de agente quando o Opus com esforço maior falhar nos seus próprios casos. ## Fable 5.2 e Opus 5.5 em resumo O Fable 5.2 é mais novo, mas os dois modelos compartilham a mesma janela de contexto de 1M tokens e a mesma saída de 128K tokens. A diferença prática neste teste foi o uso de tokens, não a correção do código. |Item|Fable 5.2|Opus 5.5| |-|-|-| |Lançamento|9 de nov. de 2026|22 de set. de 2026| |Contexto / saída|1M / 128K|1M / 128K| |Esforço padrão|high|medium| |Entrada / saída ($/1M)|$8 / $40|$4 / $20| As páginas de modelo da Anthropic do [Fable 5.2](https://platform.claude.com/docs/en/models/fable-5-2/overview) e do [Opus 5.5](https://platform.claude.com/docs/en/models/opus-5-5/overview) listam os dois como ativos, com entrada de texto e imagem. O Fable saiu em 9 de novembro de 2026; o Opus, em 22 de setembro de 2026. Os níveis de esforço padrão são diferentes, então ajuste `medium` nos dois quando for comparar. A [visão geral de modelos](https://platform.claude.com/docs/en/models/overview) da Anthropic recomenda o Opus 5.5 para a maioria das tarefas. Ela posiciona o Fable 5.2 para raciocínio exigente e trabalho de agente de longo prazo, ou para casos em que as avaliações do Opus 5.5 com esforço maior ainda ficam aquém. Esse é o posicionamento do fabricante; este teste cobre quatro tarefas pequenas. Para ver o que mudou na versão, leia [o que mudou no Fable 5.2](https://omniakey.com/pt-BR/blog/claude-fable-5-2). Para uma análise de um modelo só, veja a [análise do Opus 5.5](https://omniakey.com/pt-BR/blog/claude-opus-5-5-review). ## Quanto custam as quatro tarefas A [página de preços oficial](https://platform.claude.com/docs/en/about-claude/pricing) da Anthropic lista $8 de entrada e $40 de saída por milhão de tokens para o Fable 5.2, contra $4 e $20 do Opus 5.5 (verificada em 12 de nov. de 2026). O Batch corta os dois pares pela metade; o modo fast os dobra. Nas quatro tarefas pontuadas, o Fable usou 3.439 tokens de entrada e 2.954 de saída. O Opus usou 2.421 e 1.065. Pela tarifa padrão, a conta fica assim: - Fable: (3.439 × $8 + 2.954 × $40) ÷ 1.000.000 = $0,1457 - Opus: (2.421 × $4 + 1.065 × $20) ÷ 1.000.000 = $0,0310 São estimativas pela tarifa padrão a partir dos tokens observados, não faturas nem cobranças da OmniaKey. A resposta do Opus informou velocidade fast, e a do Fable, standard; a Anthropic lista entrada e saída no fast pelo dobro da tarifa padrão. Aqui normalizamos os dois para a tarifa padrão, então os números não são uma comparação controlada de tempo nem de cobrança. Estimativas pela tarifa padrão, em dólares: |Tarefa|Fable 5.2|Opus 5.5| |-|-|-| |Totais de uso|$0,0498|$0,0067| |Páginas de cursor|$0,0428|$0,0102| |Livro-razão|$0,0180|$0,0053| |Patch de arquivo|$0,0351|$0,0088| |Quatro tarefas|$0,1457|$0,0310| Na média das quatro tarefas testadas, o Fable ficou em $0,0364 e o Opus em $0,0077; a estimativa pela tarifa padrão do Fable foi $0,1147 maior no conjunto. A regra prática é o custo por tarefa utilizável: gasto de API mais tempo de nova tentativa e revisão. Suba de modelo quando casos reais que falharam justificarem esse gasto extra; estas quatro tarefas pequenas não justificam. Os totais de tempo real foram 27,8 s para o Fable e 43,6 s para o Opus. As respostas do Fable informaram velocidade standard e as do Opus, fast, e não fixamos nenhuma; leia como observações, não como um ranking de velocidade. ## Duas correções em Python: 22/22 verificações nos dois As duas correções são curtas, e os dois modelos devolveram funções que funcionam. Vale reaproveitar as falhas porque elas testam o tratamento de revisões e os casos de borda da paginação, não o conhecimento de uma biblioteca. ### Totais de uso: uma falha nova precisa apagar um sucesso antigo A função antiga somava todos os eventos complete. Ela ignorava revision e status, então uma nova tentativa contava os tokens duas vezes, e uma revisão failed mais nova não conseguia anular uma complete anterior. A regra central do prompt: > Keep only the highest revision for each event\_id, and on equal revisions keep the last occurrence in the input. A newer failed revision supersedes an older complete one and contributes nothing. A menor reprodução é o evento x na revisão 1, complete, 10 tokens, seguido de x na revisão 2, failed, 10 tokens. O total certo é zero; a função antiga devolve 10. Os dois modelos mantiveram a revisão mais alta, usaram a ordem de entrada para revisões iguais, pularam os vencedores failed, mantiveram os usuários com zero token e deixaram a entrada intacta. **Resultado:** 8/8 verificações cada um, com funções equivalentes. ### Paginação por cursor: empates não podem repetir nem pular A versão antiga ordenava só por `ts`, cortava a primeira página antes de aplicar o cursor, aceitava timestamps iguais com `<=`, nunca validava `limit` e sempre devolvia um cursor seguinte. Com duas linhas em `ts=4`, isso repete ou pula um ID. As regras centrais do prompt: > Sort descending by (ts,id). Select rows strictly LESS than the cursor tuple, so tied timestamps neither repeat nor skip IDs. Return next\_cursor only if MORE eligible rows remain. Raise ValueError unless limit is an integer from 1 through 100; bool is invalid. Os dois corrigiram tudo: ordenação por tupla, menor estrito, filtro da lista completa antes do corte, cursor seguinte só quando sobram linhas e validação que rejeita `True`, `False`, `0`, `101`, `1.5`, `'2'` e `None`. **Resultado:** 14/14 verificações cada um, incluindo uma varredura de uma linha sobre timestamps empatados. ## O livro-razão assíncrono: mesmos números, JSON diferente Os dois modelos acertaram a conciliação: $0,93 líquidos reservados, t3 pendente, t1 e t5 concluídas e `poll_existing` para t3. O fixture sintético fornecido usa valores ilustrativos, não preços da OmniaKey. As linhas principais: > POST key=a => 201 task=t1 quote=0.40 > > POST key=a, identical body => 200 task=t1 > > GET t1 => SUCCEEDED > > POST key=b => 201 task=t2 quote=0.40 > > GET t2 => FAILED > > POST key=c => 201 task=t3 quote=0.13 > > Client stopped polling t3 after 120 seconds; last status PROCESSING > > POST key=d => 201 task=t4 quote=0.13 > > GET t4 => CANCELED > > POST key=e => 201 task=t5 quote=0.40 > > GET t5 => SUCCEEDED A aritmética é 0,40 + 0,13 + 0,40 = 0,93. t2 e t4 são reembolsadas; t1 e t5 consomem; t3 mantém a reserva porque o cliente parou de consultar, não porque a tarefa falhou. Contando só as tarefas com último estado observado SUCCEEDED, os dois devolveram os mesmos valores. O Fable devolveu JSON cru. O Opus envolveu o JSON em um bloco de código JSON. O prompt dizia "Return ONLY JSON", então um `json.loads` estrito na resposta do Opus falha até o bloco ser removido. É um desvio só de formato: o pedido era texto JSON puro, sem schema JSON e sem modo de saída estruturada. **Resultado:** os valores passam nos dois; para automação, valide a resposta crua com um parser estrito ou use saída estruturada. Foi um desvio observado, não um padrão geral. ## A tarefa de arquivo em dois turnos: uma leitura, um patch O `remaining_quota` antigo do fixture subtraía as units de todos os eventos. Ignorava o último estado de cada id e o piso `max(0, ...)`, então tarefas failed ou canceled continuavam consumindo cota, e eventos repetidos eram debitados duas vezes. A tarefa: > Use read\_file once to inspect quota.py, then return one Python code block containing only a corrected remaining\_quota(limit, events) function. Os dois modelos fizeram exatamente uma chamada `read_file` para `quota.py`. Quando o fixture voltou, os dois devolveram a mesma lógica de patch: manter o último evento por id, somar units só para reserved ou succeeded e devolver `max(0, limit - consumed)`. **Resultado:** 7/7 verificações cada um, incluindo os casos failed e depois reserved e os de limite estourado. São dois turnos e um fixture. Mostra que os modelos pedem o arquivo certo e o corrigem; não cobre uma execução longa de agente. ## Como testamos Em 12 de nov. de 2026, enviamos quatro tarefas para `claude-fable-5-2` e `claude-opus-5-5` pelo endpoint Messages da OmniaKey. Cada par modelo/tarefa usou uma conversa nova e cache frio, com esforço `medium`, `max_tokens` 4096 por requisição, sem system prompt, sem temperature nem top\_p e uma tentativa. Alternamos qual modelo ia primeiro conforme a tarefa. A tarefa de agente usou uma ferramenta `read_file` estrita com `tool_choice: auto`; o resto foi uma única mensagem de usuário. O avaliador filtrava cada resposta em Python por AST e depois a executava em um processo isolado com limite de 3 segundos contra 8 casos de uso, 14 de cursor e 7 de agente: 29 casos de código por modelo. Cada requisição rodou uma vez. O primeiro prompt do livro-razão deixava em aberto se tarefas FAILED/CANCELED entram em `completed_task_ids`. Trocamos essa rodada ambígua por uma repetição esclarecida por modelo, contando só as tarefas com último estado observado SUCCEEDED; as saídas originais ficam fora dos totais das quatro tarefas pontuadas. As 12 requisições devolveram HTTP 200 com o ID de modelo pedido e terminaram em `end_turn`, ou `tool_use` e depois `end_turn`, sem truncamento. Os dois informaram service tier standard. O Fable informou velocidade standard e contagens separadas de tokens de thinking; o Opus informou velocidade fast e omitiu o campo de tokens de thinking. Deixamos a velocidade sem definir, e os tokens de saída já incluem o thinking cobrado, então o campo ausente do Opus não diz nada sobre thinking zero. A mesma string de esforço é um ajuste, não um orçamento de computação equiparado. Esta execução mantém o esforço em `medium`; para o seu próprio trabalho, percorra os níveis de esforço que a sua tarefa pede. É um teste com um fixture pequeno, não um benchmark de repositório inteiro nem de agente de longa duração. Ele não prevê taxas de acerto em outras tarefas. A OmniaKey vende acesso aos dois modelos; os preços acima são os de tabela oficiais da Anthropic. ## Quando avaliar o Fable Comece pelo Opus 5.5 em trabalho curto e bem especificado. Ele igualou o Fable nas 29 verificações de código, e a estimativa pela tarifa padrão do Fable ficou 4,7 vezes a do Opus. Trate o Fable 5.2 como o próximo candidato para raciocínio exigente ou laços longos de ferramentas, depois que o Opus com esforço maior falhar nos seus casos reais. Esse é o posicionamento da Anthropic; esta execução cobre apenas as quatro tarefas pequenas. Teste 10 a 20 falhas reais antes de trocar. O [anúncio do Fable 5.2](https://www.anthropic.com/claude-fable-and-mythos-5-2) da Anthropic acrescenta um dado relatado pelo fabricante: o Fable 5.2 em High marcou 45,3 % no FrontierCode 2.0 contra 45,5 % do Opus 5.5 em Max, com cerca de metade do custo por tarefa. O anúncio diz também que o Fable 5.2 em Xhigh chegou a 49,1 %, a maior pontuação entre os modelos publicados testados. Isso pareia Fable High com Opus Max, uma comparação diferente do nosso teste com o mesmo medium. Em um projeto real, compare o gasto de API com o tempo de nova tentativa e revisão por tarefa utilizável. Em trabalho pequeno que já passa, o Opus é a escolha padrão mais barata. Para usar qualquer um dos dois modelos no Claude Code, o [guia de configuração do Claude Code](https://omniakey.com/pt-BR/blog/claude-code-setup) tem a base URL e os ajustes de chave. Páginas de modelo: [Claude Fable 5.2](https://omniakey.com/pt-BR/claude-fable-5-2) e [Claude Opus 5.5](https://omniakey.com/pt-BR/claude-opus-5-5). ## Perguntas frequentes ### O Fable 5.2 vale o preço maior em relação ao Opus 5.5? Considere o Fable depois que o Opus com esforço maior falhar nos seus próprios casos, e confirme que o Fable os melhora; esta execução não dá veredito sobre tarefas difíceis. Nas nossas quatro tarefas pequenas os dois passaram em 29/29 verificações de código; a estimativa pela tarifa padrão do Fable foi $0,1457 contra $0,0310 do Opus. ### O Fable 5.2 e o Opus 5.5 passaram nos mesmos testes de código? Sim. Os dois passaram em 8/8 casos de uso, 14/14 de cursor e 7/7 de patch de arquivo. A resposta do livro-razão também foi correta nos dois, com uma diferença de formato: o Opus acrescentou um bloco de código JSON. ### Qual é mais barato para programar, Fable 5.2 ou Opus 5.5? Pelos preços de tabela padrão da Anthropic, o Opus 5.5: $4 de entrada e $20 de saída por milhão de tokens contra $8 e $40. Nossos tokens deixam a estimativa pela tarifa padrão do Fable em 4,7 vezes a do Opus: $0,1457 contra $0,0310 em quatro tarefas. ### O Fable 5.2 é mais rápido que o Opus 5.5? Nossa execução deixa isso em aberto. Os totais observados foram 27,8 s para o Fable e 43,6 s para o Opus, mas as respostas do Fable informaram velocidade standard e as do Opus, fast, e deixamos a velocidade sem definir. Compare os dois de novo com o mesmo ajuste de velocidade. ### Dá para usar os dois modelos no Claude Code pela OmniaKey? Sim. Nesta execução chamamos os dois IDs de modelo pela OmniaKey, e o [guia de configuração do Claude Code](https://omniakey.com/pt-BR/blog/claude-code-setup) mostra a base URL e a chave. Confira o nome do modelo no seu cliente depois de conectar. ## Fontes consultadas - Anthropic: [Visão geral do modelo Claude Fable 5.2](https://platform.claude.com/docs/en/models/fable-5-2/overview) - Anthropic: [Introducing Claude Fable 5.2 and Mythos 5.2](https://www.anthropic.com/claude-fable-and-mythos-5-2) - Anthropic: [Visão geral do modelo Claude Opus 5.5](https://platform.claude.com/docs/en/models/opus-5-5/overview) - Anthropic: [Visão geral de modelos](https://platform.claude.com/docs/en/models/overview) - Anthropic: [Preços](https://platform.claude.com/docs/en/about-claude/pricing) Todas verificadas em 12 de nov. de 2026.