Como fazer a Fable ficar mais barata do que a Opus: usando reescrita via delegação para mudar a estrutura de custos dos agentes

Fable 像 um gerente de liderança experiente em engenharia: entrega cedo, especifica tudo com clareza e evita se meter na mão na massa; Opus, por outro lado, é como um microgerente com estagiário. Este artigo vem de uma postagem do Joon Lee X e decompõe a estrutura de custos por trás do desempenho, usando 3.000 rodadas de avaliação.
(Houve contexto: a Anthropic lançou o “Claude for Small Business”: mira a automação de tarefas de IA para pequenas e médias empresas — para você emitir faturas, calcular salários..)
(Complemento de contexto: a Anthropic exige validação KYC com nome real! Parte das funções do Claude precisará enviar documentos de identidade, aumentando a pressão regulatória)

Sumário

Toggle

• Introdução
• Configuração do experimento
• O custo de um agent
• Microgerente com estagiário vs gerente com engenheiro sênior
• Depois da passagem
• Quando delegar não ajuda
• Conclusão

Trocamos o Opus 4.8 por Fable 5, mas a conta do Devin caiu.

O custo por token do Fable 5 é o dobro do Opus 4.8. Mas quando rodamos simultaneamente esses dois modelos com a arquitetura Fusion, na FrontierCode 1.1, o Fable acaba sendo mais barato. E, como não seria diferente, a pontuação dele também é maior. Este artigo vai explicar por quê e o que isso significa para “precificar trabalho agentic”.

Introdução

Quem já rodou um agent que programa sabe: um modelo mais forte te dá resultados melhores, mas você precisa engolir o custo.

Quando lançamos o Devin Fusion, mostramos uma saída: coloque um modelo de ponta no comando e deixe ele delegar o trabalho para um ajudante mais barato e mais rápido. Assim, você obtém desempenho de nível avançado pagando um custo 35% menor.

Mas, quando o modelo no comando delega grande parte do trabalho, o preço por token dele ainda vai dominar toda a conta? Como o custo por token do Fable 5 é duas vezes o do Opus 4.8, um agent liderado pelo Fable deveria, em tese, ficar mais caro. Para descobrir a resposta, rodamos 3.000 rodadas de avaliação de sessões de trabalho na FrontierCode 1.1, cobrindo quatro configurações: Fable e Opus cada um sentando na cadeira de liderança, e cada um executando tanto com quanto sem o mesmo ajudante barato.

Em execuções puras (pure runs), o resultado foi exatamente o que a intuição sugere: a pontuação do Fable supera a do Opus (60,8 vs 55,4), e o custo também é maior. Melhor modelo, conta maior.

Foi com a ajuda do ajudante que a história ficou interessante.

Com o mesmo ajudante, a ordem do custo inverte: Fable + ajudante fica mais barato que Opus + ajudante (US$ 1,86 vs US$ 2,04), mas com pontuação maior (60,7 vs 54,6). Em comparação com um Fable puro, Fable + ajudante reduz o custo em 54%, enquanto a pontuação quase não muda.

| Configuração | | --- | Pontuação | Custo por execução (médio) | | --- | --- | | Fable 5(low)+ ajudante | 60.7 | US$ 1,86 | | Opus 4.8(médio)+ ajudante | 54.6 | US$ 2,04 | | Fable 5(low) | 60.8 | US$ 4,03 | | Opus 4.8(médio) | 55.4 | US$ 3,06 |

Os resultados mostram que “duas vezes mais caro por token” é um número que estava sendo interpretado errado. O custo de um agent depende, principalmente, de quantas rodadas o modelo no comando percorre, de quanto contexto ele carrega junto e, o mais importante: de quantas coisas ele decide “não” fazer. A diferença se resume ao estilo de gerenciamento: o Opus se comporta como um microgerente com estagiário; o Fable, como um gerente com um engenheiro competente.

Configuração do experimento

