Jev, da TypeSafe: como usar e auditar um modelo que só responde o que você permite

A coisa mais interessante no Jev (abre em nova aba) não é a velocidade nem o preço. O modelo não gera texto. Você declara de antemão quais respostas são possíveis e ele devolve uma delas, junto com probabilidades. A TypeSafe lançou o modelo em 15 de setembro de 2026, em acesso antecipado, depois de dois anos operando em sigilo. Em pouco mais de um mês já existe uma versão nova, uma alternativa open source da Cloudflare que fala a mesma API e uma lista de vinte concorrentes circulando.

Esse formato muda o que significa "testar um modelo". Você não avalia se a redação ficou boa. Você confere se a etiqueta escolhida está certa e se a probabilidade que veio junto merece confiança. Este guia trata dessa segunda parte, que é onde a maioria das integrações vai errar.

O que a TypeSafe de fato documenta

A empresa chama a categoria de System One Models, em referência à distinção de Daniel Kahneman entre pensamento rápido (Sistema 1) e lento (Sistema 2). O modelo recebe um estado em linguagem natural e devolve decisões tipadas. Não escreve respostas, não produz código e não explica o próprio raciocínio.

A documentação de conceitos (abre em nova aba) define três primitivos para descrever as respostas permitidas:

• Choice: escolher uma opção entre várias;
• Score: uma posição numa escala ordenada;
• Noul: probabilidade de verdadeiro/falso.

Os limites práticos ficam na página de modelos (abre em nova aba):

Mais três pontos pesam na decisão de adotar. Os pesos são os mesmos para todas as contas, sem fine-tuning nem LoRA com dados do cliente. O modelo não é treinado com as suas requisições nem com as respostas. E o inglês é a língua principal de treino: segundo a documentação, outras línguas são tratadas, mas não com a mesma qualidade, e a orientação é testar qualquer carga que não esteja em inglês.

O que "não alucina" quer dizer, e o que não quer

O post de lançamento afirma que o Jev "não pode alucinar". Em sentido estrito, faz sentido: como o espaço de saída é fechado, o modelo não inventa um rótulo inexistente, um campo JSON malformado ou uma categoria fora da lista. Para quem já escreveu parser defensivo em cima de saída de LLM, isso elimina uma classe inteira de bug.

O modelo continua podendo escolher a opção errada, e com probabilidade alta. A própria documentação diz que a calibração é medida sobre grupos de previsões e não garante que uma resposta individual esteja correta. O problema deixa de ser "o modelo inventou algo" e passa a ser "o modelo errou com confiança". O segundo é mais fácil de medir e mais fácil de ignorar.

Quando vale a pena e quando não

O caso bom é uma decisão com conjunto de respostas fixo, volume alto e sensibilidade à latência: roteamento de tickets, triagem de incidentes, classificação de intenção, sinalização de risco num formulário, escolher qual ferramenta um agente deve chamar. O custo também ajuda. Um milhão de decisões com 500 tokens de entrada cada somam 500 milhões de tokens, o que dá US$ 21 pela tabela atual, já que a saída não é cobrada.

Não vale a pena nestes casos:

• Você precisa de explicação ou texto. O modelo não fornece nenhum dos dois.
• A entrada tem imagem, áudio ou vídeo. Não há suporte.
• Você precisa adaptar o modelo aos seus dados. O Jev não aceita fine-tuning. A Cloudflare oferece fine-tuning por RL para a Clef.
• O conteúdo é majoritariamente em português e você não tem como medir. A documentação não promete nada específico para português.
• Há exigência de residência de dados. A documentação não lista regiões de processamento, e o post de lançamento diz que o serviço fica na Costa Oeste dos EUA.

Sobre o preço, vale ler o que a própria TypeSafe escreveu: a sustentabilidade da tabela não está comprovada, e a empresa diz esperar que ela caia. O valor é cobrado em dólar. Faça o orçamento sabendo disso.

Pré-requisitos

Passo a passo

1. Feche o espaço de respostas antes de escrever qualquer código

Escolha o primitivo pela natureza da decisão, não pela comodidade. "Qual fila recebe este ticket" é Choice. "Quão urgente é, numa escala ordenada" é Score. "Este texto contém dado pessoal sensível" é Noul. Se a escala tem ordem, use Score: tratar urgência 1 a 5 como cinco categorias soltas joga fora a informação de que 4 está mais perto de 5 do que de 1.

Os nomes das opções contam. O modelo lê linguagem natural, então faturamento_contestacao comunica mais do que CAT_07.

2. Monte o conjunto de avaliação antes da primeira chamada

Separe algumas centenas de casos reais, rotulados por quem conhece o domínio. Se a sua operação é em português, o conjunto também precisa ser. Se você tem a mesma base em inglês, rode as duas versões: a diferença de acerto entre elas mostra quanto você perde por não estar na língua principal de treino.

3. Fixe a versão explicitamente

