Tornando o Fable mais barato que o Opus

Substituímos o Opus 4.8 pelo Fable 5, e a conta do Devin caiu.

Fable 5 custa o dobro por token do que Opus 4.8. Mas quando executamos ambos os modelos no FrontierCode 1.1 usando nossa nova arquitetura Fusion, o Fable custou menos. Sem surpresa, também pontuou mais alto. Este post explica por que e o que isso significa para o preço de trabalhos agentivos.

Introdução

Todos que executam agentes de codificação sabem que modelos mais fortes dão melhores resultados, mas você arca com o custo.

Quando apresentamos Devin Fusion, mostramos uma saída: manter um modelo frontier no comando, deixá-lo delegar para um sidekick mais barato e rápido, e você obtém desempenho nível frontier com 35% menos custo.

Mas uma vez que o modelo líder delega a maior parte do trabalho, o preço por token ainda domina a conta? Fable 5 custa 2x mais por token que Opus 4.8, então um agente liderado por Fable deveria custar mais. Para descobrir, executamos 3.000 sessões de avaliação no FrontierCode 1.1 em quatro configurações: Fable e Opus no assento de liderança, cada um com e sem o mesmo sidekick barato.

As execuções puras se comportam exatamente como a intuição sugere: Fable supera Opus (60.8 vs 55.4) e custa mais. Modelo melhor, conta maior.

Dado o mesmo sidekick, a ordem de custo se inverte: Fable + Sidekick custa menos que Opus + Sidekick ($1.86 vs. $2.04), enquanto pontua mais alto (60.7 vs. 54.6). Comparado com Fable puro, Fable + Sidekick reduz o custo em 54% enquanto mantém a pontuação quase inalterada.

O prêmio de 2x por token acaba sendo o número errado para se observar. O custo de um agente é dominado por quantas rodadas o modelo líder realiza, quanto contexto ele carrega e, acima de tudo, o que ele decide não fazer ele mesmo. A diferença se resume ao estilo de gerenciamento: Opus se comporta como um microgerente com um estagiário; Fable é um gerente com um engenheiro competente.

A configuração

Um rápido lembrete de como funciona a arquitetura de sidekick do Fusion. O agente líder é dono da sessão: ele conversa com o usuário, planeja, revisa o trabalho e faz commit. Ele também tem um subagente sidekick persistente para delegar tarefas. O líder escreve um resumo de transferência (handoff) em linguagem natural, e o subagente, alimentado por um modelo muito mais barato, executa-o em seu próprio contexto e reporta de volta. O líder revisa o resultado e decide o que acontece em seguida.

Para descobrir para onde vai o custo, fizemos duas coisas. Primeiro, analisamos cada chamada de LLM em todas as 3.000 sessões: qual modelo estava falando, qual ferramenta chamou, quantos tokens leu e escreveu, e quanto custou cada chamada. Segundo, selecionamos 40 tarefas para uma análise mais detalhada: aquelas em que o Fable era dramaticamente mais barato, aquelas em que o Opus era, e outra amostra aleatória do meio. Para cada uma, analisamos a execução liderada por Fable contra a execução liderada por Opus lado a lado, examinando as trajetórias e observando para onde os dólares iam.

Custo de um agente

Aqui está como o custo se divide entre o líder e o sidekick em nosso experimento:

Fable gasta mais em seu sidekick do que Opus — $0.27 a mais por execução. Mas gasta $0.45 a menos em si mesmo. O líder do Fable realiza 11.5 rodadas por execução contra 26.5 do Opus, escreve um terço dos tokens de saída (6.1k vs 19.0k) e consome um terço dos tokens de entrada. Fable é significativamente mais caro por token, mas vence no gerenciamento de contexto e na contagem de rodadas.

As economias de tokens do Fable surgem ao evitar trabalho diretamente. Interessantemente, em 81% das execuções lideradas por Fable, o líder nunca faz uma única edição de código. Para Opus, isso é verdade para apenas 24% das execuções. Em 13% das execuções lideradas por Fable, o líder nunca lê um arquivo do repositório ele mesmo.

Um microgerente com um estagiário vs um gerente com um engenheiro

Aqui está o que torna a diferença interessante: ambos os líderes delegam o mesmo número de vezes, cerca de 3 transferências por execução. Os logs por chamada desmentem a explicação fácil de que Fable simplesmente delega mais. O que difere é quando e o que eles delegam. A primeira transferência do Fable ocorre cedo. Opus frequentemente delega tarde, após um longo período de exploração solo e implementação; nesse ponto, as decisões de design já foram tomadas, os arquivos importantes estão em seu contexto e o trabalho caro já foi feito.

