Jev ou Decisions API da OpenAI: qual camada de decisão escolher para o seu produto?

Fala aí, beleza? A OpenAI acabou de abrir a Decisions API pra todo mundo, e ela chega pisando exatamente no terreno do Jev 🙂

No papel, as duas fazem a mesma coisa: tu manda um estado, faz perguntas tipadas sobre ele e recebe probabilidades de volta

Porém a escolha certa muda bastante conforme o TIPO de decisão que o seu produto precisa tomar

Recapitulando rapidinho: segundo o post do OpenRouter sobre o Jev, ele é o modelo de decisão hospedado da TypeSafe, um laboratório de IA fundado por Diogo Almeida, Erik Gafni e Sasha Sheng

Ele saiu em early access em 15 de setembro de 2026 e também está no OpenRouter como typesafe/jev-1.13

Do outro lado, a Decisions API da OpenAI apareceu em prévia no DevDay de 29 de setembro de 2026 e virou beta pública em 6 de outubro de 2026

Se tu já vem acompanhando o Jev por aqui, inclusive o papo sobre mods com Jev no Claude Code, este post é o próximo passo: decidir se ele segue como sua camada de decisão ou se vale olhar pra OpenAI

Um aviso honesto antes: este comparativo é feito em cima da documentação dos fornecedores, sem teste próprio, beleza?

Curso Recomendado

Curso de Jev: Sistemas Mais Inteligentes, Rápidos e Robustos

Desenvolva sistemas mais inteligentes, rápidos e robustos com Jev

Conhecer curso

Jev x Decisions API: comparação lado a lado

Antes de entrar em cada tipo de decisão, vale ver o quadro geral, com o que cada fornecedor documenta hoje:

Se liga num detalhe do acesso ao Jev: direto pela TypeSafe ainda tem lista de espera em typesafe.ai, e quem entra cria as chaves no console da TypeSafe (console.typesafe.ai/keys), onde também fica o Playground (console.typesafe.ai/playground)

Já pelo OpenRouter, qualquer pessoa com chave do OpenRouter consegue chamar, com a cobrança caindo na conta do OpenRouter

E do lado da OpenAI, imagem só entra como data URL base64 inline (URL hospedada e file_id não são aceitos), com até 128 imagens por requisição

Outro ponto que pesa: a documentação da TypeSafe diz que o Jev ingere o state uma vez e avalia cada pergunta em paralelo e isoladamente contra esse mesmo state

Ou seja, dá pra mandar várias perguntas sobre o mesmo contexto numa requisição só, cada uma avaliada de forma isolada

Para classificar e rotear: choice do Jev x Choices da Decisions API

Que tipo de decisão é essa? É quando a resposta certa é UMA entre várias opções nomeadas: categoria de um ticket, fila de destino, tipo de pedido e por aí vai

Os dois atendem esse caso: o choice do Jev e o Choices da Decisions API escolhem uma opção entre os valores que tu fornece

A diferença documentada está no que volta:

• Jev: devolve a probabilidade de cada opção e uma confiança, então dá pra ver se a escolha foi apertada ou folgada
• Decisions API: o que está documentado é que escolhe um dos valores fornecidos; se vem distribuição por opção, confirma na documentação antes de contar com isso

A própria OpenAI cita classificar conteúdo e rotear requisições como casos de uso da Decisions API, então esse é o terreno onde ela quer brigar

Mas o critério que realmente separa as duas aqui é simples: o conteúdo a classificar tem imagem?

Se tem, só a Decisions API atende, porque o Jev 1.13 é só texto

Se é tudo texto, a briga fica em preço, acesso e formato da resposta, e aí o Jev chega bem forte 😀

Para pontuar e priorizar: score do Jev x Scores da Decisions API

Aqui a ideia é avaliar algo contra uma rubrica ordenada, tipo níveis de urgência ou de qualidade

Os dois funcionam de forma parecida: avaliam contra níveis ordenados e devolvem uma posição ponderada por probabilidade

No Jev, o score aceita de 2 a 10 níveis e devolve, além da posição, a distribuição, a legenda e a confiança

Na Decisions API, o Scores devolve a média ponderada por probabilidade dos índices dos níveis

O limite de níveis e o que mais vem além dessa média não estão no que verifiquei, então confirma na documentação da OpenAI

E agora o ponto que muita gente vai ignorar… Tome cuidado!

A própria TypeSafe documenta que os níveis do score do Jev são fracos em calibração numérica e NÃO servem pra reconstruir um número exato interpolando entre níveis

Ou seja: use o score pra ordenar e priorizar, não pra cravar ‘nota exata’ de alguma coisa