O detalhe que mais pega gente: jev-latest não é a versão mais nova. Ela aponta para jev-1.13.0, a última estável e padrão do SDK. A 1.14.0, de 14 de outubro, está em jev-preview. Em produção, use o identificador completo (jev-1.13.0) em vez do alias. Assim, quando o alias mudar de destino, seu sistema não muda de comportamento sem você saber. Rode a 1.14.0 em paralelo contra o mesmo conjunto antes de migrar.

4. Faça a chamada respeitando os limites

As requisições vão para POST /v1/systemone ou passam por um dos SDKs, com o modelo no campo model. A entrada pode ser uma string, um objeto JSON ou um array de textos. A estrutura exata para declarar Choice, Score e Noul está na documentação da TypeSafe. Copie de lá em vez de adivinhar nomes de campo.

Mantenha cada pergunta abaixo de 32k tokens e a requisição inteira abaixo de 64k. O cabeçalho de contexto longo existe, mas o nome dele (Danger-Zone) já avisa: mais lento e menos preciso, segundo a própria documentação. Antes de ligá-lo, tente cortar a entrada. Para classificar um e-mail, quase nunca você precisa da thread inteira.

5. Guarde tudo o que voltou

Registre o rótulo escolhido, a probabilidade, a confiança, a versão exata e a latência medida no seu cliente. Sem isso, o passo de verificação não existe.

6. Defina um limiar e um destino para os casos abaixo dele

O valor do Jev está nas probabilidades. Use-as. Acima do limiar, a decisão segue automática. Abaixo, vai para um humano ou para um modelo mais caro. O número certo sai da sua curva de cobertura, mostrada na próxima seção, e não de intuição.

7. Trate 429 como evento normal

O limite é por organização, então dois serviços da mesma empresa competem pela mesma cota. Implemente retry com backoff exponencial e monitore a taxa de 429. Esse tipo de falha costuma aparecer só no primeiro pico de tráfego.

Como verificar

São três coisas separadas: o modelo acerta? A probabilidade dele significa o que diz? E a latência no seu ambiente bate com a anunciada?

Acerto e calibração

Exporte as respostas para um CSV com as colunas previsto, gabarito e prob (a probabilidade da opção escolhida; para Noul, a probabilidade de "verdadeiro", comparada com o gabarito booleano). O script abaixo é Python puro e não depende da API da TypeSafe:

import csv

def carregar(caminho):
    linhas = []
    with open(caminho, newline="", encoding="utf-8") as f:
        for r in csv.DictReader(f):
            linhas.append((float(r["prob"]), r["previsto"] == r["gabarito"]))
    return linhas

def calibracao(linhas, n_faixas=10):
    faixas = [[] for _ in range(n_faixas)]
    for p, acertou in linhas:
        i = min(int(p * n_faixas), n_faixas - 1)
        faixas[i].append((p, acertou))
    total = len(linhas)
    ece = 0.0
    for i, faixa in enumerate(faixas):
        if not faixa:
            continue
        conf = sum(p for p, _ in faixa) / len(faixa)
        acc = sum(a for _, a in faixa) / len(faixa)
        ece += len(faixa) / total * abs(conf - acc)
        print(f"{i/n_faixas:.1f}-{(i+1)/n_faixas:.1f}  n={len(faixa):4d}  "
              f"conf={conf:.2f}  acerto={acc:.2f}")
    brier = sum((p - a) ** 2 for p, a in linhas) / total
    print(f"ECE={ece:.3f}  Brier(top-1)={brier:.3f}")

def cobertura(linhas, limiares=(0.5, 0.7, 0.8, 0.9, 0.95)):
    total = len(linhas)
    for t in limiares:
        sel = [a for p, a in linhas if p >= t]
        if sel:
            print(f"limiar={t:.2f}  cobertura={len(sel)/total:.1%}  "
                  f"acerto={sum(sel)/len(sel):.1%}")

dados = carregar("respostas_jev.csv")
calibracao(dados)
cobertura(dados)

Como ler o resultado: num modelo bem calibrado, a faixa 0,8–0,9 acerta perto de 85% das vezes. Se ela acerta 60%, a probabilidade está inflada e o limiar precisa subir. A função cobertura mostra o custo de cada limiar: quantos casos seguem automáticos e com que acerto. Escolha o ponto que o seu negócio tolera.

Rode o script separadamente por idioma e por classe. Uma calibração boa no agregado pode esconder uma classe rara em que o modelo erra sempre com confiança. E, como a TypeSafe diz que a calibração vale para grupos, um grupo de 12 exemplos não informa nada.

Latência medida de onde você está

O post de lançamento promete de 70 ms a 500 ms ponta a ponta. A mesma página avisa que as avaliações publicadas foram rodadas de laptops na Costa Oeste americana, onde fica o serviço. Para quem chama a partir do Brasil, a ida e volta pela rede soma-se a esse número. Meça p50 e p95 no seu cliente, com payloads do tamanho real. Na rodada da Cloudflare, a mediana do Jev foi de 524,1 ms, já acima do teto anunciado.

