LEASH repassa os passos difíceis a um agente mais forte e economiza 19,2% em relação ao Opus 5

A equipe por trás do LEASH propõe uma forma de não acionar o modelo caro em cada passo de um agente de computer use. Um modelo aberto mais fraco age por padrão, e o mais forte só entra quando o primeiro «tem dúvidas». Depois da passagem de controle, o agente forte continua sob supervisão. No OSWorld, a combinação com o Qwen3.5-35B-A3B atingiu 73,66% de tarefas concluídas, a um custo de $0,4117 por tarefa. O Claude Opus 5 operando o tempo todo marcou 72,90%. Na prática, o LEASH não fica atrás dele em qualidade e sai 19,2% mais barato.

O problema: tarefas longas e inferência cara

Agentes que controlam um computador resolvem tarefas de dezenas de passos: abrir um aplicativo, encontrar um arquivo, ajustar configurações, verificar o resultado. Um modelo de fronteira em cada passo faz a conta disparar rapidamente. Já um modelo pequeno com pesos abertos (open-weight), sozinho, muitas vezes não chega ao fim. A escalada de um modelo fraco para um forte promete um meio-termo, mas esbarra em uma pergunta: quando, exatamente, chamar o modelo forte? Para responder, é preciso um sinal que possa ser checado a cada passo quase sem custo.

Há ainda um segundo problema. O agente forte costuma ser acessado por uma API fechada, então não é possível olhar seus estados internos. Mesmo depois de receber o controle, ele pode se perder, e não há como monitorá-lo.

Como funcionam as três camadas do LEASH

O framework funciona sem treinamento e se apoia nos estados ocultos do modelo fraco. Os autores os comparam com estados de trajetórias anteriores, bem-sucedidas e fracassadas. Quanto mais o estado atual se parece com os das falhas, maior a estimativa de incerteza. O estimador reaproveita as ativações que o modelo já calcula ao gerar a ação. Não é preciso um forward pass adicional nem um monitor treinado à parte.

Esse sinal alimenta três camadas:

• incerteza inicial da tarefa: roteamento antecipado, que decide se o modelo forte é necessário desde o primeiro passo;
• incerteza passo a passo: escalada durante a execução, quando o agente fraco começa a «derrapar»;
• observador de sombra: continua acompanhando o agente forte, que é uma caixa-preta (black-box), mesmo depois da passagem de controle.

O nome LEASH («coleira») descreve bem a ideia: o agente forte é solto da coleira quando necessário, mas nunca fica totalmente solto depois disso.

O que o OSWorld mostrou

Os experimentos rodaram no OSWorld com quatro backbones modernos. Resultados segundo o texto do estudo:

• o LEASH é consistentemente melhor que os agentes fracos usados isoladamente;
• com a mesma proporção de escaladas, ele supera a escalada aleatória em 6,55–11,94 pontos;
• Qwen3.5-35B-A3B + LEASH: 73,66% de sucesso e $0,4117 por tarefa;
• Claude Opus 5 em modo always-on: 72,90%;
• economia de inferência em relação ao always-on: 19,2%.

A partir do último item, dá para estimar que uma execução completa no Opus 5 custa cerca de $0,51 por tarefa. Esse é um cálculo nosso; o estudo não traz esse número no resumo. Convém não inflar a diferença de 0,76 ponto de precisão em um único benchmark. Mas a direção é clara: um roteamento inteligente alcança o modelo principal em qualidade e ainda ganha no preço.

Onde isso é útil e qual é a pegadinha

Para equipes que constroem agentes sobre APIs de modelos de fronteira, o esquema parece prático. O trabalho principal fica com um modelo open-weight local ou barato, e a chamada cara é reservada para os trechos difíceis. Quanto mais longos os cenários, maior o efeito: a conta cresce com o número de passos, enquanto a escalada é acionada raramente.

Há também limitações. O método exige acesso aos estados ocultos do modelo fraco, então só serve para uma variante self-hosted ou open-weight. Também é preciso uma base de trajetórias anteriores com rótulos de sucesso e falha, embora não seja necessário treinar nada. A validação, por ora, se limita ao OSWorld, e não se sabe como o sinal se comportará em outras interfaces e em aplicativos fora do padrão. Antes de levar o LEASH para produção, vale montar seu próprio conjunto de trajetórias e verificar o quanto o sinal de incerteza coincide com as falhas reais nas suas tarefas.