O que é o Jev IA: o modelo que não escreve nada (e por isso custa 100x menos)

Todo mundo passou três anos tentando fazer LLM devolver JSON válido. A TypeSafe olhou pro problema e perguntou outra coisa: e se o modelo simplesmente não pudesse escrever? A resposta se chama Jev, e entender o que é o Jev IA é entender uma classe de modelo que não existia até seis dias atrás.

Em 15 de setembro de 2026 a TypeSafe AI anunciou o Jev como o primeiro System One model. Ele não completa texto. Ele recebe o estado do seu programa mais um conjunto de perguntas tipadas e devolve, numa única passagem paralela, a opção escolhida, a nota na sua régua e a probabilidade de um sim. Nada de prosa, nada de parser, nada de try/catch em volta de json_decode.

Neste post: o que o Jev é de fato, por que ele não consegue alucinar (e por que isso não significa que ele não erra), a conta real do preço, e código Python que roda de verdade chamando os três primitivos.

TL;DR

• O que é: o primeiro System One model. Estado entra, decisão tipada sai. Zero geração de texto.
• Stack: jev-1.13.0 via POST /v1/systemone, SDK oficial em Python e JavaScript.
• Custo/Acesso: US$ 0,042 por milhão de tokens de input. Output é de graça. Precisa de TYPESAFE_API_KEY.
• Latência: 70ms a 500ms ponta a ponta, contra 3s a 329s dos modelos de fronteira nas comparações da própria TypeSafe.
• Link útil: docs.typesafe.ai e pip install typesafe-sdk.

O que é o Jev IA (e por que um System One model não consegue alucinar)

O nome vem do Kahneman. Sistema 1 é o julgamento rápido, intuitivo, o que você faz em um segundo olhando pra coisa. Sistema 2 é o raciocínio lento, encadeado, deliberado. Os LLMs que a gente usa desde 2023 são máquinas de Sistema 2 improvisando Sistema 1: você pede uma classificação de três opções e o modelo monta uma cadeia de raciocínio, escreve um JSON, e você reza pra chave vir com o nome certo.

O Jev inverte o contrato. A documentação oficial chama ele de "frontier-intelligence function call": estado não estruturado entra, decisão probabilística tipada sai. Você manda um state (uma string, um objeto JSON, um array de textos) e um dicionário de perguntas. Cada pergunta é avaliada em paralelo e em isolamento contra o mesmo estado, e volta como um valor que o seu código consome direto.

Agora a parte que importa: a garantia é de tipo, não de prompt.

Num LLM, "sempre responda com uma das três opções" é uma instrução. Uma instrução muito bem cumprida em 2026, mas ainda uma instrução: o modelo tem o vocabulário inteiro disponível a cada token e você está pedindo boa vontade. Se você quer entender por que isso é estrutural e não preguiça do fornecedor, o caminho é entender o que um LLM faz a cada token — e depois ver as camadas que a gente empilha pra domar structured output.

No Jev, o espaço de saída é o conjunto que você enumerou. O modelo devolve uma distribuição de probabilidade sobre as suas opções e nada fora delas. Ele não tem como inventar uma quarta categoria, não tem como devolver "tecnico " com espaço no fim, não tem como quebrar o schema no meio de um pico de tráfego. A doc é seca sobre isso: "every answer is constrained to the options you supplied".

E aqui vem a ressalva que o material de marketing não dá: não alucinar não é a mesma coisa que acertar. O Jev não consegue te entregar um valor inválido. Ele consegue, com toda a tranquilidade do mundo, te entregar o valor errado com 0,94 de confidence. A diferença é que o erro dele é um erro de decisão, que você mede com eval e trata com threshold, em vez de um erro de formato, que você trata com retry e parser defensivo. Isso é uma classe inteira de bug que sai da sua base de código. Só que a distinção entre "não pode inventar" e "não pode errar" é fina, e errar nela não estoura na sexta do deploy: estoura três meses depois, como dívida técnica no ticket que ninguém consegue explicar. Esse é o tipo de decisão de arquitetura que a gente coloca na mesa toda semana, ao vivo, no Clã Beer and Code — é pago, é assinatura, e é exatamente o ambiente que este post descreve.

