A API Decisions da OpenAI e o Jev da TypeSafe fazem o mesmo trabalho: enviam uma entrada e um conjunto de perguntas, recebem respostas tipadas com probabilidades em vez de texto para analisar, e pagam apenas pelos tokens de entrada. Decisions custa US$0.10 por 1M de tokens de entrada, está em beta público, aceita texto e imagens, e roda no GPT-6 Luna. Jev custa US$0.042 por 1M de tokens de entrada, está em acesso antecipado atrás de uma conta de console da TypeSafe, é somente texto, e limita cada requisição a 64k tokens.
Para o básico, comece com o que é a API Decisions e como usar o Jev. Esta postagem os compara linha por linha, depois conecta ambos em um projeto Apidog por trás de uma única regra de confiança.
Comparação lado a lado
Cada célula é proveniente das páginas dos fornecedores nas referências.
| API Decisions da OpenAI | Jev da TypeSafe | |
|---|---|---|
| Endpoint | POST /v1/decisions |
POST /v1/systemone |
| Modelo | apenas gpt-6-luna |
jev-1.13.0 (jev-latest) |
| Status | beta público, GA “nas próximas semanas” | acesso antecipado (post de lançamento), acesso direto restrito por uma conta de console |
| Entrada | texto + imagens (URL de dados base64; referência também lista URLs públicas) | somente texto, 64k por requisição |
| Tipos de pergunta | predicate / choice (2 a 255 opções) / score |
noul / choice / score |
| Formato das perguntas | array com name opcional |
objeto indexado por ID |
| Campos de saída | probability; choice ou score + probabilities + confidence; refusal |
noul; choice ou score + confidence + probabilities |
| Preço | US$0.10 por 1M de entrada, sem cobrança de saída | US$0.042 por 1M de entrada, sem cobrança de saída |
| Cache | nenhum ainda (fórum OpenAI) | não publicado |
| Limites de taxa | página de limites por organização | 100K TPS / 80 RPS, dinâmico |
| Alegação de velocidade | “cerca de 10x mais rápido que a API Responses” (OpenAI) | 70 a 500 ms de ponta a ponta (TypeSafe) |
| Dados | ZDR + HIPAA para clientes elegíveis; residência nos EUA/UE | ZDR para empresas; não treinado em requisições |
Decisions é um endpoint, não um modelo; ele roda no GPT-6 Luna. Jev é o “modelo System One” da TypeSafe, treinado com RLCD para retornar decisões calibradas, e não um LLM geral.
A mesma requisição de roteamento de ticket em ambos os formatos
Um ticket de suporte chega; você quer um departamento e um sim/não sobre se o cliente deseja um reembolso. Primeiro Decisions: as perguntas são um array, cada uma com um type, instructions e um name opcional que a API retorna.
curl https://api.openai.com/v1/decisions \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-6-luna",
"input": "I was charged twice for my order.",
"questions": [
{
"type": "choice",
"name": "department",
"instructions": "Which team should handle this ticket?",
"choices": [
{"value": "billing", "description": "Charges, refunds"},
{"value": "technical", "description": "Bugs, errors"},
{"value": "other"}
]
},
{
"type": "predicate",
"name": "wants_refund",
"instructions": "Is the customer asking for money back?"
}
]
}'
Agora Jev: o campo de entrada é state, as perguntas são um objeto indexado por IDs que você escolhe, choice aceita um mapa criteria de opção para descrição, e o tipo sim/não é noul.
curl https://api.typesafe.ai/v1/systemone \
-H "Authorization: Bearer $TYPESAFE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "jev-latest",
"state": "I was charged twice for my order.",
"questions": {
"department": {
"type": "choice",
"instructions": "Which team should handle this ticket?",
"criteria": {
"billing": "Charges, refunds",
"technical": "Bugs, errors",
"other": "Anything else"
}
},
"wants_refund": {
"type": "noul",
"instructions": "Is the customer asking for money back?"
}
}
}'
O que é retornado
Decisions retorna model, answers e usage. As respostas chegam na ordem solicitada, cada uma com seu name; as probabilidades por opção são um array de objetos. Observe output_tokens: 0.
{
"model": "gpt-6-luna",
"answers": [
{
"type": "choice",
"name": "department",
"choice": "billing",
"probabilities": [
{"value": "billing", "probability": 0.95},
{"value": "technical", "probability": 0.02},
{"value": "other", "probability": 0.03}
],
"confidence": 0.93
},
{"type": "predicate", "name": "wants_refund", "probability": 0.95}
],
"usage": {
"input_tokens": 42,
"input_tokens_details": {"cached_tokens": 0, "cache_write_tokens": 0},
"output_tokens": 0,
"output_tokens_details": {"reasoning_tokens": 0},
"total_tokens": 42
}
}
Jev retorna model (o ID versionado), um objeto answers indexado pelos IDs de suas perguntas e usage com input_tokens e output_tokens. Você lê answers.department.choice, sua confidence e probabilities indexadas pelo nome da opção, além de answers.wants_refund.noul. Apenas no lado da OpenAI, uma resposta de refusal pode aparecer por pergunta enquanto as outras ainda recebem respostas.
Preço por milhão, e quanto custam um milhão de tickets
Redação da OpenAI: com gpt-6-luna, a entrada custa US$0.10 por 1M de tokens, sem cobranças de leitura de cache, escrita de cache ou tokens de saída. A TypeSafe lista US$0.042 por 1M de tokens de entrada e saída gratuita.
Considere um ticket de 500 tokens com as duas perguntas acima:
- Decisions: 500 / 1.000.000 x US$0.10 = US$0.00005 por requisição. Um milhão de tickets = US$50.
- Jev: 500 / 1.000.000 x US$0.042 = US$0.000021 por requisição. Um milhão de tickets = US$21.
Dois multiplicadores se aplicam no lado da OpenAI: entrada de contexto longo (acima de 272K tokens) é 2x, então US$0.20 por 1M, derivado da página de preços, e o processamento regional adiciona 10%. Nenhuma camada Batch, Flex ou Fast está documentada para /v1/decisions, e de acordo com o fórum da OpenAI, ainda não há cache de prompt, embora usage contenha os campos cached_tokens e cache_write_tokens. Jev não publica nada sobre cache.
Entradas: imagens de um lado, texto do outro
Decisions aceita uma string ou um array de mensagens de usuário misturando partes de input_text e input_image. O guia diz que as imagens devem ser URLs de dados base64 inline; a referência da API também lista URLs HTTP(S) públicas e até 128 imagens por requisição, então trate base64 como o caminho seguro e teste URLs hospedadas antes de confiar nelas. file_id, arquivos e áudio não são suportados.
Jev é somente texto: uma string, um objeto JSON ou um array de texto, sem entrada de imagem, áudio ou vídeo, de acordo com a página de modelos da TypeSafe. No fórum da OpenAI, sam.saffron disse claramente: o entendimento de imagens é algo que o Jev ainda não suporta. Se sua decisão depender de uma foto, apenas Decisions pode analisá-la.
Contexto e limites de taxa
Jev publica um limite de 64k tokens por requisição, sendo 32k para state mais a pergunta mais longa, e afirma que ingere o estado uma vez e avalia cada pergunta em paralelo. Sua página de modelos lista 100K tokens por segundo e 80 requisições por segundo, ajustando-se dinamicamente, com um 429 se o limite for excedido. Esses números mudaram desde setembro, então leia a página ao vivo.
A OpenAI não publica um valor de janela de contexto e nenhum limite de taxa específico para Decisions; a janela de 1.050.000 tokens de Luna é um número da página do modelo, não do endpoint. Verifique Configurações > Organização > Limites (guia de limites de taxa); nosso guia de limites de taxa aborda o tratamento de 429 em ambos os lados.
Status e acesso
Decisions entrou em beta público em 06-10-2026, aberto a todos os desenvolvedores de acordo com o anúncio; o guia diz que a OpenAI espera a GA “nas próximas semanas”, sem data definida.
Jev está em acesso antecipado de acordo com o post de lançamento da TypeSafe, que menciona uma lista de espera, e o acesso direto a api.typesafe.ai está atrás de uma conta de console da TypeSafe; como acessar o Jev descreve os caminhos e chave de API do Jev aborda a criação de chaves. A segunda rota é o Vercel AI Gateway, onde Jev é typesafe-ai/jev, chamado através de experimental_evaluate no AI SDK (7.0.105 ou posterior), de acordo com o changelog da Vercel; a documentação de avaliação da Vercel diz que ele não é exposto no endpoint compatível com OpenAI do Gateway, e lá o tipo sim/não é boolean, retornando a probabilidade de verdadeiro.
Controles de dados
A OpenAI afirma que Decisions suporta Retenção Zero de Dados (ZDR) e uso HIPAA para clientes elegíveis, com residência de dados e processamento regional nos Estados Unidos e Europa (EEE mais Suíça); a página de controles de dados acrescenta que os logs de monitoramento de abuso para /v1/decisions são mantidos por até 30 dias por padrão. A TypeSafe diz que Jev não é treinado em requisições ou respostas de clientes, oferece ZDR para clientes empresariais e executa os mesmos pesos para cada conta.
Nenhum dos fornecedores publica dados de precisão ou calibração; o guia da OpenAI sugere que você defina os limites a partir de seus próprios exemplos rotulados, e isso também se aplica ao Jev.
Velocidade, então qual escolher
A OpenAI diz que Decisions é cerca de 10x mais rápido que a API Responses e não publica um número absoluto de latência; um desenvolvedor no fórum da OpenAI relatou decisões de entrada de imagem em cerca de 0.8 segundos em uma conexão lenta. A TypeSafe cita de 70 ms a 500 ms de ponta a ponta para o Jev. Essas não são medições comparáveis, então cronometre ambos com seus próprios tickets.
Escolha Decisions quando a entrada incluir imagens, quando você já usa OpenAI e quer uma chave e uma fatura, ou quando você precisa de cobertura HIPAA sob um BAA da OpenAI. Escolha Jev quando a entrada for texto, quando o preço mais baixo por token for relevante para o seu volume, ou quando você já usa o Vercel AI Gateway.
Executar ambos por algumas semanas é sensato: avalie cada um contra o mesmo conjunto rotulado, mantenha a melhor curva de limiar e guarde o outro como fallback. Se a verdadeira questão for Decisions versus um rótulo de Saídas Estruturadas, consulte Decisions vs Responses; se nenhum dos fornecedores se adequar à sua política de dados, existem alternativas open-source ao Jev.
Teste ambos em um projeto Apidog
Dois ambientes. Crie OpenAI com OPENAI_API_KEY e TypeSafe com TYPESAFE_API_KEY, cada um com o valor no campo local para que nunca seja sincronizado com a equipe (ambientes e variáveis secretas abrange o escopo).
Duas requisições salvas. POST https://api.openai.com/v1/decisions com Bearer {{OPENAI_API_KEY}} e o primeiro corpo acima; POST https://api.typesafe.ai/v1/systemone com Bearer {{TYPESAFE_API_KEY}} e o segundo.
Uma regra de asserção, aplicada duas vezes. A regra de negócio: confiança acima de 0.8 roteia o ticket automaticamente, qualquer valor abaixo vai para uma fila de revisão. Na requisição Decisions, afirme status 200, $.answers[0].choice igual a billing, $.answers[0].confidence maior que 0.8, e $.usage.output_tokens igual a 0. Na requisição Jev, afirme $.answers.department.choice igual a billing e $.answers.department.confidence maior que 0.8.
Um cenário orientado a dados. Coloque vinte tickets rotulados em um CSV com o departamento esperado, execute ambas as requisições sobre ele como um cenário de teste e veja qual API tem a confiança caindo abaixo de 0.8 nas linhas ambíguas. É assim que você escolhe os limites, e isso detecta uma mudança de modelo antes que os tickets sejam roteados incorretamente.
Simule ambos os formatos. Salve uma resposta Decisions e uma resposta Jev como mocks para que o frontend possa ser construído contra um array answers estável e um objeto answers; simular respostas condicionais retorna o caso de baixa confiança sob demanda para exercitar o branch da fila de revisão.
Execute-o na CI. Execute o cenário com o Apidog CLI (apidog run com o reporter cli ou junit) a cada deploy, para que uma mudança de campo na GA ou uma atualização de jev-latest torne o build vermelho, e não a fila de suporte. Baixe o Apidog para configurar isso.
FAQ
Jev é um LLM como o GPT-6 Luna? Não. A TypeSafe descreve Jev como um modelo System One treinado com RLCD para retornar decisões calibradas; ele não gera texto. Decisions é um endpoint no modelo Luna de propósito geral.
A OpenAI construiu a API Decisions em resposta ao Jev? As páginas da OpenAI não afirmam isso, e nós não o alegamos. Ambos entregam a mesma ideia: respostas tipadas com probabilidades, cobradas pela entrada.
Qual é mais barato? Jev, a US$0.042 por 1M de tokens de entrada contra US$0.10; em um milhão de tickets de 500 tokens, US$21 contra US$50.
Algum deles pode retornar meu próprio esquema JSON? Não. Ambos retornam formatos de resposta fixos; para campos extraídos ou uma explicação escrita, use Saídas Estruturadas na API Responses.
Próximo passo
Envie as duas requisições curl acima com o mesmo ticket, salve ambas no Apidog e adicione a asserção de confiança de 0.8 a cada uma. Em seguida, substitua por vinte de seus próprios tickets e veja qual API cruza seu limite com mais frequência. O guia de como usar possui as versões em Python e JavaScript.