Jev ou pedir JSON para um LLM: qual caminho usar para decisão estruturada?

Fala aí, beleza? Se o strict: true já obriga o modelo a devolver exatamente o seu JSON Schema, por que raios existiria um modelo separado só pra decidir?

Essa é a dúvida que aparece toda vez que alguém esbarra no Jev depois de já ter resolvido a vida com Structured Outputs

A resposta curta: os dois resolvem formato, mas só um deles te entrega distribuição

E isso muda bem mais coisa no seu código do que parece à primeira vista 🙂

O que cada caminho realmente entrega

Do lado do LLM, o problema de formato já é bem resolvido. A documentação de Structured Outputs da OpenAI diz que, com strict: true, a saída obedece ao JSON Schema fornecido, sem chave obrigatória faltando e sem valor de enum inválido, disponível tanto via response_format com json_schema quanto via function calling

Do lado da Anthropic, o Structured Outputs saiu do beta na Claude API para Claude Sonnet 4.5, Claude Opus 4.5 e Claude Haiku 4.5, com o parâmetro de formato migrando de output_format para output_config.format, e schemas cacheados por até 24 horas desde o último uso

Ou seja: a época de rezar pra IA não cuspir markdown em volta do JSON já passou

Agora o outro lado. O Jev é um modelo de decisão da TypeSafe que recebe um estado e perguntas tipadas e devolve respostas tipadas com probabilidade, em vez de texto livre

A TypeSafe chama isso de modelo de decisão tipada (System One) e é explícita: o Jev abre mão da geração de strings, é otimizado pra saída estruturada e, segundo a empresa, "não pode alucinar" justamente porque não gera texto

Repara na diferença de natureza aqui. Um modelo escreve um JSON que por acaso é uma decisão

O outro não escreve nada, ele responde perguntas

Pré-inscrição Curso Jev

Domine o Jev e coloque decisões de IA dentro do seu sistema

Você vai aprender a usar o Jev, o System One Model da TypeSafe AI, pra automatizar decisões com resposta tipada e confiança medida, sem depender de chat nem de alguém revisando cada passo. Entre na lista de espera para garantir a condição de lançamento!

Quero minha vaga

Jev x JSON de LLM: comparação ponto a ponto

O preço e a janela de contexto batem entre a tabela de modelos da TypeSafe e a página do modelo na OpenRouter, que explicita o detalhe importante: os 32k são pro estado mais uma única pergunta, a mais longa delas

Não é um contexto pra você despejar o histórico inteiro do usuário, beleza? É orçamento apertado por design

Previsibilidade do formato: onde o JSON do LLM ainda escorrega

Aqui vale ler a letra miúda da própria OpenAI, que é honesta sobre isso

A documentação lista as exceções em que o modelo pode não seguir o schema: quando há recusa (refusal = true) e quando a geração para em max_tokens ou em outra condição de parada antes de terminar

Traduzindo pro seu código: o JSON pode simplesmente não existir, ou pode chegar pela metade

E aí você precisa de:

• validação da resposta antes de confiar nela
• tratamento explícito do caso de recusa
• detecção de truncamento (o JSON abriu e não fechou)
• política de retry, com o custo de tokens que isso implica

Nada disso é drama, é engenharia normal. Mas é código que existe por causa do fato de que a saída é uma string sendo gerada token a token

O Jev ataca isso pela raiz: como ele não gera string, não existe JSON pela metade

Não tem chave faltando porque o modelo parou no meio, porque não tem chave sendo escrita

Tome cuidado com a conclusão errada, porém: "não trunca" não é o mesmo que "está sempre certo". Uma decisão tipada pode vir bem formada e ainda assim ser a decisão errada

O papel da confiança: o que muda no seu if

Essa é, na minha leitura, a diferença que realmente importa no dia a dia

O Jev tem três tipos de pergunta, que a TypeSafe chama de primitivas:

• Choice: seleciona uma opção de um conjunto definido, e a resposta traz a opção escolhida, uma probabilidade por opção e a confiança
• Score: avalia contra níveis ordenados e descritivos, e a resposta traz o score, uma probabilidade por nível e a confiança
• Noul: a pergunta sim/não, que devolve a probabilidade de a resposta ser sim, e não tem valor de confiança separado como Choice e Score

