Modelos de decisão, também chamados de modelos System One,1 escolhem a próxima ação do agente em uma única passagem em vez de gerar texto token por token. Para ver se eles podem tornar a automação de navegador mais barata do que LLMs, executamos três modelos de decisão e dois LLMs, Gemini 3.8 Flash e GPT-6 Astra, nas mesmas 50 tarefas de navegador, em 250 tentativas no total.
Taxas de sucesso dos modelos de decisão
Kev-9B concluiu 20 das 50 tarefas e o Jev 1.13 concluiu 17. A Laya não concluiu nenhuma em nossa integração, que rodou acima dos limites de entrada divulgados.
Em seguida, executamos as mesmas 50 tarefas com um LLM escolhendo cada ação. O GPT-6 Astra concluiu 47 e o Gemini 3.8 Flash 42, ambos na configuração de baixo esforço de raciocínio de sua API. O Astra também concluiu todas as tarefas que Jev ou Kev concluíram.
Veja 10 tarefas de exemplo e o resultado de cada modelo em Hugging Face, e como executamos o benchmark em metodologia.
Modelos de decisão versus LLMs
A maioria dos LLMs escreve sua resposta um token por vez, e cada token custa computação e tempo. Na maioria das etapas do navegador, o agente apenas escolhe uma operação e um controle na página.
Um modelo de decisão lê a página e as opções, pontua cada opção e retorna a mais provável. Ele retorna uma probabilidade para cada opção em vez de texto gerado, portanto, uma etapa não precisa de uma saída longa. Se os modelos de decisão se tornarem precisos o suficiente, a mesma automação poderá rodar muito mais rápido e por uma fração do custo de um LLM.
Os três modelos de decisão não conseguem escrever texto, portanto, um modelo de texto separado, Mercury 2.5,2 escreve os valores digitados nos campos de formulário. Nós o chamamos de assistente de texto, e ele estava disponível para todos os modelos.
Executamos todos os cinco modelos no runtime open-source jev-ultrafast do browser-use,3 que foi criado para o Jev. Os três modelos de decisão são Jev 1.13 da TypeSafe,4 Kev-9B5 e Laya typed-decisions.6 O GPT-6 Astra serve como referência de LLM de ponta e o Gemini 3.8 Flash como um de baixo custo.
Cinco modelos na mesma tarefa
Na Wikipedia, todos os modelos, exceto a Laya, digitaram na caixa de busca, o assistente de texto escreveu “Ada Lovelace” e o modelo escolheu a sugestão correta. O Jev chegou ao artigo em 8,1 segundos, o Gemini em 11.0, o Astra em 18.9 e o Kev em 43.8. A Laya declarou a tarefa concluída na página principal sem executar nenhuma ação.
A tarefa de filtro exige dois menus suspensos e um botão de busca. Jev, Gemini e Astra seguiram os mesmos quatro passos e terminaram em 4.6, 10.7 e 20,3 segundos. A Laya clicou no logo do site e declarou a tarefa concluída. O Kev falhou nesta tarefa no benchmark e, na demonstração, ainda estava clicando depois de 11 minutos, por isso foi deixado de fora deste clipe.
As legendas mostram a operação e o alvo escolhidos por cada modelo e, no caso dos modelos de decisão, a probabilidade dessa operação. Os clipes vêm de uma execução de demonstração separada em velocidade 1×, não do benchmark pontuado, e cada página final foi verificada com o avaliador do benchmark.
Resultados dos modelos de decisão
As tarefas que Jev e Kev concluíram incluem buscas na Wikipedia, uma seleção de menu suspenso, ordenação de produtos e uma aba de produto. Ambos concluíram as duas tarefas da Wikipedia e a tarefa de menu suspenso do Web Scraper, assim como os dois LLMs.
Cada tarefa do Books to Scrape exigia passar de uma lista de categorias para uma página de produto. O Jev não concluiu nenhuma das seis e o Kev concluiu três.
Together, Jev e Kev concluíram 26 tarefas distintas.
Padrões de falha
- Jev declarou a tarefa bloqueada em 24 de suas 33 falhas, 16 vezes antes de executar qualquer ação.
- Kev tomou uma mediana de 9.5 ações nas tarefas com falha, contra 3 nas tarefas que concluiu. Dez tentativas atingiram o limite de ações ou de chamadas de decisão, e outras cinco foram interrompidas depois que três ações seguidas deixaram a página inalterada.
- Laya declarou a tarefa concluída antes de atingir a meta em 33 tentativas, 17 vezes antes de executar qualquer ação. Outras oito tentativas foram interrompidas depois de três ações inalteradas. Nove tentativas falharam quando nosso conector, o código que encaminha cada solicitação à Laya, rejeitou uma pergunta ou opção mais longa que os limites de entrada da Laya.
Por que a Laya pontuou 0/50
Testamos duas alterações na integração da Laya. Em 24 solicitações de teste, enviar cada pergunta separadamente em vez de em um único lote produziu saídas idênticas. Com uma pergunta separada de sim/não para “a meta já foi alcançada?”, a Laya passou em no máximo 3 de 12 cenários que exigiam primeiro a ação correta e depois um sinal de concluído.
Em todos os 12 cenários, a Laya pontuou a página concluída mais alto do que a não concluída, mas as faixas de pontuação se sobrepuseram de um cenário para o outro. Oito de seus 11 alvos errados repetiram o valor ou a página que já estava na tela.
A versão da Laya que usamos foi treinada para tarefas de julgamento, como tickets de suporte, faturas e revisão de rastreamento de agentes, não para navegação de navegador.6 Após o fine-tuning em tarefas de navegador, a Laya concluiu no máximo 3 de 50, contra 0 da Laya original no mesmo dia (p = 0.25).
Resultados do LLM
GPT-6 Astra falhou em 3 tarefas. Ele marcou uma tarefa de categoria do ScrapeMe como bloqueada. Em um formulário de calculadora, continuou digitando no mesmo campo e foi interrompido depois que três ações deixaram a página inalterada. A terceira terminou em um erro do assistente de texto.
Gemini 3.8 Flash falhou em 8. Quatro dessas chegaram à página correta, mas não concluíram. Duas foram interrompidas pela nossa salvaguarda de custo quando a OpenRouter não informou uma taxa, uma atingiu o limite de ações e uma terminou em um erro do assistente de texto.
Ambos os LLMs falharam na tarefa de formulário T02. Ambos preencheram e enviaram o formulário, e as duas tentativas terminaram quando o assistente de texto não retornou nenhum valor válido.
Sucesso por site
Jev e Kev foram fortes em sites diferentes. O Kev concluiu 6 de 8 tarefas do Web Scraper e 3 de 6 no Books to Scrape, onde o Jev não concluiu nenhuma. O Jev se saiu melhor no Quotes to Scrape (4 de 8) e no Scrape This Site (3 de 6).
O TestPages tinha todas as quatro tarefas de formulário e o menor número de conclusões. O Kev concluiu uma e o Jev nenhuma. Para comparação, o GPT-6 Astra concluiu todas as tarefas em sete dos nove sites e duas das quatro tarefas de formulário.
Cada site tem de duas a oito tarefas, portanto essas contagens se aplicam apenas a este conjunto de tarefas.
Velocidade e sucesso
O Jev foi o mais rápido, com uma mediana de 4,2 segundos por tentativa, mas parte dessa velocidade vem de parar cedo. Dezesseis de suas falhas terminaram antes de qualquer ação. Nas 17 tarefas que o Jev concluiu, ele teve uma média de 5,4 segundos contra 12.5 do GPT-6 Astra nas mesmas tarefas.
Gemini (12,7 segundos, 84%) e Astra (17,4 segundos, 94%) foram rápidos e precisos. A Laya levou 15,1 segundos por tentativa e não concluiu nenhuma tarefa.
O Kev levou uma mediana de 38,3 segundos por tentativa, por dois motivos. Cada decisão do Kev levou uma mediana de 3,7 segundos de tempo de GPU, contra cerca de 1 segundo para uma chamada completa de API do Jev. Executamos o Kev com o código de referência do produtor em precisão total de 32 bits, e dois pacotes opcionais de kernel que aceleram seu modelo base não estavam instalados, então o modelo voltou a kernels de referência mais lentos. A rede adicionou cerca de meio segundo.
O Kev também tomou muito mais decisões, uma média de 26 por tentativa contra cerca de 4 do Jev, e 90% delas ocorreram em tentativas com falha. Não testamos uma configuração de GPU mais rápida.
Custo
Astra, Gemini e Jev usaram cada um de 3.150 a 3.470 tokens de entrada por decisão. Portanto, o preço por token, e não a quantidade lida, define a diferença de custo. O preço de entrada do Astra é cerca de 240 vezes o do Jev.78
No raciocínio baixo, o Astra produziu 6.599 tokens de saída em 307 decisões, contra 968.376 tokens de entrada. O preço de saída do Jev é $0.
Com o preço de entrada do Jev, os 968.376 tokens de entrada das decisões do Astra teriam custado cerca de $0,04 em vez de $9.68. Um modelo de decisão que igualasse a taxa de sucesso do Astra ao preço do Jev executaria a mesma automação por uma pequena fração do custo de um LLM.
O Kev e a Laya não tiveram taxa de API de decisão. O aluguel da A100 para o Kev custou cerca de $5,31 (3.32 horas a $1,60 por hora), incluindo o tempo de configuração fora das execuções pontuadas. Não estimamos um custo para o Mac que executou a Laya. Uma taxa do Jev e duas taxas do Gemini não foram registradas e estão faltando na tabela.
Treinamento de modelos de decisão
Fizemos fine-tuning do Kev-9B e da Laya com as decisões que o GLM-5.3-Flash, o modelo de rotulação, tomou em tarefas de navegador de oito sites fora do benchmark. Em seguida, executamos as 50 tarefas novamente. Cada modelo fine-tuned é comparado com sua versão original, executada no mesmo dia e no mesmo hardware.
O Kev fine-tuned e as duas versões da Laya estão no Hugging Face.
O p vem de um teste pareado nas mesmas 50 tarefas (McNemar exato), e p abaixo de 0.05 conta como significativo. O Kev original concluiu 21 tarefas naquele dia, uma a mais do que no benchmark principal. Um dos 12 ganhos do Kev, C02, foi um timeout do navegador na execução original, e não uma falha do modelo. Sem ele, o Kev ganhou 11 tarefas e perdeu 1 (p = 0.006).
- O Kev fine-tuned ganhou tarefas em seis dos nove sites, três em cada um de Quotes to Scrape e Scrape This Site. Seus resultados no Web Scraper, na Wikipedia e nos formulários do TestPages não mudaram.
- O Kev fine-tuned terminou 5 tentativas bloqueadas contra 12 e atingiu o limite de ações 6 vezes contra 11. Declarou uma tarefa incompleta como concluída 7 vezes, contra 4.
- Em 41 tarefas dos sites de treinamento que foram mantidas fora do treinamento, o Kev concluiu 21 contra 13 antes. Em 101 decisões individuais de 19 dessas tarefas, escolheu a operação do modelo de rotulação 94% das vezes, contra 62% antes.
- O primeiro fine-tune da Laya escolheu a operação do modelo de rotulação em 75% das 88 decisões que conseguiu ler, contra 19% da Laya original. Ele declarou uma tarefa concluída em uma página que ainda precisava de uma ação 2 vezes em vez de 53.
- No benchmark, o primeiro fine-tune da Laya declarou uma tarefa incompleta como concluída 36 vezes, uma vez antes de executar qualquer ação. A Laya original fez isso 32 vezes, 17 delas antes de qualquer ação.
Por que a Laya permaneceu perto de zero
O ganho de decisão única do primeiro fine-tune é principalmente rolagem. Ela correspondeu a 33 das 47 decisões de rolar para baixo, onde a Laya original correspondeu a 2 e respondeu concluído em 38. O segundo fine-tune correspondeu a 25 das 88 decisões e clicou em 33 das 47 rolagens. Ainda assim, concluiu 3 tarefas do benchmark, mais do que qualquer outra versão da Laya.
O teste de decisão única usa apenas páginas das execuções bem-sucedidas do modelo de rotulação. No benchmark, 26 das 36 declarações incorretas de conclusão do primeiro fine-tune vieram depois de uma ou duas ações, em páginas que a própria Laya alcançou.
Nosso conector rejeita uma solicitação quando qualquer pergunta ou opção excede os limites de entrada da Laya. Em quatro dos oito sites de treinamento, menos da metade das páginas registradas cabia. No total, 292 dos 606 registros de treinamento cabiam. O primeiro fine-tune verificou o tamanho em uma solicitação com apenas as perguntas que cada etapa precisa, portanto também aprendeu com páginas que a Laya nunca recebe em uma execução ao vivo.
O segundo fine-tune manteve apenas aqueles 292 registros e adicionou 102 das execuções da própria Laya. Quando a Laya declarou uma tarefa de treinamento concluída ou bloqueada, ou atingiu 10 ações, o GLM-5.3-Flash assumiu na mesma página. Suas próximas decisões se tornaram rótulos se a execução passasse. Em 14 dos novos registros, a Laya havia declarado a tarefa concluída e o GLM clicou em vez disso.
Antes desta rodada, definimos uma regra para parar se uma rodada adicionasse menos de 3 tarefas concluídas do conjunto de validação em relação à anterior. O conjunto de validação tem 20 novas tarefas do Automation Exercise que o GLM concluiu em páginas que cabem todas na entrada da Laya. A Laya original, o primeiro fine-tune e uma versão treinada apenas nos 292 registros legíveis não concluíram nenhuma. O segundo fine-tune concluiu uma, então paramos.
A Laya recebeu uma segunda rodada com dados de suas próprias execuções, e o Kev não. As configurações do Kev foram fixadas antes de qualquer execução de benchmark, e seu ganho já era significativo. A segunda rodada da Laya treinou em 394 registros contra 606 do Kev, e não procuramos mais sites com páginas curtas. O resultado não mostra se mais dados ajudariam a Laya.
Metodologia
Todos os cinco modelos usaram o mesmo runtime de navegador jev-ultrafast. A cada etapa, ele transformava a página atual em texto de página mais uma lista numerada de controles visíveis. O modelo escolhia uma operação, como clicar, digitar, selecionar, concluir ou bloquear, e um alvo dessa lista. O runtime executava a ação e relia a página.
Os três modelos de decisão classificam as opções fornecidas e não conseguem escrever texto. Quando qualquer modelo escolhia digitar, o assistente de texto escrevia o valor no campo do formulário.
Cada tentativa começava em uma nova sessão do navegador. Todos os cinco modelos rodaram no mesmo dia com as mesmas tarefas, runtime e avaliação.
Modelos
Raciocínio baixo é uma configuração de esforço definida pelo provedor. As 307 decisões do Astra incluíram 791 tokens de raciocínio reportados.
Dataset
As 50 tarefas cobrem nove sites: oito sites de prática criados para raspagem e testes, mais a Wikipedia. As tarefas incluem navegação em catálogo, busca, ordenação, paginação, opções de produto, formulários e buscas de artigos. Cada tarefa começa em uma URL fixa e declara o estado final em uma frase, por exemplo “Mudar para Ficção Científica, encontrar Dune (Dune #1), abrir os detalhes do produto e parar.”
Antes da execução dos modelos, uma execução roteirizada concluiu todas as 50 tarefas usando apenas as ações suportadas pelo runtime. Cada tarefa é solucionável sem senhas, CAPTCHAs ou a tecla Enter.
Tarefas de exemplo
Dez das 50 tarefas estão publicadas no Hugging Face com as instruções, a URL inicial, as condições de aprovação e o resultado de cada modelo. As outras 40 são retidas para execuções posteriores.
Avaliação
Uma tarefa passava quando o modelo a declarava concluída dentro dos limites e uma verificação separada da página final confirmava todas as condições: uma URL final aceita, os fatos da tarefa visíveis na página, mais de 100 caracteres de texto da página e uma página totalmente carregada.
Cada tentativa tinha 900 segundos, 60 ações de navegador e 120 chamadas de decisão. Erros de API contavam como falhas. O tempo é medido desde a primeira página carregada até a verificação final.
Os modelos não podiam ver o status de carregamento da página que a verificação exigia. O Jev na B05 e o Gemini na M04 chegaram ao conteúdo correto, mas falharam apenas nessa verificação e contam como falhas.
Custo
O gasto de API é composto pelas chamadas de decisão mais o assistente de texto, para todas as 50 tentativas por modelo. A OpenRouter informou as taxas do GPT-6 Astra, do Gemini e do Mercury. O custo do Jev são seus tokens reportados ao preço de tabela em 22 de setembro de 2026: $0,042 por milhão de tokens de entrada e sem cobrança pela saída.4 A estimativa do Kev não foi conciliada com uma fatura.
Fine-tuning
As 327 tarefas, 286 para treinamento e 41 de validação, vêm de oito sites que não estão no benchmark, incluindo Demo Web Shop, Automation Exercise e Project Gutenberg. Cada tarefa foi verificada em um navegador: sua página inicial falha no avaliador e sua página-alvo passa.
O GLM-5.3-Flash, um modelo de pesos abertos sob a licença MIT,9 tentou 300 das tarefas no runtime do benchmark em baixo raciocínio. Erros do provedor o impediram de fazer as outras 27. Não usamos o GPT-6 Astra nem o Gemini para isso, porque os termos da OpenAI e do Google proíbem usar sua saída para construir modelos concorrentes.1011
As 184 execuções de treinamento bem-sucedidas geraram 606 registros de decisão. Uma execução contava como bem-sucedida quando o avaliador a aprovava. Em todas as tarefas, 11 execuções adicionais contaram porque chegaram à página de produto correta por meio da busca do site e falharam apenas na verificação exata de URL.
O teste de decisão única reproduz 103 decisões gravadas de 19 tarefas de validação e conta com que frequência um modelo escolhe a operação do modelo de rotulação. O Kev conseguiu ler 101 delas. A Laya conseguiu ler 88 quando recebeu apenas as perguntas que cada etapa precisa, e 34 na solicitação completa que o benchmark envia. Nessas 34, a Laya original concordou 29% das vezes, o primeiro fine-tune 71% e o segundo 41%.
Ambos os modelos partiram dos pesos originais que avaliamos e usaram as receitas de treinamento de seus produtores com os limites de entrada do benchmark. O Kev também treinou por duas épocas em vez de uma, sem os registros de repetição do produtor. Cada execução de treinamento levou menos de 20 minutos em uma H100 GPU.
O par do Kev e o primeiro par da Laya rodaram em uma H100 alugada na França, com Chrome no Linux. O segundo par da Laya rodou no Mac do benchmark principal. Cada par usou as 50 tarefas, o runtime, os limites e o avaliador do benchmark principal, com uma tentativa por tarefa.
Limitações
Cada modelo tentou cada tarefa uma vez, portanto os resultados não estimam a confiabilidade. O Kev concluiu 20 tarefas e o Jev 17; uma execução não pode dizer se essa diferença se manteria.
As 50 tarefas vêm de nove sites, e as tarefas do mesmo site compartilham layouts de página. Os modelos rodaram um após o outro no mesmo dia, e os sites ativos podem mudar entre as execuções.
O formato de etapa, uma lista de operações mais listas de alvos, foi criado primeiro para o Jev. Todos os modelos receberam o mesmo formato. Não testamos se outro formato mudaria os resultados. A Laya rodou com limites de entrada acima das configurações divulgadas para que páginas longas não fossem cortadas.
Cite este benchmark
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{kalelioglu2026,
author = {Kalelioğlu, Berk},
title = {{AIM-Decision: Jev versus Kev versus LLMs}},
year = {2026},
month = oct,
howpublished = {\url{https://aimultiple.com/decision-models}},
note = {AIMultiple. Acessado em 5 outubro 2026}
}Resultados e carimbos de data/hora de 146 pontos de dados. Baixe os dados resumidos exibidos nos gráficos e tabelas deste artigo como um arquivo ZIP contendo 5 arquivos CSV e um README.
Quer os dados granulares por trás disso? Assine o Premium


Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.