Jev vs Decisions API da OpenAI: onde o Jev continua a ganhar, e o que ainda ninguém provou
Oito dias de diferença. A TypeSafe lançou o Jev a 21 de setembro, e a 29 de setembro, no DevDay, a OpenAI anunciou a Decisions API. Os dois fazem a mesma coisa de base. Descreves uma pergunta e as respostas que aceitas, e recebes uma decisão sobre a qual o teu código pode agir, em vez de um parágrafo que tens de interpretar.
Este mês fiz um benchmark ao Jev em Batalha Naval, por isso quis perceber onde é que ele fica agora que a OpenAI tem a sua própria versão.
Hoje, o Jev continua à frente. Parte da razão é simplesmente que a versão da OpenAI ainda não saiu ao público, por isso quero deixar claro o que aqui está medido e o que é só aquilo que cada empresa publicou.
A mesma categoria, uma máquina diferente
Os dois produtos partilham uma ideia de interface e pouco mais.
O Jev é um modelo próprio. A TypeSafe chama-lhe o primeiro modelo "System One", construído de raiz para avaliar perguntas tipadas contra um estado e devolver probabilidades. Não gera texto nenhum. O Simon Willison prefere o termo "modelo de decisão", e é esse que vou usar.
A Decisions API é um endpoint à frente de uma versão especializada do GPT-6 Luna, o modelo generalista da OpenAI. Continuas a definir a pergunta e as respostas permitidas, e a OpenAI mantém o output dentro dessas respostas. Só que atrás do endpoint está um modelo de fronteira que também te escreve um soneto.
Essa diferença explica quase tudo o que vem a seguir. É por isso que a OpenAI aceita imagens logo à partida. E é também por isso que o número de velocidade que anuncia, cerca de 150 ms e umas dez vezes mais rápido, é medido contra perguntar o mesmo ao GPT-6 Luna pela API normal. A comparação é Luna contra Luna. A OpenAI não a pôs ao lado do Jev.
Onde o Jev ganha hoje
Consegues mesmo usá-lo
A Decisions API está em "limited preview". A maioria de nós pode ler o anúncio e pouco mais.
O Jev é público. O meu benchmark de Batalha Naval fez 6.000 chamadas e custou 77 cêntimos, e o código é aberto, por isso qualquer pessoa o pode voltar a correr. Não consigo correr esse benchmark contra a OpenAI, e tu também não, a não ser que estejas no preview.
O preço é público
O Jev cobra 0,042 dólares por milhão de tokens de input e nada pelo output. O Simon fez notar que isso fica abaixo até do preço de input do GPT-5 Nano. A OpenAI ainda não publicou preços para a Decisions API. Com o Luna por baixo, ficava surpreendido se saísse mais barata, mas é um palpite, e vou tratá-lo como tal até existir uma página de preços.
Mais tipos de pergunta
O Jev tem três tipos de pergunta. Um Choice escolhe de uma lista e devolve uma probabilidade para cada opção. Um Score dá uma nota numa escala numérica que tu descreves. Um Noul devolve a probabilidade de uma afirmação ser verdadeira, de 0 a 1. Podes misturar os três na mesma chamada, e cada pergunta é avaliada de forma independente e em paralelo, por isso dez perguntas demoram mais ou menos o mesmo que uma, e juntar mais não contamina o que as outras veem.
Isso muda a forma como se constrói com ele. A documentação da TypeSafe empurra-te para partir um julgamento grande em vários pequenos e combinar as respostas no teu próprio código. Um ticket de suporte passa a ser "esta mensagem pede um reembolso?", "quão frustrado está o cliente, de 0 a 10?" e "que equipa fica com isto?", tudo perguntado contra o mesmo estado, num só pedido.
Tudo o que a OpenAI publicou até agora descreve um só formato: uma pergunta com respostas predefinidas. Isso cobre classificação e routing, que é a maior parte do uso que as pessoas lhe vão dar. Para uma probabilidade de sim ou não, ou para uma nota numérica, tinhas de a simular com baldes de respostas.
Já há gente a construir em cima dele
Em nove dias o Jev ganhou um plugin para a ferramenta llm do Simon, por isso isto funciona diretamente no terminal:
llm -m jev 'Please refund my last payment.' -s 'Does this message explicitly request a refund?'
O Josh Rosen escreveu sobre como o usa dentro do ThruWire como checkpoint para o trabalho de agentes. O agente faz o que quiser entre checkpoints, e em cada um o Jev avalia se as provas sustentam mesmo o que o agente afirma antes de o trabalho avançar. O CEO da TypeSafe partilhou notas sobre agentes de código com ideias como fazer uma pergunta de sim ou não sobre cada pedaço de contexto para decidir o que o próximo turno precisa mesmo de ver. Já existe até uma imitação com pesos abertos, chamada Kev.
Esta é a parte que acho mais interessante. Os primeiros casos de uso a que as pessoas chegam são canalização dentro de agentes, onde uma só tarefa precisa de centenas de pequenos julgamentos e cada um tem de ser barato e rápido. É exatamente nesse trabalho que um modelo pequeno e dedicado devia ganhar a um modelo de fronteira atrás de um endpoint.
Onde a OpenAI pode ganhar
Não quero escrever a versão deste artigo em que o Jev ganha tudo, porque os dados não dizem isso.
As imagens são o caso óbvio. O Jev só recebe texto. Se a tua decisão depende de uma captura de ecrã, de uma fatura digitalizada ou da fotografia de uma encomenda danificada, a OpenAI é a única das duas que a consegue ver (por agora, em preview).
Atualização, 6 de outubro de 2026: um dia depois de este artigo sair, a Cloudflare lançou o Clef, um modelo de decisão com pesos abertos que usa a mesma API do Jev e aceita até quatro imagens por pedido. Já há um modelo de decisão dedicado que também consegue ver imagens. Entretanto comparei o Clef com o Jev.
O outro é o modelo que está por trás. O Jev tem pontos fracos documentados, e a própria página de irregularidades do modelo da TypeSafe diz que tem dificuldades com números, com datas e com texto escrito de propósito para o enganar. No meu benchmark de Batalha Naval arredondava as probabilidades a duas casas decimais, por isso, com 90 opções, cerca de metade voltava a zero e quase todas as outras ficavam empatadas em 0,01, o que deixava uma ordem útil para mais ou menos uma dúzia de casas. Com o tabuleiro em bruto, perdeu para uma heurística que escreverias de cabeça. O Luna tem muito mais conhecimento geral por trás, e perante um contexto longo e confuso pode simplesmente lê-lo melhor. Ninguém o mostrou ainda, mas é a forma mais plausível de a OpenAI ganhar em qualidade.
Correção, 6 de outubro de 2026: uma versão anterior deste parágrafo dizia que a distribuição voltava quase toda a zeros. Um teste posterior mostrou que cerca de 45 das 90 opções voltam com valor e que as probabilidades continuam a somar 0,996. O problema é que dezenas de opções ficam empatadas no fundo da lista, sem forma de as ordenar.
E há equipas que vão escolher a OpenAI porque já pagam à OpenAI. Um fornecedor, uma fatura, um só conjunto de papelada de compliance. É uma razão aborrecida, e é real.
O que ainda ninguém provou
A maior pergunta em aberto é se a "confiança" de qualquer um dos dois quer dizer alguma coisa. O guia da Hugging Face sobre a Decisions API di-lo sem rodeios: não assumas que um campo chamado confidence é uma probabilidade calibrada. Isto também vale para o Jev. O Simon pediu-lhe para avaliar cidades da Bay Area e ficou com Cupertino no topo e East Palo Alto em último, que é o tipo de padrão que não queres escondido dentro de uma decisão de contratação ou de crédito.
Depois há a pergunta mais simples de todas, qual dos dois faz melhor o mesmo trabalho. Não encontrei um único benchmark que os ponha frente a frente. Todas as tabelas de comparação que li, incluindo as dos guias acima, comparam funcionalidades e disponibilidade. Nenhuma compara resultados.
E a Decisions API é um preview. Os nomes dos endpoints, os limites, os preços e o significado das pontuações podem mudar todos antes de chegar a toda a gente.
O que eu faria agora
Se esta semana fosse construir em cima de um modelo de decisão, usava o Jev, porque é o que consigo chamar, medir e pagar. Mantinha a chamada atrás de uma interface pequena no meu próprio código, para que trocar para a Decisions API mais tarde seja uma mudança num só ficheiro.
E trazia comigo a única lição da Batalha Naval que não tem nada a ver com qual dos fornecedores ganha. O Jev só pareceu bom depois de o meu código já ter reduzido o problema a 16 opções descritas, e mesmo aí empatou com código simples. Constrói primeiro a escada de baselines (aleatório, uma heurística ingénua, a melhor solução só com código que tiveres paciência para escrever) e compara o modelo que escolheres com ela. Esse teste funciona da mesma forma quer o modelo atrás do endpoint seja o Jev, quer seja o Luna.
O código do benchmark de Batalha Naval é aberto. Se estiveres no preview da Decisions API, apontá-lo à OpenAI dava-nos o primeiro frente a frente que eu já vi. Gostava muito de ver os números.