Em 15 de setembro de 2026 a TypeSafe AI lançou o Jev, que ela chama de primeiro "System One model". A proposta é simples de enunciar e estranha de aceitar: é um modelo de linguagem que não devolve texto.
Você manda um estado e uma pergunta com opções fechadas. Ele devolve qual opção, a probabilidade de cada uma e um número de confiança. Nada de parágrafo, nada de JSON para parsear, nada de "às vezes ele responde em markdown".
Escrevi este post para dois públicos. Se você é dono de um sistema, pule para O que isso resolve na prática. Se você programa, o post inteiro é para você.
Resumo em 30 segundos
- Jev responde três tipos de pergunta: escolher uma opção, dar uma nota numa régua e responder sim/não com probabilidade.
- A saída é tipada e fechada. Ele não pode inventar uma opção que não está na lista — mas pode escolher a errada, e essa diferença é o ponto mais importante deste texto.
- O preço anunciado é US$ 0,042 por milhão de tokens de entrada, com saída gratuita. Latência relatada entre 70 ms e 500 ms.
- Serve para roteamento, triagem e classificação. Não serve para escrever, resumir ou conversar.
- Está em acesso antecipado, com lista de espera.
O nome vem do Kahneman
"System One" é referência ao Rápido e Devagar do Daniel Kahneman: o Sistema 1 é o pensamento rápido, automático, que reconhece um rosto ou desvia de um buraco sem deliberar. O Sistema 2 é o lento, que resolve uma equação.
Os modelos de linguagem que a gente usa desde 2023 são Sistema 2 vestido de Sistema 1: eles deliberam em texto mesmo quando a pergunta é "isso é uma reclamação de cobrança ou um problema técnico?". Pagam por essa deliberação em latência e em token.
A aposta do Jev é que a maior parte das decisões dentro de software não precisa de deliberação. Precisa de uma classificação rápida, consistente e com uma medida de quanta certeza existe.
As três perguntas que ele responde
| Primitiva | Pergunta | Devolve |
|---|---|---|
| Choice | "Qual destas opções?" | A escolhida, probabilidade de cada uma, confiança |
| Score | "Onde isso cai nesta régua?" | Nota contínua, distribuição, confiança |
| Noul | "Esta afirmação é verdadeira?" | Probabilidade de ser sim, de 0 a 1 |
E é só. Não existe uma quarta primitiva chamada "escreva um e-mail".
Como uma chamada se parece
O contrato é estado mais perguntas, numa requisição só:
{
"model": "jev-latest",
"state": "não consigo entrar na minha conta desde ontem",
"questions": {
"assunto": {
"type": "choice",
"instructions": "Sobre o que é esta mensagem?",
"criteria": {
"cobranca": "pagamento, fatura, boleto",
"acesso": "login, senha, conta bloqueada",
"produto": "algo quebrado ou funcionando errado"
}
}
}
}
E a resposta traz a distribuição inteira, não só o vencedor:
{
"choice": "acesso",
"confidence": 0.856,
"probabilities": {
"acesso": 0.856,
"produto": 0.108,
"cobranca": 0.036
}
}
A confiança não é um número solto: sai da fórmula (n × maior_probabilidade − 1) / (n − 1), onde n é a quantidade de opções. Ela normaliza pelo tamanho da lista — 60% de probabilidade entre três opções significa uma coisa, entre vinte significa outra.
Endpoint oficial: POST https://api.typesafe.ai/v1/systemone, com SDK em Python e JavaScript.
Por que isso é diferente de pedir JSON para um LLM
Essa é a pergunta que todo programador faz, e é justa. Dá para pedir JSON ao GPT com structured output. Três diferenças reais:
Uma chamada, várias perguntas, sem degradar. Você manda o estado uma vez e faz dez perguntas sobre ele. Cada pergunta é avaliada de forma independente — não existe o efeito de uma resposta contaminar a próxima, que é o que acontece quando um LLM responde tudo numa saída só. A documentação chama isso de ausência de context rot.
Num teste publicado, dez perguntas numa chamada contra dez chamadas sequenciais deram 7,5× mais rápido e 5,6× menos token de entrada — o estado vai uma vez, não dez. Nove das dez respostas foram idênticas às sequenciais, o que é a evidência de que as perguntas realmente não interferem entre si.
A probabilidade vem de fábrica. Um LLM pedindo para "dar uma nota de confiança" devolve um número inventado no meio do texto. Aqui a distribuição é a saída do modelo, não uma opinião dele sobre si mesmo. A TypeSafe diz treinar com um método que chama de RLCD — Reinforcement Learning for Calibrated Decisions — em vez do RLHF usual, e a calibragem é justamente o objetivo declarado.
O preço e a latência mudam de ordem de grandeza. US$ 0,042 por milhão de tokens de entrada, com saída gratuita. Para efeito de comparação, é uma fração do que custa uma chamada a um modelo de fronteira para responder a mesma pergunta de uma palavra.
O que isso resolve na prática
Se você tem um sistema que toma decisões a partir de texto de gente — e quase todo sistema de atendimento, vendas ou suporte tem — estas são as decisões que hoje ou são regra fixa, ou são um LLM caro:
- Para qual departamento vai este chamado?
- Isto é urgente ou pode esperar?
- O cliente está pedindo cancelamento ou só reclamando?
- Este formulário foi preenchido por um humano ou por um robô?
- Esta resposta do atendente resolveu o problema?
Nenhuma delas precisa de um parágrafo. Todas precisam de uma escolha e uma medida de certeza.
O padrão que vale copiar: portão por confiança
Este é o desenho mais útil que saiu da documentação, e ele serve mesmo que você use outro modelo.
Em vez de um limite único de confiança para tudo, o limite acompanha o tamanho do estrago:
LIMITES = {
"consultar_saldo": 0.50, # errar custa pouco
"aprovar_transferencia": 0.85,
"encerrar_conta": 0.90, # errar é irreversível
}
if resposta.confidence >= LIMITES[resposta.choice]:
executar()
else:
pedir_confirmacao_humana()
O que isso faz de bom não é técnico: transforma tolerância a risco em código versionado. Hoje, na maioria dos sistemas, o limite de "quando a máquina pode decidir sozinha" está na cabeça de alguém. Assim ele entra no diff, passa por revisão e tem teste.
O que ele não resolve — e o marketing não diz
Aqui é onde eu discordo do tom que vi em várias coberturas.
"Não alucina" é meia verdade. É correto que o Jev não pode inventar uma opção fora da lista: a saída é um conjunto fechado, e isso elimina uma classe inteira de problema — o modelo prometendo uma ação que não existe. Mas ele pode escolher a opção errada com alta confiança. Isso não é alucinação, é erro de classificação, e dá o mesmo prejuízo. A diferença é que agora você tem um número para decidir quando não confiar, o que é melhor do que nada, e não é a mesma coisa que estar certo.
Ele não substitui a regra determinística. Se o seu problema é casamento de texto com erro de digitação e você já tem um banco Postgres, o pg_trgm faz isso dentro do banco, com latência de microssegundos e custo zero. Trocar por uma chamada de rede paga só se justifica se a taxa de acerto subir de forma medida. Se ninguém mediu quanto a solução atual acerta, a conversa sobre trocar não deveria nem começar.
Os dados saem da sua infraestrutura. O texto do cliente vai para um terceiro. Isso é assunto de LGPD e, se você atende empresas, é cláusula de contrato. Não é impeditivo — é trabalho que precisa entrar na conta.
Está em acesso antecipado. Lista de espera, sem histórico de disponibilidade, sem SLA público. Construir caminho crítico em cima disso hoje é assumir um risco que não é técnico, é de fornecedor.
O número do fabricante, com a ressalva
A TypeSafe publica "193,6× mais rápido" e "244,6× mais barato" comparado a modelos de fronteira, com exemplos de 0,114 s contra 8,566 s.
Esses números são de fluxos escolhidos pelo fabricante, onde a tarefa é classificação pura. São plausíveis pelo desenho — um modelo que devolve uma escolha em vez de um parágrafo gera ordens de grandeza menos token. Mas comparar um classificador com um modelo generativo na tarefa em que o classificador foi feito para vencer não é uma medida honesta de quanto ele vai te ajudar.
O número que importa é outro: quantas decisões do seu sistema ele acerta a mais do que o que você já usa. Esse só sai medindo com o seu tráfego.
Como eu avaliaria, se fosse hoje
A ordem que eu seguiria em qualquer sistema meu:
- Medir a linha de base primeiro. Quanto a solução atual acerta? Sem isso, qualquer modelo parece bom.
- Montar o conjunto de avaliação com dado real. As decisões que o sistema já tomou, com o desfecho conhecido, são rótulo de graça.
- Rodar o modelo offline, contra esse conjunto. Sem tocar em cliente nenhum.
- Só então decidir, comparando dois números em vez de dois argumentos.
- E se entrar, entrar sugerindo para uma pessoa antes de decidir sozinho. A primeira versão de qualquer automação de decisão deveria ter um humano lendo antes.
Estou aplicando exatamente isso num chatbot de atendimento que desenvolvo. O motor hoje é determinístico e o casamento de texto livre é trigrama no Postgres. A arquitetura já tem a porta pronta para trocar o classificador sem tocar no resto — e é essa porta que torna a avaliação barata. A decisão de trocar vai sair de um número, não de um lançamento.
Vale a pena?
Se você já tem um sistema que decide a partir de texto de gente, o Jev merece uma tarde de avaliação. A categoria — modelo de decisão estruturada em vez de gerador de texto — me parece certa, e é o tipo de coisa que, funcionando, vira infraestrutura invisível.
Se você ainda não tem tráfego real, não tem nada a medir, e a resposta é esperar.
Fontes: typesafe.ai · documentação oficial · MarkTechPost — anúncio · MarkTechPost — guia prático · Cloudflare AI docs
Preços, latências e disponibilidade conferidos em 26/09/2026. Produto em acesso antecipado — confira na fonte antes de decidir.
// contato
Vamos conversar sobre o seu projeto?
Diagnóstico técnico, arquitetura e desenvolvimento sob medida para startups e empresas.
Fale comigo →