GIF

Uma execução típica liderada por Fable realiza algumas ações de reconhecimento no repositório, depois escreve um resumo de qualidade de especificação delegando todo o ciclo de implementação + teste + lint. Em seguida, um git show para revisar o diff e um commit.

Uma execução típica liderada por Opus passa por 20–45 rodadas de exploração solo, design e implementação, e uma transferência tardia para a parte mecânica.

Às vezes, a primeira ação do Fable em uma sessão é uma transferência. Na mesma tarefa, os dois líderes começaram assim:

A correção óbvia é fazer Opus delegar mais exploração, mas forçar esse comportamento tende a diminuir o desempenho. Saber quando uma investigação é segura para transferir e quando é algo que você precisa fazer você mesmo é, por si só, uma questão de julgamento. Um modelo coagido a delegar não adquire esse julgamento; ele apenas delega as coisas erradas.

O estilo de gerenciamento de cada modelo também se revela nos próprios resumos de transferência. Quando Opus delega implementação, ele dita, enquanto Fable escreve um documento de design:

A delegação não apenas move o custo; ela também altera a qualidade do trabalho. A tarefa de hashing acima é um exemplo claro. A especificação da tarefa exigia que uma função hash fosse O(1) no comprimento do ponteiro. Opus implementou manualmente e nunca escreveu esse requisito em lugar nenhum. Em algum lugar no caminho, esqueceu a restrição e enviou uma implementação de tempo linear, que pontuou 25. Em contraste, Fable delegou usando restrições de alto nível. Seu resumo dizia: "operator() must be O(1) in pointer length: NO full token scan." O sidekick implementou isso com sucesso para uma pontuação de 94.

Descobrimos que esse padrão se generaliza entre as tarefas. As transferências do Fable enumeravam restrições, casos extremos e uma definição de 'pronto', economizando seu próprio esforço enquanto permitiam que o sidekick completasse a implementação de forma barata e correta.

Após a transferência

A outra metade é o que o agente líder faz com o trabalho que retorna do sidekick. Ambos os líderes frequentemente executam a mesma verificação barata: duas ou três chamadas git diff/git show. Mas Opus não para por aí. Ele puxa os arquivos do sidekick de volta para seu próprio contexto 2x mais vezes e faz 4x mais edições corretivas a preços de líder. No caso extremo, ele reverteu o trabalho do sidekick e reescreveu manualmente:

A desconfiança do Opus também não aumenta a correção. Em algumas tarefas de avaliação, a única revisão de diff do Fable pegou bugs reais do sidekick e optou por outra transferência barata, em vez da reescrita em nível de líder que Opus tantas vezes utiliza.

Quando a delegação não ajuda

A estratégia de delegação do Fable não é universalmente útil; ela falha quando a tarefa não possui componentes delegáveis. Os seguintes tipos de tarefas pareciam difíceis de decompor:

• Tarefas curtas que incluem apenas algumas poucas rodadas do modelo líder, sem nada para delegar entre decidir e enviar.
• Tarefas de depuração serial onde a caça à causa raiz é uma longa cadeia de julgamentos. Aqui, o contexto acumulado é o trabalho.

Notavelmente, nessas tarefas, Fable mal delega. O mesmo julgamento que escreve um bom resumo também sabe quando não escrever um. Mas quando uma tarefa não oferece nada que valha a pena transferir, a delegação não tem alavancagem sobre o custo.

Em produção, o Fusion lida com isso em outra camada: a delegação controla qual trabalho permanece com o modelo caro, enquanto o roteamento decide se o modelo caro está envolvido ou não.

Conclusão

Começamos este experimento esperando medir o quanto o prêmio de 2x do Fable aumentaria o custo. Ficamos surpresos ao descobrir que a delegação eficaz do Fable na verdade diminuiu o custo geral. Ele especificava restrições e resultados em vez de detalhar a implementação, dava feedback em vez de fazer correções ele mesmo e, na maioria dos casos, nunca tocava no código. Esses são os hábitos de um bom gerente.

À medida que os modelos sidekick se tornam mais baratos e melhores, mais trabalho pode ser passado para eles. O que continuará valendo os preços de frontier é o julgamento: o que construir, o que restringir e quem deve escrever.