A confiança em Choice e Score é um número entre 0 e 1 derivado da distribuição de probabilidade da resposta

E aí o seu if muda de cara

Com JSON de LLM, você recebe categoria: "fraude" e trata aquilo como fato. Se quiser incerteza, você pede pro modelo escrever um campo de confiança, que é o próprio modelo escrevendo um número sobre si mesmo em texto

Com o Jev, a incerteza vem da distribuição, não de uma autoavaliação redigida

Isso abre roteamento por incerteza: confiança alta segue automático, confiança baixa escala pra humano ou volta pedindo mais contexto

Você para de tratar toda resposta como certeza e começa a calibrar threshold com número na mão

Com Noul é diferente e vale registrar: você lê a probabilidade de "sim" direto, sem um valor de confiança próprio pra consultar

O que cada caminho exige do seu código

Bora comparar o esforço real, que é onde a decisão acontece

No caminho do LLM você monta o schema, valida a resposta, trata recusa, trata truncamento e faz o parse antes de usar o dado

No caminho do Jev, o quickstart da TypeSafe mostra que a chamada combina estado e perguntas: o método system_one() recebe o state mais um dicionário de questions, e a resposta volta tipada, acessível pelo ID de cada pergunta

Sem parse, sem validação de formato, sem retry por JSON quebrado. O que aparece no lugar é outro trabalho: fazer o estado caber no orçamento de 32k

A instalação do SDK Python é direta:

pip install typesafe-sdk
# ou, se você usa uv
uv add typesafe-sdk

export TYPESAFE_API_KEY="sua-chave-aqui"

Requisito: Python 3.10 ou superior. O SDK traz TypeSafeClient (síncrono) e AsyncTypeSafeClient (assíncrono), e chama o jev-latest por padrão

O erro comum aqui é esquecer a variável de ambiente e ficar caçando problema de rede que não existe. A chave vai em TYPESAFE_API_KEY, no ambiente

Se você programa com agente, a TypeSafe também publica uma agent skill com o contexto da API: os três tipos de pergunta, padrões arquiteturais e boas práticas. No Claude Code a instalação passa pelo marketplace de plugins:

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

Em outros agentes, o caminho é npx skills add typesafe-ai/skills --skill typesafe-ai, e no modo manual você copia o diretório skills/typesafe-ai pro diretório de skills do seu agente

E já adianto um mal-entendido clássico: a própria documentação da TypeSafe diz que o Jev não é substituto do LLM que roda por trás de Claude Code, Cursor, opencode ou Copilot

O uso é outro: você escreve, com o agente, o código que chama o Jev pra decidir

Saída tipada não é blindagem: o que a pesquisa mostrou

Agora a parte que o marketing não coloca no topo da página

O claim de "não pode alucinar" é sobre geração de texto, não sobre segurança. E gente de fora já foi olhar isso

Um artigo no arXiv, "Decision Hijacking: Prompt Injection Attacks on Jev’s Typed Probabilistic Decisions", de Tiantong Wu e Wei Yang Bryan Lim (Nanyang Technological University), testou 510 casos reconstruídos do InjecAgent contra as decisões tipadas do Jev

O resultado é interessante e nada sensacionalista: conteúdo malicioso desloca as probabilidades das ações, mas raramente faz o Jev escolher o alvo do atacante

Com ataque adaptativo usando feedback de score, o sucesso em chamadas de validação novas sobe de 1,8% para 3,5%

A conclusão dos autores é a que importa: saída definida por schema muda o risco de prompt injection, não elimina

O blog da Check Point publicou um primeiro olhar próprio sobre o Jev na mesma linha: restringir a saída a ações declaradas não garante resistência a prompt injection

Marcar um documento como não confiável não mudou a crença do modelo, e a instrução explícita pra ignorar instruções embutidas reduziu as quebras de 18 para 17 em 27, o que eles classificaram como ineficaz