O que muda quando você tira a autoregressão: 70ms, US$ 0,042/MTok e output de graça

Autoregressão é o que faz um LLM ser caro e lento: cada token de saída depende do anterior, então a resposta é serial por construção. Tire a geração da equação e três coisas mudam ao mesmo tempo.

Latência. A TypeSafe publica 70ms a 500ms ponta a ponta, e apresenta isso como 40x a 200x mais rápido que modelos de fronteira na mesma tarefa. Medições de terceiros colocam o p50 de uma pergunta única em torno de 236ms a 276ms, o que é coerente com a faixa anunciada. Em termos práticos: cabe dentro de um request HTTP sem você precisar de fila, job e webhook.

Preço. jev-1.13.0 custa US$ 0,042 por milhão de tokens de input. Output custa zero, e a TypeSafe escreve "too cheap to meter" na tabela, o que é sincero: não existe output pra medir.

A conta. Vamos fechar a planilha de um caso concreto, porque "100x mais barato" é número de manchete e manchete não paga fatura. Suponha 1 milhão de classificações por mês, 300 tokens de estado em cada uma:

Contra o frontier, 476x. Contra o modelo barato da geração atual, 47x. O "100x" do título é a média entre os dois extremos, e a conta que importa é a sua, não a minha. O detalhe que quase ninguém nota na tabela: metade da economia vem do output ser zero. Numa classificação, o JSON de volta é curto, mas a token de saída custa cinco vezes a de entrada na maioria das tabelas de preço. Aquele pedacinho some inteiro.

Choice, Score e Noul: os três primitivos com código Python rodando

A API inteira do Jev cabe em três tipos de pergunta. A doc chama eles de primitivos, e a analogia é boa: são blocos pequenos que você compõe em código, não prompts que você tenta afinar.

Instalação e primeira chamada

pip install typesafe-sdk
export TYPESAFE_API_KEY="sk-..."

O cliente lê a chave do ambiente e aponta pra jev-latest por padrão. Este código roda como está:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()

ticket = (
    "Faz três dias que tento ligar minha conta do Stripe e a integração "
    "quebra em toda tentativa. Estou perdendo venda. Preciso de ajuda urgente."
)

resposta = client.system_one(
    state=ticket,
    questions={
        "time": Choice(
            instructions="Qual time deve atender este ticket?",
            criteria={
                "cobranca": "Problemas de pagamento, fatura ou assinatura",
                "tecnico": "Bugs, erros ou falha de integração",
                "vendas": "Dúvidas de preço ou de conta comercial",
            },
        ),
        "irritacao": Score(
            instructions="O quanto o cliente parece irritado",
            criteria=[
                "Calmo, só relatando o fato",
                "Irritado, mas civilizado",
                "Muito bravo, linguagem forte",
            ],
        ),
        "e_urgente": Noul(
            instructions="A mensagem expressa urgência ou sensibilidade a tempo",
        ),
    },
)

print(resposta.answers["time"].choice)          # "tecnico"
print(resposta.answers["time"].confidence)      # 0.93
print(resposta.answers["time"].probabilities)   # {"cobranca": 0.04, "tecnico": 0.93, ...}
print(resposta.answers["irritacao"].score)      # 1.7
print(resposta.answers["e_urgente"].noul)       # 0.96
print(resposta.usage.input_tokens, resposta.usage.output_tokens)  # 118 0

Repare no último print. output_tokens é zero. Não é arredondamento: não há saída pra cobrar.

O que volta, campo por campo

choice é a opção vencedora, já como string do seu conjunto. probabilities é a distribuição inteira, o que te deixa olhar o segundo colocado antes de decidir. confidence resume o quão concentrada está essa distribuição, e a fórmula está aberta na doc:

def confidence(probabilidades: list[float]) -> float:
    n = len(probabilidades)
    pico = max(probabilidades)
    return max(0.0, min(1.0, (n * pico - 1) / (n - 1)))

print(confidence([0.93, 0.04, 0.03]))        # 0.895
print(confidence([1/3, 1/3, 1/3]))           # 0.0

Distribuição uniforme dá confidence 0. Distribuição cravada numa opção dá 1. É uma medida de "quão decidido", não de "quão certo" — e é isso que te dá um segundo eixo pra rotear.

