Jev em tempo real: o que dá para construir com resposta de 70ms a 500ms?

Colocar um modelo no caminho crítico de uma interação sempre custou caro em tempo

Você aperta o botão, o usuário espera, o modelo pensa, e aí a tela volta a responder

O Jev, da TypeSafe, aparece exatamente pra brigar com esse problema: ele não escreve resposta, ele devolve uma decisão tipada (uma escolha, uma nota ou uma probabilidade de sim/não) em 70ms a 500ms ponta a ponta, segundo a própria empresa

Então a pergunta deste post não é "o Jev é bom?"

É outra, bem mais prática: o que cabe dentro dessa janela de tempo, e o que continua não cabendo?

Por que o Jev responde nessa faixa de tempo

A sacada é arquitetural, e vale entender o porquê antes do como

Um LLM comum é autorregressivo: ele gera token, olha o que gerou, gera o próximo, e assim por diante

Cada token é uma ida e volta interna, e é isso que faz o tempo de resposta crescer junto com o tamanho da saída

O Jev não faz isso

Ele usa um amostrador paralelo e gera toda a saída em uma única passagem, em vez de token a token

É essa escolha que sustenta a faixa baixa de latência que a TypeSafe divulga na página oficial de lançamento do Jev

O treino também é próprio: a empresa chama o método de Reinforcement Learning for Calibrated Decisions (RLCD)

A palavra importante ali é calibrated

A saída não é um texto que você precisa parsear na unha, é um valor tipado que já sai pronto pro seu if

Curso Recomendado

Curso de Jev: Sistemas Mais Inteligentes, Rápidos e Robustos

Desenvolva sistemas mais inteligentes, rápidos e robustos com Jev

Conhecer curso

Quem está por trás disso?

A TypeSafe AI saiu do modo furtivo em setembro de 2026 com 40 milhões de dólares, em São Francisco

Segundo a TechCrunch, foi fundada em 2024 por Diogo Almeida (ex-pesquisador da OpenAI, envolvido no ChatGPT e no RLHF), junto com Erik Gafni e Sasha Sheng

A empresa afirma que o Jev é de 40 a 200 vezes mais rápido que um LLM em trabalho de decisão

Guarda esse detalhe com carinho: esse número é da própria TypeSafe, não é medição independente 🙂

Orçamento de latência: o que cada faixa de tempo permite

Antes de escolher modelo, escolhe o orçamento

Orçamento de latência é quanto tempo a sua interação tolera esperar ANTES de o usuário (ou o robô, ou o jogo) perceber que travou

Um laço de controle de 10Hz tem 100ms por volta, ponto

Um chat tolera segundos, porque a pessoa lê enquanto o texto aparece

São mundos diferentes, e é por isso que dá pra montar uma régua:

No benchmark próprio da TypeSafe, com quatro fluxos de trabalho, o Jev roda um caso em cerca de 0,4 segundo e custa cerca de US$ 0,0004 por caso

Os LLMs comparados no mesmo teste levaram de 10 a 38 segundos e custaram de US$ 0,0304 a US$ 0,1761 por caso

Olha o salto de faixa: é o mesmo trabalho pulando da linha de baixo da tabela pra linha de cima

Agora o disclaimer honesto, de novo: essa avaliação é autodeclarada

A própria TypeSafe registra que os testes rodaram das máquinas da equipe na Costa Oeste e que os fluxos foram construídos pelo próprio time

Não existe reprodução independente em larga escala publicada

Não significa que está errado, significa que o número é da casa

O que dá para construir dentro desse orçamento

Aqui fica concreto

Todo caso abaixo tem a mesma cara: decisão repetitiva, resposta curta, tipada, dentro de um laço

Laço de controle em tempo real

A demo que rodou a internet foi o Jev jogando Doom

Detalhe que muita gente pula: ele reage a estado de jogo entregue como texto estruturado, não a imagem, a cerca de 10 decisões por segundo

As outras demos iniciais seguem a mesma lógica de laço apertado: bot de Minecraft, simulação estilo direção autônoma, jogo estilo Subway Surfers e um drone simulado em pista de obstáculos

Primitiva natural aqui: Choice, escolhendo uma ação de um conjunto fixo (andar, virar, atirar, frear)

Gate de segurança em comando

Esse é o caso que mais gosto, porque é chato e ninguém quer pagar 30 segundos por ele

