Claude Fable 5.2 vs Opus 5.5: código e tarefas de agente

Nestas quatro tarefas pequenas de código e ferramentas, o prêmio do Fable 5.2 não se paga: Claude Fable 5.2 e 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.

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.

As páginas de modelo da Anthropic do Fable 5.2 e do Opus 5.5 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 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. Para uma análise de um modelo só, veja a análise do Opus 5.5.

Quanto custam as quatro tarefas

A página de preços oficial 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:

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 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 tem a base URL e os ajustes de chave. Páginas de modelo: Claude Fable 5.2 e 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 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
• Anthropic: Introducing Claude Fable 5.2 and Mythos 5.2
• Anthropic: Visão geral do modelo Claude Opus 5.5
• Anthropic: Visão geral de modelos
• Anthropic: Preços

Todas verificadas em 12 de nov. de 2026.