Anthropic lança Fable 5.2: desempenho próximo ao Opus por quase metade do custo por tarefa

Um agente de IA pode passar horas corrigindo um bug, executando testes e reescrevendo o próprio patch. Para a equipe, a questão logo se torna financeira: quanto custa produzir uma alteração que um desenvolvedor realmente aceite? A Anthropic lançou o Fable 5.2 e afirmou que, em um teste de programação, o modelo se aproximou do resultado do Opus 5.5 com quase metade do custo por tarefa. É um motivo para testar as configurações do seu agente, principalmente se os gastos com raciocínio prolongado já pesam no orçamento.

De onde vem a economia

No FrontierCode 2.0, o Fable 5.2 com a configuração High obteve 45,3%, enquanto o Opus 5.5 com Max alcançou 45,5%. O teste avalia se os mantenedores de repositórios de código aberto aceitariam as alterações propostas pelo modelo. Segundo a empresa, o custo por tarefa do Fable nessa comparação foi aproximadamente a metade. A API do novo modelo custa $8 por milhão de tokens de entrada e $40 por milhão de tokens de saída. Os números vêm do anúncio da Anthropic.

Aqui, vale distinguir o preço de um token do custo de um resultado. O primeiro aparece na tabela de preços. O segundo depende de quantas vezes o agente tenta corrigir o erro, de quanto contexto lê e de quanto trabalho deixa para uma pessoa. Uma execução mais barata pode acabar custando mais se, depois dela, um engenheiro passar meio dia restaurando o funcionamento que foi comprometido.

O nível de raciocínio também passa a fazer parte da escolha. Comparar modelos apenas nas configurações máximas é conveniente para uma tabela de recordes. Para um produto, é mais útil encontrar uma configuração que entregue qualidade aceitável dentro de um orçamento viável. O resultado da Anthropic mostra por que esse experimento faz sentido, embora não seja possível prometer antecipadamente a mesma economia a uma equipe específica.

Como testar com um bug conhecido

Imagine um serviço de assinaturas: após uma solicitação ser repetida, o cliente às vezes recebe duas cobranças idênticas. O agente precisa investigar o tratamento das novas tentativas, corrigir o código e adicionar uma verificação. Uma explicação bem escrita não resolve nada se as cobranças duplicadas continuarem aparecendo.

Para comparar os modelos, prepare o mesmo snapshot do repositório, a mesma descrição do erro e as mesmas ferramentas disponíveis. Defina limites iguais de tempo e gasto. Depois, verifique se o patch elimina o problema original, se os testes existentes passam e se o comportamento muda em cenários relacionados. É útil que o revisor avalie primeiro as alterações sem saber o nome do modelo: isso reduz a tentação de perdoar um erro do favorito.

Um único bug não basta. Reúna um pequeno conjunto de tarefas já resolvidas: corrigir uma regressão, ampliar uma API, alterar um esquema de dados e identificar a causa de uma consulta lenta. Para cada uma, registre o custo das execuções, o número de novas tentativas e o tempo de revisão humana. A principal métrica é o gasto por correção aceita. A taxa de sucesso das tarefas e o tempo de execução devem ser acompanhados em paralelo; caso contrário, a economia pode esconder uma perda de qualidade ou velocidade.

Para um gerente de produto, essa é uma forma de testar uma hipótese concreta: é possível atender a mais solicitações complexas com o mesmo orçamento? Para um fundador, é uma oportunidade de avaliar o custo de uma funcionalidade antes de prometer aos usuários um assistente ilimitado.

Até onde vão as conclusões do anúncio

A comparação publicada tem uma limitação importante: os resultados foram apresentados pelo próprio fornecedor. Seus repositórios, ferramentas, instruções e critérios de aceitação podem ser bastante diferentes dos usados no teste. A diferença entre 45,3% e 45,5% também não comprova, por si só, que os modelos sejam equivalentes em todas as tarefas de engenharia.

Por isso, seria prematuro trocar imediatamente o modelo em todo o produto. Um primeiro passo sensato é executar as tarefas salvas e, depois, destinar à nova configuração uma pequena parcela do trabalho real, com a revisão habitual. Se a vantagem se confirmar, o uso pode ser ampliado gradualmente, mantendo a possibilidade de voltar à configuração anterior.

O valor prático do lançamento está em uma promessa verificável de reduzir o custo do trabalho complexo. A equipe precisa de uma resposta própria para uma pergunta simples: quanto dinheiro e tempo são necessários para uma correção que passa pela revisão e é incorporada ao código principal?