IronBee Express cria browser agent com custo de US$ 0,0042

Um agente de browser sem LLM no loop

A IronBee detalhou a construção do IronBee Express, um agente de navegador para automação e testes que executa um checkout de nove ações em 6,7 segundos, custando US$ 0,00054 de modelo por execução. A peça central é o Jev, um modelo da TypeSafe que não gera texto e não olha screenshots: ele responde perguntas tipadas, escolhendo entre opções enviadas e devolvendo probabilidades e confiança. Como não há geração de tokens, uma decisão leva cerca de 300 ms, o input custa US$ 0,042 por milhão de tokens e a saída é gratuita. Como o modelo só pode devolver uma chave da lista oferecida, o código valida a resposta contra ela - a saída nunca vira seletor, coordenada ou script.

Cada passo envia todas as perguntas de uma vez (operação, alvo do clique, campo de digitação, valor) em uma única chamada, mesmo sabendo que só uma operação vencerá. Esse design teve efeitos colaterais: perguntas independentes fizeram um número de cartão ir parar num campo de PIN, e a digitação que substitui o conteúdo do campo juntou endereços em três partes sobrepostas, deixando só o CEP. As correções re-consultam o modelo nomeando o campo ou oferecendo opções como REPLACE e JOIN, cada uma descrevendo o texto final do campo. A opção KEEP, escolhida repetidamente sem proveito, foi removida.

Latência e custo medidos

Cerca de 215 ms de cada decisão de 300 ms é a viagem de ida e volta da Turquia até os servidores do Jev em Oregon. Como o fetch do Node fecha conexões ociosas após 4 segundos, muitas decisões pagavam um handshake extra de ~450 ms. Mover todas as chamadas para um pool HTTP/2 com conexão mantida aberta por um minuto, aberta enquanto a primeira página carrega, derrubou a primeira decisão de ~1.000 ms para ~300 ms. Uma execução no Google Flights caiu de 26,1 s para ~8 s em três etapas: trocar o Claude Code CLI (3 a 4,8 s por valor) por valores entre aspas no objetivo, evitar WAITs inúteis e manter a conexão quente.

Os custos foram medidos com um proxy que registra os tokens: um checkout repetido fez três chamadas de ~4.300 tokens cada, totalizando US$ 0,00054. Um exemplo explorado de 20 ações, com o Jev decidindo cada passo, gerou 23 chamadas e 99.144 tokens - US$ 0,0042 pela execução inteira, concluída em 12,1 s.

Orientação pelas opções e o que o modelo vê

Regras gerais no prompt pioraram o desempenho (Flights mediano de 8,11 s para 9,66 s). O que funcionou foi embutir informação na própria opção: após dois WAITs que nada mudaram, o texto da opção avisa que nada está carregando; cliques que não alteraram nada saem da lista até a página mudar; descrições de valores (como "o número do cartão") permitem casar segredos com campos de rótulo diferente. A leitura da equipe é que o Jev pesa cada opção pelo próprio texto.

A maior parte dos "erros do Jev" era falta de contexto: doze botões idênticos de "Add to cart" precisam do texto do produto ao redor; a data atual foi adicionada ao estado após falhas no BBC Weather; a janela de histórico subiu de 10 para 30 ações; páginas anteriores ganharam resumos de 220 caracteres; e progresso passou a significar mudança real de conteúdo, com ações aguardando as requisições que dispararam.

Julgamento sem asserções escritas à mão

A primeira versão tinha uma linguagem de checagens que a equipe deletou. Agora o Jev julga em dois momentos: ao DONE, lendo a página, todas as respostas de API com corpo e logs, apontando o id da evidência que justifica o veredito; e numa revisão final, onde código simples coleta anomalias (4xx, erros de console, spans lentos) e o Jev classifica cada grupo como irrelevante, menor, maior ou crítico. Foi assim que o Express detectou um pedido que a página dizia "placed", mas a API marcava como FAILED por estoque insuficiente - sem ninguém ter escrito uma asserção. O julgamento ainda erra em casos conhecidos, como um DONE aprovado com p=0,99 no Airbnb sem nova busca, e um pedido com PAYMENT_FAILED aprovado antes do resultado do pagamento chegar.

Replay, recuperação e o papel do LLM

Execuções bem-sucedidas viram gravações que são repetidas sem decisões do Jev (checkout em 1,6–1,9 s). A gravação detecta quando ficou obsoleta: controle ausente, candidatos ambíguos (resolvidos com uma pergunta estreita same_control, exigindo 80% de confiança) ou objetivo não alcançado. Em 130 replays contra um loja local controlada, a taxa inicial foi de 110 acertos; após deixar de pedir improvisos ao modelo - esperando APIs lentas em vez de julgá-las - chegou a 130 de 130. Como juiz, o Jev acertou 110 de 110. A regra central: um replay se recupera quando o site mudou, nunca quando a aplicação quebrou.

Quando o Jev trava, um LLM assume como agente próprio, com screenshot, árvore de acessibilidade e HTML, agindo pelo mesmo portão de ações, por até 3 tomadas de controle de 15 chamadas cada. No Google Maps transit, só o Jev passava 0 de 4 execuções; com um takeover por execução, 4 de 4 passaram, em 42 a 63 s. O LLM também escreve valores que ninguém forneceu (evitado ao máximo, pois um modelo hospedado custa ~1 s por chamada e o CLI do Claude Code ~6 s) e explica falhas em uma a três frases, sem alterar o veredito.

O projeto está no GitHub (ironbee-ai/ironbee-express) sob Elastic License 2.0, exigindo Node.js 22, Chrome e chave da API TypeSafe. Os números vêm de execuções próprias entre 21 de setembro e 1 de outubro de 2026.