Vamos revisar rapidamente como funciona a arquitetura de ajudante do Fusion. O agent no comando tem o controle de toda a sessão de trabalho: ele conversa com o usuário, planeja, revisa o trabalho e envia (commit). Ele também tem um subagent residente, usado para delegar tarefas. O modelo no comando escreve um briefing de passagem em linguagem simples; então, um subagent guiado por um modelo muito mais barato executa dentro do seu próprio contexto, devolvendo os resultados. O modelo no comando revisa esses resultados e decide o que fazer a seguir.

Para descobrir para onde o custo escoa, fizemos duas coisas. Primeiro, analisamos todas as chamadas de LLM em cada uma das 3.000 sessões de trabalho: qual modelo estava falando, quais ferramentas ele chamou, quantos tokens ele leu e escreveu e quanto custou cada chamada. Segundo, escolhemos 40 tarefas para observação mais de perto: as que ficaram claramente mais baratas com Fable, as que ficaram claramente mais baratas com Opus e outra leva de amostras aleatórias do meio do espectro. Para cada uma, comparamos lado a lado a execução liderada por Fable e a liderada por Opus, inspecionamos as suas trilhas e observamos em que o dinheiro foi gasto.

O custo de um agent

A seguir, como o custo foi distribuído entre modelo no comando e ajudante no nosso experimento:

| | | --- | Modelo no comando $ | Ajudante $ | Custo total por execução $ | Rodadas por execução do modelo no comando | Tokens de entrada do modelo no comando (acumulado) | | --- | --- | --- | --- | --- | | Fable + ajudante | US$ 1,28 | US$ 0,58 | US$ 1,86 | 11,5 | 545k tok | | Opus + ajudante | US$ 1,73 | US$ 0,31 | US$ 2,04 | 26,5 | 1.679k tok |

O Fable gasta mais dinheiro com o ajudante do que o Opus — são US$ 0,27 a mais por execução. Mas ele gasta menos consigo mesmo: US$ 0,45 a menos. O Fable faz 11,5 rodadas por execução no comando, contra 26,5 do Opus; e os output tokens que ele gera são só um terço (6,1k vs 19,0k), enquanto os input tokens também ficam em um terço. O Fable custa mais por token, mas ganha em gerenciamento de contexto e em número de rodadas.

A economia de tokens do Fable vem de simplesmente evitar trabalho. O dado curioso: em 81% das execuções lideradas por Fable, o modelo no comando não editou nenhum código do começo ao fim. Para o Opus, apenas 24% das execuções são assim. E em 13% das execuções lideradas por Fable, o modelo no comando nem chega a ler diretamente nenhum arquivo de um repo.

Microgerente com estagiário vs gerente com engenheiro sênior

O que torna essa discrepância fascinante é que: as duas lideranças delegam em número semelhante — cerca de 3 passagens por execução. Logs de chamadas sequenciais derrubam a explicação simples de que “o Fable só delega mais”. A verdadeira diferença é “quando” elas delegam e “o que” delegam. A primeira passagem do Fable acontece cedo.

O Opus tende a delegar muito tarde: depois de uma longa fase de exploração e implementação sozinho; nessa altura, as decisões de design já foram tomadas, os arquivos importantes já estão no contexto — e o trabalho caro já foi feito.

Uma execução típica liderada pelo Fable começa com algumas ações de reconhecimento no repo; depois, ele escreve um briefing no nível de especificação e delega todo o ciclo “implementação + teste + lint” de uma vez. Em seguida, faz um git show para revisar o diff e então envia.

Uma execução típica liderada pelo Opus passa por 20 a 45 rodadas de exploração, design e implementação sozinho, e só depois ocorre uma passagem bem tardia, focada em delegar um fechamento mecânico.

Às vezes, o primeiro ato do Fable em uma sessão é delegar. No mesmo task, as aberturas dos dois modelos no comando são assim:

A correção óbvia seria forçar o Opus a delegar mais exploração. Mas impor esse comportamento costuma piorar o desempenho. Saber quando uma investigação pode ser delegada com segurança e quando você precisa fazer pessoalmente é, por si só, um tipo de julgamento. Um modelo forçado a delegar não adquire esse tipo de julgamento; ele só delega coisas que não deveriam ser delegadas.

O estilo de gerenciamento de cada modelo também aparece claramente no próprio briefing de passagem. Quando o Opus delega implementação, ele está dando ordens; quando o Fable delega, ele está escrevendo um documento de design:

Delegar não é apenas deslocar custos; isso também muda a qualidade do trabalho. A tarefa de hashing acima é um exemplo bem nítido. A especificação do task exige que uma função de hash tenha complexidade O(1) em termos do tamanho do ponteiro. O Opus implementou isso na mão, mas nunca colocou essa exigência em nenhum lugar. Em algum passo do processo, ele esqueceu o requisito e devolveu uma implementação de tempo linear, com pontuação 25. Em contraste, o Fable delegou usando restrições de alto nível: o briefing dizia “operator() deve ter O(1) no tamanho do ponteiro: não faça varredura completa de tokens”. O ajudante conseguiu implementá-la com sucesso e fez 94 pontos.

Descobrimos que esse padrão se aplica a diversos tasks. As passagens do Fable listam várias restrições, casos-limite e uma definição de “o que significa concluir” — economizando esforço para si e permitindo que o ajudante faça a implementação de forma barata e correta.

Depois da passagem

A outra metade é o que o agent no comando faz com os resultados devolvidos pelo ajudante. Os dois modelos no comando costumam rodar as mesmas checagens baratas: duas ou três chamadas de git diff / git show. Mas o Opus não para aí. Ele puxa de volta os arquivos gerados pelo ajudante para o próprio contexto com frequência 2 vezes maior e faz até 4 vezes mais edições corretivas cobradas ao preço do modelo no comando. No caso mais extremo, ele reverte completamente os resultados do ajudante, reescrevendo tudo à mão:

E a desconfiança do Opus não aumenta a corretude. Em algumas tarefas de avaliação, uma única revisão de diff do Fable pegou o bug real do ajudante e optou por fazer mais uma passagem barata, em vez de recorrer tão frequentemente à reescrita no nível do modelo no comando, como o Opus faz.

Quando delegar não ajuda

A estratégia de delegação do Fable não é universal; quando um task não tem partes delegáveis, ela falha. Estes tipos de tarefas parecem difíceis de decompor:

• tasks curtos com poucas rodadas do modelo no comando, sem nada entre “decidir” e “entregar” que possa ser delegado.
• tarefas de depuração sequencial, cujo rastreamento de causa raiz vira uma longa sequência de decisões. Aqui, os contextos acumulados em si já são o trabalho.

Vale notar que nessas tarefas, o Fable quase não delega. A mesma capacidade de fazer bons briefings também sabe quando não delegar. Mas quando um task não tem nada que valha a pena delegar, não há onde ganhar alavancagem com a delegação.

Em um ambiente de produção formal, o Fusion lida com isso em outro nível: a decisão de delegação determina quais trabalhos ficam com o modelo caro, e o roteamento (routing) determina se o modelo caro precisa mesmo ser envolvido.

Conclusão

Quando começamos este experimento, esperávamos quantificar quanto o ágio de 2 vezes do Fable faria o custo aumentar. Mas nos surpreendemos ao ver que a delegação eficaz do Fable, na prática, diminuiu o custo total. Ele indica restrições e resultados, em vez de escrever a implementação passo a passo; ele dá feedback, em vez de consertar com as próprias mãos; e, na maioria dos casos, nem chega a tocar no código. Isso tudo são hábitos de um bom gerente.

À medida que os modelos ajudantes ficam mais baratos e melhores, mais trabalho pode ser delegado a eles. E o que ainda vale pagar o preço de ponta no futuro será o julgamento: o que fazer, o que limitar e quem deve escrever.