Desconfie dos multiplicadores

A home da TypeSafe fala em 193,6x mais rápido e 444,6x mais barato. O post de lançamento explica de onde vêm esses números: avaliações de workflow cuja referência é a média de GPT-6 Astra e Fable 5.1. A própria empresa admite que isso favorece OpenAI e Anthropic e que os valores devem estar no topo da faixa. A comparação que interessa é contra o que você usa hoje, no seu conjunto.

As alternativas: o que dá para checar

A lista do MarkTechPost, de 17 de outubro, fala em pelo menos vinte alternativas em cerca de quatro semanas, de Cloudflare, OpenAI, Perplexity, Liquid AI, Strands Labs (da AWS) e desenvolvedores independentes. O próprio artigo avisa que a maior parte dos números é autodeclarada, que as suítes não são comparáveis entre si e que a tabela multimodelo de terceiros vem da Respan, que vende um modelo concorrente.

A alternativa com anúncio próprio e números publicados é a Clef, lançada pela Cloudflare (abre em nova aba) em 1º de outubro em duas versões, Clef e Clef-flash. As duas rodam no Workers AI, são compatíveis com a API do Jev e estão no Hugging Face sob Apache 2.0. A Clef tem encoder de visão e aceita imagens. A Cloudflare anunciou ainda um produto de fine-tuning por RL. As bases são Qwen3.8-27B congelado (Clef) e Qwen3.5-9B (Clef-flash), com adaptadores de rank 256 e uma etapa de pontuação não autorregressiva.

Os números abaixo foram medidos pela Cloudflare:

O retrato é mais equilibrado do que a manchete "Clef supera Jev" sugere. A Clef vence com folga em classificação de intenção bancária e, ainda segundo a Cloudflare, em processamento de faturas e incidentes de segurança. O Jev lidera em decidir quando chamar uma ferramenta, em recuperação e em observabilidade de traces de agente. Na latência, a Clef-flash fica uma ordem de grandeza abaixo do Jev nessa rodada.

Um detalhe para não ser enganado: a Cloudflare compara a janela de 64k da Clef com "32k do Jev". A documentação da TypeSafe diz 64k por requisição e 32k por pergunta. Ao que parece, a Cloudflare comparou o limite por pergunta. Confira na documentação de cada um antes de dimensionar.

Das demais, os dados vêm só da lista. A Decisions API da OpenAI teria entrado em beta pública em 6 de outubro, apenas no gpt-6-luna, a US$ 0,10 por milhão de tokens de entrada, sem compatibilidade com a API do Jev e sem benchmarks publicados. O Strands Decider teria cerca de 1,9 bilhão de parâmetros sobre Qwen3.5-2B-Base, sob Apache 2.0, com 180 de 231 (77,9%) no JevBench público, segundo o relatório do próprio projeto. Trate esses dados como ponto de partida para procurar a documentação de cada um, não como especificação.

Na prática, a compatibilidade de API da Clef é o argumento mais forte para começar pelo Jev sem medo de ficar preso. Se o seu código fala POST /v1/systemone, dá para rodar o mesmo conjunto de avaliação contra as duas e decidir pelos seus próprios números. Com a OpenAI, segundo a lista, isso exigiria outra integração.

Erros comuns

• Usar jev-latest achando que é a versão mais nova. É a 1.13.0. A 1.14.0 está em jev-preview.
• Avaliar só em inglês e colocar em produção em português. A documentação diz que outras línguas não têm a mesma qualidade. Meça a diferença.
• Ler a probabilidade de uma resposta isolada como garantia. A calibração vale para o agregado. Um 0,97 isolado pode estar errado.
• Despejar centenas de categorias numa pergunta só. O limite é 255. Acima disso entra o esquema em dois estágios, e você precisa avaliar esse fluxo também.
• Ligar o contexto longo por padrão. O cabeçalho custa o mesmo por token, mas a própria TypeSafe diz que o resultado fica pior e mais lento.
• Tratar Score como Choice. Escalas ordenadas perdem informação quando viram categorias soltas.
• Confiar na latência e nos multiplicadores do marketing. Foram medidos da Costa Oeste, contra uma referência que a empresa admite ser enviesada.
• Comparar benchmarks entre fornecedores como se fossem a mesma régua. Cada empresa roda a própria suíte, e quem publica a tabela costuma vencer nela.
• Esperar que o modelo aprenda com o seu uso. Os pesos são os mesmos para todas as contas, e suas requisições não entram no treino. Se você precisa de adaptação, isso aponta para a Clef.

O conjunto rotulado, o script de calibração e a medição de latência servem para o Jev, para a Clef e para qualquer uma das outras dezoito. Monte essa base primeiro, porque é ela que vai mostrar qual modelo entrega o que promete no seu caso.