Duas pegadinhas de nome. Noul devolve uma probabilidade de 0 a 1, não um booleano, e é o único primitivo sem campo confidence (0,5 significa "não sei", não "meio-termo"). E Score devolve um float que pode cair entre dois níveis da sua régua: 1.7 numa régua de três posições quer dizer "entre irritado e muito bravo, puxando pro segundo".

Roteando em código

O ponto do Jev não é a resposta. É que a decisão volta no formato que um if entende:

time = resposta.answers["time"]
irritacao = resposta.answers["irritacao"]
urgente = resposta.answers["e_urgente"]

if time.confidence < 0.70:
    fila_humana(ticket_id, motivo="classificação incerta")
elif time.choice == "tecnico":
    abrir_incidente(ticket_id, prioridade="alta" if urgente.noul > 0.8 else "normal")
elif time.choice == "cobranca":
    rotear_cobranca(ticket_id)

if irritacao.score > 1.5:
    marcar_para_resposta_prioritaria(ticket_id)

Os thresholds são seus, ficam versionados no repositório e mudam com um commit. Quando a prioridade do negócio mudar, você altera um número — não reescreve um prompt e reza pra não regredir outra coisa junto.

Fan-out especulativo: por que a décima pergunta é quase de graça

Este é o padrão que muda como você desenha o sistema, e é onde a arquitetura do Jev se paga.

O modelo ingere o state uma vez e avalia todas as perguntas em paralelo contra ele. Adicionar perguntas quase não mexe no tempo de resposta e custa só os tokens das perguntas novas, que são baratas. O state — que normalmente é 90% do request — você paga uma vez só.

A consequência prática é o que a doc chama de speculative fan-out: mande todas as perguntas que o seu fluxo possa precisar, inclusive as que só fazem sentido em um dos ramos, e deixe o código jogar fora o que não interessa.

questions = {
    "categoria": Choice(
        instructions="Qual a natureza deste ticket?",
        criteria={
            "bug": "Algo quebrado, erro ou falha de integração",
            "cobranca": "Cobrança, fatura, reembolso, assinatura",
            "feature": "Pedido de funcionalidade nova",
            "conta": "Login, permissão, perfil, segurança",
        },
    ),
    # especulativas: só importam se categoria == "bug"
    "severidade": Score(
        instructions="Qual a severidade do problema relatado",
        criteria=["Cosmético", "Degradado, com contorno", "Bloqueante, sem contorno"],
    ),
    "tem_passos": Noul(instructions="O usuário descreve passos para reproduzir o problema"),
    # especulativa: só importa se categoria == "cobranca"
    "pede_reembolso": Noul(instructions="O usuário pede reembolso ou estorno explicitamente"),
}

Num LLM, essa lista custaria quatro chamadas ou um mega-prompt que degrada com o tamanho. No Jev, sai numa chamada e o fluxo inteiro resolve num round trip.

E tem número de terceiro pra isso. O cookbook de perguntas paralelas roda 13 perguntas (8 Noul, 2 Choice, 3 Score) sobre o artigo da Wikipédia do GDPR — uns 54 mil caracteres — comparando uma chamada com 13 perguntas contra 13 chamadas de uma pergunta: 12,2x mais barato e 10x mais rápido, com as respostas idênticas. O desvio padrão entre repetições foi exatamente 0,0 na maioria das perguntas, nos dois formatos. Batelada não adiciona ruído porque cada pergunta é avaliada em isolamento: uma não é contexto da outra.

Isso também mata um hábito. Num LLM, empilhar pergunta no mesmo prompt polui a janela e derruba a qualidade de todas. Aqui não. As perguntas não se veem.

As 5 armadilhas do Jev: literalidade, aritmética, datas, context rot e zero geração

A TypeSafe publica uma página só de defeitos conhecidos, a jaggedness do jev-1.13, revisada em 17/09/2026. É o documento mais honesto do site e o que você deveria ler antes de colocar isso em produção.

1. Literalidade extrema. "O jev-1.13 responde a pergunta que você escreveu, não a que você quis dizer." Escopo, negação e condição implícita são lidos ao pé da letra. A regra prática da doc é ótima: quando você olha uma resposta errada e se pega explicando o que realmente queria dizer, aquela explicação é a metade que faltava na instrução. Escreva a condição exata, e ponha os casos de borda nos criteria.

