Mal passou um mês desde o lançamento do Jev e já é perceptível como ele abriu os olhos dos desenvolvedores de sistemas baseados em IA para uma nova vertente, os modelos discriminativos de decisão.
Mesmo com os modelos discriminativos existindo há décadas, o Jev surgiu com um diferencial de impacto: um foundation model puramente discriminativo, construído para uso geral via API. Agora você não precisa mais treinar o seu sistema com 1000 imagens contendo um gato e 1000 imagens contendo um cachorro para ter uma rede neural que consiga discernir um do outro com precisão.
Assim como aconteceu com as outras ferramentas e modelos quando lançados, surgiram diversos benchmarks e casos de uso ressaltando o impacto que esses modelos causaram nos sistemas. Lendo essas análises eu percebi um ponto em comum: a maior parte das chamadas de um LLM de um agente não precisam de raciocínio, são decisões. Aprovar um comando, escolher a próxima ferramenta dentre as disponíveis, julgar se a tarefa terminou, decidir qual modelo usar, etc. Para isso voce não precisa de um Claude Fable ou GPT-6 Sol, precisa de algo barato, rápido e com saída estruturada.
A LangChain integrou o Jev no harness e no LangSmith. A OpenAI anunciou a Decisions API no DevDay. Os números de economia variavam de "40x", "277x" a "444x".
Fui atrás das fontes primárias de cada número desse buscando entender quais foram as diferenças de cada uso para haver essa diferença tão grande nos resultados. Eu já adianto que a tese sobrevive, mas não do jeito que parece.
Cascata e Roteamento (nada novo)
Usar um modelo barato e só recorrer a um caro quando necessário não é uma ideia nova, e ela aparece em duas formas.
A técnica de cascata, onde o modelo barato responde primeiro e a resposta só sobe para o caro se não for boa o suficiente, ou seja, ele decide depois da resposta se há a necessidade de um modelo melhor. O FrugalGPT (Stanford, 2023) mostrou que isso iguala o desempenho do melhor modelo individual com até 98% de redução de custo.
E no roteamento, um classificador decide antes qual modelo chamar. O RouteLLM (LMSYS/Berkeley, 2024) treinou roteadores com base em votos humanos sobre qual resposta era melhor e cortou o custo "em mais de 2x em alguns casos" sem perda de qualidade.
O que mudou em 2026 foi a peça do meio: ao invés de um LLM pequeno ou de um classificador treinado para uma única decisão, agora temos modelos de uso geral que só decidem. Qualquer pergunta, qualquer conjunto de respostas, sem treinar nada.
- Jev (TypeSafe): treinado com RLCD (Reinforcement Learning for Calibrated Decisions). Recebe uma pergunta com um schema de respostas possíveis e devolve a escolha com confiança calibrada. A TypeSafe fala em "40x-200x mais rápido" para consultas nesse formato, e input a $0,042/MTok.
- Decisions API (OpenAI): anunciada no DevDay como "decision-making em tempo real, powered by GPT-6 Luna", para classificar conteúdo, rotear requisições ou escolher a próxima ação de um agente. Um slide mostrava 150 ms contra 1,6 s do Luna normal.
Certo, até aqui tudo bonito. Agora vamos aos números.
De onde vem cada número
"444x" é a demo da própria TypeSafe
O "444,6x mais barato" vem de uma demo na home da própria TypeSafe, com workflows montados pelo time deles. Não há uma metodologia publicada para avaliar.
"277x" é de um paper independente
Já o 277x não é marketing da TypeSafe. Vem de um paper independente da CMU, JEV-as-a-Judge: Accept When Confident, Escalate When Unsure, que demonstrou o resultado de $0,044 contra $12,182 por mil julgamentos comparando com o GPT-6. Porém os próprios autores limitam o alcance dizendo que avaliaram o Jev apenas como um juiz de respostas prontas. Se ele funciona da mesma forma dentro de um agente escolhendo ferramentas ou a próxima ação "não foi testado aqui".
E esse paper foi a evidência mais robusta que encontrei disponível, justamente porque mede qualidade, não só o custo: 5.172 julgamentos comparando o Jev com outros 16 juízes, com adjudicação humana cega nos casos em que os juízes discordaram.
| Benchmark | Jev | GPT-6 |
|---|---|---|
| RewardBench (1.500) | 92,5% | 92,5% |
| HaluEval (3.000) | 87,3% | 88,4% |
| JudgeBench (350) | 78,6% | 93,1% |
| Código (1.302) | 78,8% | 91,7% |
| Logic Puzzles (98) | 68,4% | 95,9% |
Em julgamentos "de reconhecimento", ou seja, quando dá para julgar apenas olhando o material entregue (pergunta + qual resposta é mais útil para o cliente em um chatbot), o Jev tecnicamente empata(nas palavras dos autores, fica "até três pontos do GPT-6 sempre que o veredito pode ser lido no texto"). Quando o veredito precisa ser derivado, ou seja, o juiz precisa resolver o problema para saber se a resposta está certa (matemática, código, lógica), ele perde de 13 a 28 pontos percentuais. Os autores dizem isso explicitamente.
"83x" ou "13%"? Depende contra quem
A LangChain testou o Jev como juiz de avaliação de agentes. Ela pegou 5 respostas de um agente simples de previsão do tempo e pediu para cada juiz avaliar cada resposta 100 vezes (totalizando 500 julgamentos), buscando medir não só se ele acerta, mas se o veredito é consistente. Tudo isso acompanhado por um revisor humano.
| Juiz | Concordância com o humano | Custo total |
|---|---|---|
| Jev | 100% | $0,34 |
| GPT-5.6 Luna | 96,4% | $0,39 |
| GPT-5.6 Terra | 99,8% | $2,90 |
| Claude Sonnet 4.6 | 80,0% | $28,17 |
Contra o Sonnet, o Jev é aproximadamente 83x mais barato. Mas contra o Luna, que é o concorrente direto de um modelo de decisão, a diferença caiu para 13%. E esse utilizado no estudo é o GPT-5.6 Luna, uma geração anterior ao GPT-6 Luna que roda a Decisions API. O ganho real demonstrado aqui é outro: a variância. A variância média por caso do Jev ficou entre 92 e 913 vezes menor que a dos LLMs. Para um juiz que roda a cada mudança no agente, isso importa mais que centavos. Se o juiz oscila, você não vai saber se a nota caiu porque o agente piorou ou se foi porque o juiz mudou de ideia.
Ressalto que os autores são honestos dizendo "um teste restrito", ou seja, são apenas 5 casos com um único agente de previsão do tempo. E a informação sobre qual a versão do Jev foi utilizada "não estava disponível nos metadados do experimento".
A própria TypeSafe admite que seus números estão "no lado mais alto dos ganhos do mundo real" e que o speedup "tende a ser bem menor" contra LLMs sem modo de raciocínio, como o Luna.
"−64% sem perda de qualidade", mas com um detalhe
O roteador de modelos da LangChain no Open SWE, um agente de código open source deles, cortou em 64% o custo mediano por conversa (thread) ($0,94 contra $2,61) em comparação com usar sempre o modelo mais caro, o GPT-6 Astra. Na média, a queda foi de 42%, e nas 10% de conversas mais caras, de 37%. O teste A/B rodou em 973 conversas de engenheiros internos, e a qualidade (a fração de conversas que terminou em PR aceito) ficou em 29,2% contra 27,3%. Mas com p=0,49, a diferença pode ser acaso, ou seja, no geral o roteador economizou sem piorar a qualidade.
Dois detalhes mudam a leitura:
- O roteador decide uma vez por thread, classificando só a primeira mensagem humana. Não reroteia no meio. Escolhe entre três tiers (GLM-5.3-Flash, GPT-5.6 Sol, GPT-6 Astra). Começou com um LLM com saída estruturada e migrou para o Jev, "quase 50 vezes mais rápido".
- Houve uma segunda linha: roteador contra "sempre o modelo rápido". Foi encerrado em menos de um dia, antes de ter significância estatística, porque essa linha de usar "sempre o rápido" estava "atrapalhando a produtividade pela baixa qualidade do output".
Resumindo: a decisão barata funcionou. A execução barata, não.
Conclusão
O que as evidências sustentam
- Cascata com escalonamento. No paper da CMU, o Jev responde primeiro e só tem a resposta aceita quando está confiante. O resto sobe para o GPT-6. Nos 1.610 pares de teste, o Jev resolveu 69% das decisões, o sistema ficou 0,9 ponto mais preciso que o GPT-6 sozinho e custou 41% do valor. Não são 277x, são cerca de 2,4x (ainda assim é uma economia considerável sem perda de qualidade).
- Rotear cedo, uma vez e com um classificador. O roteador da LangChain escolhe o modelo na primeira mensagem e o mantém até o fim da conversa, sem ficar tentando otimizar cada chamada. É simples, evita os custos de trocar de modelo no meio, e foi o único caso com teste A/B em produção mostrando economia sem perda de qualidade.
- Consistência, não só custo. No teste da LangChain, a economia contra o Luna foi de só 13%, mas o Jev concordou com o humano nos 500 julgamentos e oscilou de 92 a 913 vezes menos que os LLMs. Para um juiz que avalia o agente a cada mudança, isso vale mais que a economia financeira, a nota só muda quando o agente muda.
- Ineficiência em decisões que exigem raciocínio. "Esse PR está correto?" tem resposta sim ou não, mas para responder é necessário entender o código. É derivação disfarçada de decisão, e é exatamente onde o Jev perde 13 pontos. Nesses casos ou você aceita o erro, ou escala para o modelo grande e perde a economia.
Pontos em aberto
Durante essa pesquisa, percebi que a premissa que citei no início desse artigo de que "a maioria das chamadas de um agente são decisões", não foi medida. Não encontrei nenhum estudo com traces reais demonstrando qual fração das chamadas dos agentes é apenas decisão e qual é raciocínio ou geração.
O registro mais próximo disso que encontrei foi o do paper da NVIDIA Small Language Models are the Future of Agentic AI trazendo que 40% a 70% das consultas em MetaGPT, Open Operator e Cradle "poderiam ser atendidas" por SLMs especializados. Mas é somente uma estimativa dos autores, não uma medição real (também vale lembrarmos que a NVIDIA vende infraestrutura para SLMs).
Um outro ponto importante a ser levado em consideração quando falamos em vida real e os estudos não medem é o custo downstream de uma decisão errada. Quanto custa no seu fluxo, de ponta a ponta, um comando aprovado que não deveria ter sido ou uma tarefa roteada para o tier errado?
Esses dois pontos dependem muito de como você construiu a sua solução e do fluxo, é algo praticamente individual. Mas se você tem um agente em produção provavelmente esses são números que serão relevantes para sua avaliação.
Por fim
Modelos de decisão são uma primitiva real e útil de harness. Mas o ganho real pode significar "2,4x com cascata e escalonamento" ou "−64% roteando uma vez por thread", não serão sempre as "277x". O número que você vê depende do baseline que alguém escolheu, e uma decisão barata no lugar errado, como a que exige raciocínio, pode sair mais cara do que a do modelo grande.
Desconfie de multiplicadores soltos. Pergunte contra quem, medindo o quê, com quantos casos?
No fim, nenhum desses estudos prometeu uma resposta pronta ou uma receita de bolo a ser seguida. As próprias publicações (que vimos anteriormente) são bem claras quanto as limitações dos estudos. Vi muitas pessoas ignorarem todo o contexto e deixar toda a atenção apenas nos "277x" ou nos outros números que enchem os olhos. O valor desses estudos não está no número, está em mostrar em que cenário cada abordagem funciona e quais variáveis mudam o resultado. O ensinamento que devemos obter desses artigos não é "qual modelo é melhor", mas sim "o que disso vale para o meu produto".
Referências
- Chen, Zaharia, Zou. FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance. Stanford, 2023.
- Ong et al. RouteLLM: Learning to Route LLMs with Preference Data. LMSYS/Berkeley, 2024.
- JEV-as-a-Judge: Accept When Confident, Escalate When Unsure. CMU, 2026.
- Belcak et al. Small Language Models are the Future of Agentic AI. NVIDIA, 2025.
- TypeSafe. Introducing System One Models & Jev.
- LangChain. Can Jev Be a Better Agent Evaluator?.
- LangChain. How to Build a Model Router in the Harness.
- OpenAI Developers. Anúncio da Decisions API no DevDay.
- The Decoder. OpenAI expands Codex and its API at DevDay with security scans, a Decisions API, and Ultrafast
Top comments (0)