Um engenheiro da Vercel relatou à TechCrunch que, ao trocar o classificador de segurança de comandos por Jev, os resultados vieram de 5 a 18 vezes mais rápido

É aquele check antes de deixar o agente rodar os rm -rf da vida

Primitiva: Noul, probabilidade de o comando ser perigoso, com limiar aplicado no seu código

Classificação e roteamento

CTO da Bryo AI contou à TechCrunch que, em classificação de e-mails corporativos, o Gemini foi um pouco mais preciso, porém de 10 a 20 vezes mais caro que o Jev

Essa frase resume a decisão inteira: você troca um tiquinho de acurácia por ordem de grandeza em tempo e custo

Se o caso aceita esse trade, ótimo

Se não aceita, o Jev não é o lugar

Primitiva: Choice pra categoria, Score quando você precisa de posição em uma escala descrita em passos (urgência, severidade, prioridade)

Moderação antes de exibir

Mostrar conteúdo e tirar depois é ruim

Segurar a tela por 20 segundos também é ruim

Na faixa de 70ms a 500ms, dá pra decidir antes de pintar o componente

E quando a parte pesada do fluxo continua sendo texto de LLM, aí você combina as duas coisas: decisão rápida no gate e entrega da resposta em streaming pro usuário sentir movimento na tela

Primitiva: Noul com threshold, ou Choice quando existem categorias fixas de bloqueio

O que continua não cabendo (e por quê)

Agora a parte que todo post empolgado esquece de escrever

O Jev não escreve resposta, não produz código, não resume documento e não explica o raciocínio da decisão

A saída é exclusivamente tipada, sem texto livre e sem justificativa

Se o seu produto precisa mostrar "por que" a decisão foi tomada, você vai ter que construir esse porquê por fora

E tem mais, vindo da própria documentação

Jaggedness: onde o jev-1.13 vai mal

A TypeSafe publica uma página de jaggedness por versão, listando os pontos fracos do modelo

No jev-1.13 os pontos listados são:

• interpretação literal do enunciado
• contas e contagem
• perguntas que exigem múltiplos saltos de raciocínio

Inconsistência por fraseado

A mesma página registra um caso que dá arrepio

Na mesma ticket, um Noul sobre pedido de reembolso deu 0,22, enquanto um Choice sim/não deu 0,01 para sim e 0,99 para não

E uma pergunta mais a negação dela somaram 1,19

Tradução prática: a forma como você escreve a pergunta muda o resultado

Então versionar prompt de pergunta e testar variações não é frescura, é requisito

Acurácia

No benchmark da própria TypeSafe, o Jev marca 67,8%

O GPT-5.6 Terra marca 67,9%, o Opus 5 marca 73,1% e o GPT-5.6 Sol marca 74,1%

Ou seja: ele empata com um e perde pros bons

O argumento dele não é ser o mais certeiro, é ser certeiro o suficiente por 0,4 segundo

Outros limites de entrada

O Jev aceita texto em linguagem natural, e o inglês é a língua principal de treino, onde a acurácia está melhor hoje

Se o seu estado e as suas perguntas estão em português, isso entra na conta do risco

E o acesso segue em early access por lista de espera desde o lançamento, com chaves emitidas no console da TypeSafe

Como colocar a decisão no caminho crítico sem estourar o orçamento

Bora pra parte prática

1. Instale o SDK Python oficial

A instalação usa o índice de pacotes da própria TypeSafe e exige Python 3.10 ou superior:

pip install "typesafe-sdk>=0.5.7" --extra-index-url https://pypi.typesafe.ai/

O erro comum deste passo: rodar o pip install sem o --extra-index-url e tomar um "package not found" achando que o nome do pacote está errado

2. Configure a chave de API

As chaves saem do console da TypeSafe, e o SDK lê da variável de ambiente:

export TYPESAFE_API_KEY="sua-chave-aqui"

O erro comum deste passo: commitar a chave dentro do código porque "é só um teste"

Já vi gente se ferrar feio com isso

3. Importe as primitivas

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()

O client lê a TYPESAFE_API_KEY do ambiente e usa a rota jev-latest por padrão, que hoje resolve para jev-1.13

O erro comum deste passo: fixar mentalmente o comportamento do jev-latest como se fosse versão travada

Se você precisa de resultado estável em produção, aponta pra versão explícita

4. Escolha a primitiva certa pro seu problema

São três:

• Choice: uma opção de um conjunto fixo
• Score: posição em uma escala descrita em passos
• Noul: probabilidade de 0 a 1 de a resposta ser sim