Então fica o recado: escolher entre os dois caminhos por segurança é escolher por motivo errado

Se o seu problema é entrada hostil, isso se trata numa camada dedicada, como detectar jailbreak antes do LLM responder, e não confiando que o tipo da saída te protege

Quando pedir JSON para o LLM continua sendo a escolha certa

Tem um monte de caso em que o Jev simplesmente não é a ferramenta, e tá tudo bem

• Você precisa de texto gerado no mesmo payload: resumo, mensagem pro usuário, explicação da decisão. O Jev não gera texto livre, ponto
• Campos abertos que não viram enum: nome extraído, endereço, trecho citado. Isso é extração, não decisão entre opções definidas
• Schema grande com objetos aninhados: quando a resposta é uma estrutura rica, e não uma resposta por pergunta
• Estado maior que o orçamento de contexto: lembra que os 32k do Jev cobrem o estado mais a pergunta mais longa. Documento gigante não cabe
• Stack já em produção e estável: com schemas cacheados por até 24 horas na Claude API, você já tem previsibilidade e custo controlado no caminho que roda hoje
• O LLM por trás do seu agente de código: a própria TypeSafe diz que o Jev não entra como drop-in replacement ali

Trocar arquitetura que funciona por hype é o jeito mais rápido de gastar sprint pra chegar no mesmo lugar 😛

Quando o Jev faz mais sentido

Agora o lado simétrico, e os casos são bem específicos

• Decisão repetida e de alto volume: classificar, rotear, aprovar, pontuar. Sempre a mesma pergunta, milhares de vezes
• Você quer probabilidade por opção pra calibrar threshold: Choice e Score entregam distribuição, e é com ela que você define onde automatiza e onde escala pra humano
• Custo e latência apertados: aqui o preço é verificável, US$ 0,042 por 1M de tokens de entrada e US$ 0 por 1M de saída. Já a afirmação de inteligência similar à de LLMs em tarefas System One sendo duas ordens de magnitude mais rápido e mais eficiente é claim do fornecedor, não benchmark independente que eu possa te mostrar
• Arquitetura híbrida: o LLM escreve, o Jev decide. É o padrão que aparece quando você usa o Jev como guardrail da saída de outro LLM, com o modelo de texto produzindo e o modelo tipado julgando

Aquele terceiro ponto merece uma pausa. Não existe, até onde eu consegui verificar, benchmark público comparando acurácia de Jev e LLM com JSON Schema na mesma tarefa de classificação

Então "é melhor" não dá pra dizer. "É diferente e tem preço listado" dá

Veredito: não é substituição, é divisão de trabalho

Não tem vencedor aqui, e forçar um seria desonesto

JSON estruturado de LLM é o caminho padrão e maduro: garante formato, aceita texto junto, roda em stack que você já conhece, e tem as exceções bem documentadas pra você tratar

O Jev é uma peça nova pra um subconjunto bem definido: decisão tipada com incerteza explícita, em volume, onde você quer distribuição e não só o valor final

O que é verificável: preço, contexto de 32k, as três primitivas, a confiança de 0 a 1 derivada da distribuição, o estado de early access desde 15 de setembro de 2026 e o Jev 1.13 ao lado do alias jev-latest

O que é claim do fornecedor: "não pode alucinar" (que é sobre não gerar texto, e a pesquisa de prompt injection mostrou que não vira blindagem) e as duas ordens de magnitude de velocidade e eficiência

Distinguir essas duas listas já te coloca à frente de metade das discussões sobre o assunto 😀

Conclusão

A régua é simples: se a chamada precisa produzir texto, fica no LLM com Structured Outputs. Se ela só precisa escolher, pontuar ou dizer sim ou não, o Jev entra na conversa

O próximo passo prático não é migrar nada. É abrir seu sistema e mapear quais chamadas são decisão pura e quais precisam de texto gerado

Provavelmente você vai achar duas ou três que são decisão disfarçada de prompt

Pega uma delas, isola, e compara com calma antes de mexer em arquitetura. Trocar tudo de uma vez por causa de um modelo em early access é pedir pra se ferrar

Até o próximo post!