Priorizar trabalho, aliás, é justamente um dos casos que a OpenAI indica pra Decisions API

Para aprovar ou barrar: noul do Jev x Predicates da Decisions API

Esse é o tipo de decisão mais perigoso de errar, porque normalmente vira um ‘pode’ ou ‘não pode’ dentro do produto

Os dois devolvem uma probabilidade de 0 a 1 de uma condição ser verdadeira: noul no Jev, Predicates na Decisions API

E o detalhe do Jev que muda o design do produto: 0,5 significa ‘não sei dizer’, não ‘médio’

E o que isso muda na prática? Muda que a sua regra de aprovação não pode ser só ‘acima de X aprova, abaixo reprova’

Tu precisa de uma zona de incerteza no meio, tratada de outro jeito: mandar pra revisão humana, pedir mais informação, segurar a ação e etc

Do lado da OpenAI, o que está documentado é a probabilidade de 0 a 1

Se a mesma semântica do 0,5 vale lá, confirma na documentação antes de reaproveitar o mesmo limiar nas duas APIs

Os critérios que realmente separam as duas opções

Tirando os tipos de pergunta (que se equivalem), sobram estes critérios pra decidir:

Dois cuidados de leitura nessa tabela

Primeiro: o ‘até 10x mais rápida’ da OpenAI é comparação com o próprio GPT-6 Luna pela Responses API, não com o Jev

Segundo: a lista de riscos do Jev vem da própria TypeSafe, então do lado da Decisions API vale conferir no guia da OpenAI quais limitações ela documenta antes de assumir que não tem nenhuma

Veredito: qual camada de decisão escolher para o seu produto

Sem fórmula mágica, beleza? Vai depender do perfil do produto

Tende ao Jev:

• Produto só de texto
• Alto volume de decisões, onde o preço por token de entrada pesa
• Várias perguntas sobre o mesmo estado, aproveitando a avaliação em paralelo
• Desde que tu mantenha o state enxuto, porque context rot é limitação documentada

Tende à Decisions API:

• Produto que precisa decidir em cima de imagem
• Time que já está no ecossistema OpenAI e aceita pagar mais por token de entrada pra manter tudo num fornecedor só

E independente do lado, lembra que os dois estão em fase inicial: early access de um lado, beta pública do outro

Então já deixa pronto o plano B da camada de decisão antes de colocar isso no caminho crítico

O que confirmar na documentação antes de escolher

• Limites de rate e SLA de cada fase (early access do Jev e beta da Decisions API)
• Janela de contexto da Decisions API
• Limite de níveis em Scores na Decisions API
• Formato exato da resposta de cada tipo de pergunta (distribuição, confiança e etc)
• Semântica do 0,5 nos Predicates da OpenAI
• Previsão de GA da Decisions API e de novos modelos além do gpt-6-luna

As referências são o guia do Jev no OpenRouter e o guia da Decisions API da OpenAI

Próximo passo: valide com as suas próprias decisões

Documentação ajuda a filtrar, mas quem decide de verdade são as decisões do SEU produto

Bora montar um teste simples:

1. Separa de 3 a 5 decisões reais do produto, de preferência cobrindo os três tipos: classificar, pontuar e aprovar ou barrar. Erro comum: escolher só casos fáceis, onde qualquer modelo acerta
2. Pra cada decisão, escreve a mesma pergunta nos dois tipos equivalentes (choice x Choices, score x Scores, noul x Predicates). Erro comum: usar um state cheio de coisa irrelevante e culpar o modelo pelo context rot
3. No Jev, o caminho mais rápido sem lista de espera é o OpenRouter: instala o @openrouter/sdk e chama openrouter.alpha.decisions.create() com model typesafe/jev-1.13, um objeto state e as perguntas tipadas
4. Na OpenAI, usa o endpoint POST /v1/decisions, que está em beta pública com o gpt-6-luna
5. Compara as respostas, olhando principalmente os casos de incerteza (no Jev, o famoso 0,5) e se a ordem dos scores faz sentido pra ti

Com esse teste na mão, a escolha deixa de ser hype e passa a ser dado do seu próprio produto 🙂

Conclusão

Resumindo: no Jev vs Decisions API, os tipos de pergunta se equivalem, então a decisão sai de outros critérios

Imagem no meio? Decisions API

Só texto, volume alto e várias perguntas por estado? O Jev tende a sair na frente pelo preço de entrada e pela avaliação em paralelo, com cuidado no tamanho do state

E antes de fechar com qualquer um, passa pelo checklist e confirma na documentação o que ainda não está claro

Valeu e até o próximo post!