2. Zero aritmética. Ele não é calculadora e não conta. Caracteres numa palavra, ocorrências num texto, itens numa lista: o erro cresce com o tamanho. A saída é iterar em código e fazer uma pergunta por item:

itens = ["typesafe", "maçã", "california", "banana", "laranja"]
LIMIAR = 0.5

resultado = client.system_one(
    {"itens": itens},
    {
        f"item_{i}": Noul(instructions=f"`itens[{i}]` é o nome de uma fruta?")
        for i in range(len(itens))
    },
)

total = sum(resultado.nouls[f"item_{i}"].noul > LIMIAR for i in range(len(itens)))

É o fan-out de novo: cinco perguntas, uma chamada, e a soma acontece em Python, onde soma é confiável.

3. Datas são texto pra ele. O Jev lê data como string, não como quantidade ordenada. Perguntar qual vem antes, quantos dias separam ou se cai dentro de uma janela é pedir erro — e piora com formato misto e referência relativa. O padrão é partir o trabalho: extração é julgamento (mês é um conjunto fechado de 12 opções, dia de 31, então vira Choice com uma opção explícita de "não informado"), aritmética é código.

4. Context rot. A acurácia cai conforme o state cresce com conteúdo irrelevante à decisão. Detalhe solto vira distrator. Filtre antes, mande só os campos que a pergunta precisa. O limite duro também existe: 64k tokens por request no total, e 32k para o state mais a maior pergunta.

5. Ele não gera nada. Nem um pouco. Parece óbvio depois de todo o post, mas é a armadilha que mais pega gente: dá pra forçar geração encadeando Choice, e "isso não vai funcionar bem e vai ser muito lento". Se você precisa de texto, precisa de outro modelo. O Jev decide; quem escreve é outro.

Bônus que economiza uma tarde: não espere invariantes estruturais. A mesma pergunta como Noul e como Choice de sim/não volta com números que não conversam — a doc mostra noul 0,22 contra probabilities["yes"] 0,01 no mesmo ticket. E P(x) mais P(não x) não soma 1. Não carregue threshold calibrado num primitivo pro outro.

FAQ rápido

Dá pra trocar o meu chatbot pelo Jev? Não. Ele não escreve resposta nenhuma. O papel dele é decidir o que o seu código faz em seguida: qual rota, qual severidade, qual passagem vale a pena mandar pro modelo que escreve. Quem conversa com o usuário continua sendo um LLM.

Ele funciona bem em português? A doc é direta: inglês é a língua primária de treino e onde a acurácia está melhor hoje. Outras línguas são suportadas, mas não igualmente bem. Teste no seu conteúdo e use confidence como rede: abaixo do seu limiar, manda pra revisão humana em vez de agir.

Posso mandar imagem, áudio ou PDF? Não. Input é texto: string, objeto JSON ou array de textos. Qualquer outra coisa precisa virar texto ou campo estruturado antes. Rate limit atual: 250 mil tokens por segundo e 1.200 requests por minuto, e a TypeSafe avisa que esses números estão se movendo.

Existe alternativa open source? Existe: a Laya, Apache 2.0, ~0,4B de parâmetros e pesos abertos no Hugging Face, faz o mesmo jogo de perguntas tipadas com probabilidades calibradas — a comparação honesta entre as duas está em Laya vs Jev.

O que fazer com isso

O modelo Jev não é "um LLM mais rápido". É a admissão de que a gente vinha usando a ferramenta errada pra metade do trabalho: pedindo raciocínio deliberado e prosa pra um sistema que só precisava responder "qual destes três" em 80 milissegundos. Três anos de engenharia de structured output foram, em boa parte, um workaround de arquitetura.

O que isso muda no seu sistema é uma pergunta de fronteira: onde termina a decisão e começa a redação. Toda vez que o seu pipeline chama um modelo de fronteira só pra receber de volta uma string de um conjunto de cinco, você está pagando geração pra não gerar nada.

Onde exatamente vale fazer essa troca é assunto de um post inteiro, e ele existe: Substituir LLM por Jev: 10 lugares onde a migração se paga em uma semana.