O erro comum deste passo: usar Noul quando o problema é claramente categórico

Lembra do caso documentado com 0,22 contra 0,01/0,99? Primitiva diferente, resultado diferente, mesma pergunta

5. Aplique o threshold no seu próprio código

O Noul devolve um número de 0 a 1, e a documentação orienta que o corte vire decisão dura no seu lado:

LIMIAR_BLOQUEIO = 0.8

if probabilidade_comando_perigoso >= LIMIAR_BLOQUEIO:
    bloquear()
else:
    executar()

O erro comum deste passo: chutar 0.5 porque "é o meio"

O limiar é decisão de produto, e depende do custo de errar pra cada lado

6. Agrupe N perguntas contra o mesmo estado em UMA chamada

Esse é o truque que mais economiza tempo e dinheiro

No Jev, todas as perguntas de uma mesma requisição são avaliadas em paralelo contra o mesmo estado, e cada pergunta extra custa apenas os próprios tokens

No cookbook oficial com 13 perguntas sobre um artigo da GDPR, juntar tudo em uma chamada saiu 12,2 vezes mais barato e 10 vezes mais rápido, sem mudar as respostas

O erro comum deste passo: fazer um for em cima da lista de perguntas e disparar uma chamada por item

Funciona, mas você paga o estado inteiro de novo a cada volta

7. Respeite os dois limites de contexto ao mesmo tempo

O jev-1.13 tem dois tetos simultâneos:

• estado mais TODAS as perguntas dentro de 64 mil tokens
• estado mais a PERGUNTA MAIS LONGA dentro de 32 mil tokens

O erro comum deste passo: olhar só o total de 64K, empilhar 40 perguntas contra um estado gordo e estourar o segundo limite sem entender o motivo

São dois contratos, não um

8. Se for chamar direto pela API, use o endpoint único

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "model": "jev-latest", ... }'

É o mesmo endpoint pra todos os modelos: quem decide qual atende é o campo model da requisição

O erro comum deste passo: procurar uma URL diferente por modelo e perder tempo caçando rota que não existe

Vale colocar o Jev no caminho crítico?

Vou de veredito por cenário, porque a resposta muda bastante

Vale a pena quando: a decisão é tipada, repetitiva e o laço é apertado

Gate de segurança, moderação síncrona, roteamento, classificação de alto volume, controle de agente em loop

Nesses casos o preço ajuda muito: US$ 0,042 por milhão de tokens de entrada, com tokens de saída gratuitos

Saída de graça faz sentido quando a saída é literalmente um número ou um enum, né? 😀

Mas coloca fallback

Se a chamada estourar o orçamento de tempo, o seu código precisa ter um caminho padrão pronto, senão você trocou latência alta por indisponibilidade

Não vale quando: a resposta precisa de texto, de explicação ou de raciocínio encadeado

O modelo não escreve, não justifica, e a própria documentação admite fraqueza em contas, contagem e múltiplos saltos

Forçar isso é usar chave de fenda como martelo

E fica valendo o alerta de sempre: os números de velocidade, custo e acurácia vêm da avaliação da própria TypeSafe

Os relatos da Vercel e da Bryo AI são relatos de usuários à imprensa, não medição controlada

O jeito certo de decidir é medir com a SUA carga

Pra quem já brinca com esse tipo de laço, a lógica é bem parecida com a de testar interrupção de voz em tempo real: não adianta olhar só a média, o que dói é a cauda

Vídeo: contexto sobre arquiteturas de IA

Pra pegar contexto sobre modelos que trabalham de forma diferente do LLM tradicional, tem um vídeo no canal sobre a Sakana Fugu que serve de material introdutório

Próximo passo

Se você chegou até aqui, o exercício é simples e dá pra fazer hoje

Abre o seu fluxo e marca quais pontos são decisão, não geração de texto

Cada um desses pontos é candidato a virar Choice, Score ou Noul

Depois mede o orçamento de latência real de cada um: quanto tempo aquela etapa consome hoje, e quanto a interação de fato tolera

Com esses dois mapas na mão, a conversa deixa de ser hype e vira arquitetura

E como o acesso ainda é early access por lista de espera, entrar na fila cedo é o que te dá chance de validar com carga de verdade em vez de validar com benchmark dos outros

Qualquer coisa que rolar aí, bora trocar uma ideia

até o próximo post! 🙂