StopLoss interrompe execuções fadadas ao fracasso de agentes de código e economiza até 48% dos custos

Agentes de código insistem em refinar soluções que vão falhar na verificação de qualquer jeito, e cada passo extra é pago em tokens. Delegar essa supervisão a um modelo de fronteira esbarra no mesmo problema: o próprio observador sai caro. Os autores do StopLoss propõem um monitor externo pequeno, que lê os últimos passos do agente e interrompe a execução na hora certa. No SWE-bench Verified, ele reduz em 4,5% o custo por solução preservada, mantendo 99% das execuções bem-sucedidas. No subconjunto mais caro do SWE-bench Pro, a economia chega a 31%, e com o Qwen3-8B como modelo-base, a 48%.

Como o monitor funciona

O nome vem da ordem de stop loss da bolsa de valores: a posição é encerrada automaticamente quando o prejuízo se torna mais provável que o lucro. Aqui, a "posição" é a execução do agente. O monitor decide abortar quando a estimativa de risco de falha ultrapassa um limiar.

O treinamento é feito com trajetórias já concluídas e veredictos do verificador. O resultado final da execução, sucesso ou falha, é atribuído a janelas locais anteriores: as últimas chamadas de ferramentas. Assim, obtém-se um conjunto de treino sem rotulagem manual. Um modelo de linguagem com fine-tuning avalia cada janela em uma única passagem direta, sem raciocínio longo e sem gerar texto. O limiar é calibrado com execuções bem-sucedidas, para não interromper as que chegariam a uma solução. O agente executor permanece intocado: o monitor se conecta por fora e não exige mudanças no agente nem nos prompts dele.

O modelo foi treinado com trajetórias da família GPT do SWE-rebench. A avaliação usou o SWE-bench Verified e um subconjunto do SWE-bench Pro, com GPT e Claude atuando como agentes executores. Como base de comparação, os autores usaram seis juízes LLM de uso geral, que receberam exatamente as mesmas janelas.

O que as medições mostraram

Nos juízes de uso geral, a previsão de falha na primeira verificação fica próxima do acaso. O treinamento com base nos resultados eleva essa previsão a um sinal útil. Além disso, cada verificação custa de uma a duas ordens de grandeza menos que a de qualquer um dos juízes testados. É isso que faz a interrupção antecipada compensar do ponto de vista econômico: se a própria verificação é cara, ela consome o ganho das execuções interrompidas.

• Custo por solução preservada no Verified: −4,5% em relação a rodar todas as tarefas até o fim, mantendo 99% das execuções bem-sucedidas.
• No subconjunto Pro: até −31%, e com o Qwen3-8B como base, até −48%.
• Custo da verificação: de uma a duas ordens de grandeza menor que o de qualquer um dos seis juízes.
• Nas quatro configurações, o custo por solução preservada do StopLoss é menor que o de qualquer política baseada em juízes.
• O agente executor não muda, e o limiar é ajustado com base nas execuções bem-sucedidas.

A diferença entre os benchmarks é reveladora. No Verified, as tarefas são mais baratas e há pouco a economizar: 4,5% é um número modesto. No Pro, onde uma execução fracassada custa bem mais, interromper as falhas compensa mais. O efeito cresce junto com o preço do erro.

Onde isso é útil na prática

A métrica "custo por solução preservada" é mais útil que o custo da execução. Ela leva em conta tanto os tokens economizados quanto os sucessos perdidos por interrupções indevidas. Equipes que rodam agentes em larga escala, por exemplo na correção automática de bugs em CI, devem acompanhar justamente essa métrica.

A abordagem não exige acesso aos componentes internos do agente executor e se apoia em dados que a maioria das equipes já tem: logs de trajetórias e resultados de testes. Um monitor pequeno pode receber fine-tuning com as execuções da própria equipe, e o limiar pode ser ajustado para uma fatia aceitável de sucessos perdidos. No estudo, essa fatia é de 1% no Verified.

Há limitações. Os resultados vêm de dois benchmarks de engenharia de software, e as trajetórias de treino pertencem à família GPT. O artigo não mostra como o monitor se comportaria em cargas de outros domínios nem em outros arcabouços de agentes. Mesmo assim, a ideia é clara: se a falha pode ser identificada a baixo custo, não é necessário esperar o fim da execução.