Como usar o Jev para decidir se a notificação vai agora, entra no resumo ou não vai?

Fala aí, beleza? A TypeSafe AI soltou o Jev, o primeiro modelo do que eles chamam de System One, e ele não gera texto: ele devolve decisão tipada com probabilidade calibrada

E tem um problema no mundo real que parece feito sob medida pra isso: a fadiga de notificação

Todo app que manda push decide, dezenas de vezes por minuto, se interrompe a pessoa AGORA, se guarda aquilo pro resumo das 19h, ou se simplesmente não manda nada

Na prática essa decisão vira uma de duas coisas: um monte de if aninhado que ninguém mais entende, ou uma chamada de LLM generativo que custa caro demais pra rodar no caminho de envio

O Jev tenta ocupar exatamente esse meio: você manda o estado (quem é o usuário, o que aconteceu, o que já foi mandado nas últimas horas) e recebe de volta uma das opções que VOCÊ definiu, com um número de confiança que o seu código consegue usar

Bora ver como monta isso?

Por que essa decisão precisa ser barata e rápida

Pensa no caminho de envio como um orçamento de latência

O evento chegou, o worker pegou, e tem um tempo curtíssimo até o push sair. Se a decisão de "manda ou não manda" custa meio segundo e alguns centavos, ela some no meio da conta quando você multiplica por milhão de eventos

A TypeSafe divulga uma faixa de latência ponta a ponta de 70 a 500 ms pro Jev. Num cookbook próprio deles, uma execução reportou média de round-trip de 111 ms usando a rota jev-latest (que resolveu pra jev-1.13.0)

O preço ajuda a fechar a conta: US$ 0,042 por 1 milhão de tokens de entrada, e US$ 0,00 na saída

Saída gratuita faz sentido quando tu lembra o que sai: não é um parágrafo, é uma escolha e um número

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

Agora a parte honesta, porque aqui é onde o hype costuma escorregar

Os números de manchete que circularam (até 193x mais rápido e cerca de 444x mais barato em classificação) são benchmark da própria TypeSafe, e o anúncio deles já traz a ressalva de que esperam que isso esteja "na ponta alta dos ganhos do mundo real". Testes independentes mediram ganhos bem menores, na faixa de poucas vezes a dezenas de vezes

Ou seja: continua sendo interessante pro caminho de envio, só não compra a régua do marketing como se fosse a sua

E não existe dado público de latência ou custo do Jev medido especificamente em pipeline de push. Essa parte tu vai ter que medir no teu ambiente, não tem jeito

O que você precisa antes de começar

Lista curta:

• Uma chave de API na variável de ambiente TYPESAFE_API_KEY
• O SDK oficial em Python (pip install typesafe-sdk, ou uv add typesafe-sdk se tu usa uv) ou o SDK oficial em JavaScript
• Ou, se preferir HTTP na unha, qualquer cliente que mande POST com header Authorization: Bearer <API_KEY> e Content-Type: application/json

Tome cuidado com o acesso, porque esse ponto mudou rápido

A TypeSafe abriu cadastro direto em 20/09/2026 e pausou novos cadastros em 22/09/2026 por excesso de demanda. Eles afirmam que as contas existentes seguem funcionando e que estão trabalhando pra reabrir, mas até 24/09/2026 não teve confirmação de reabertura

Se tu não tem conta, dá pra alcançar o modelo por gateway de terceiro: o OpenRouter lista typesafe/jev-1.13 e jev-latest, e o Vercel AI Gateway expõe como typesafe-ai/jev

Último detalhe de dimensionamento: a janela de contexto do Jev 1.13 é de 32.000 tokens por requisição

Guarda esse número, porque ele é justamente o que vai te impedir de jogar o histórico inteiro do usuário dentro do state 😉

Passo a passo: montando a decisão de notificação com o Jev

1. Modele a decisão como UM Choice de três opções

A pergunta é "o que fazer com esta notificação?" e as respostas possíveis são: enviar agora, juntar no resumo, não enviar

Isso é um Choice clássico: escolhe uma opção de um conjunto conhecido. As três primitivas da API são Choice, Score (nota contra níveis ordenados e descritivos) e Noul (probabilidade de sim pra pergunta sim/não), e tu pode conferir o formato exato de cada uma na documentação de primitivas

Por que não três Noul separados ("envio agora?", "jogo no resumo?", "descarto?")? Porque as perguntas são avaliadas de forma INDEPENDENTE. Tu ia acabar com dois "sim" ao mesmo tempo e um desempate feito na mão, que é exatamente o if aninhado que tu queria matar

O erro comum deste passo: explodir o Choice numa opção por tipo de notificação ("enviar agora se for comentário", "enviar agora se for menção", "enviar agora se for DM"…). O teto é de 255 opções por Choice e cada opção adicionada custa alguns tokens, então dá pra fazer, mas a decisão fica confusa e cara sem necessidade. Tipo de notificação é state, não é opção

2. Monte o state com os três sinais que importam

O state é o conteúdo que o modelo avalia, e ele vai no campo state da requisição, junto das perguntas

Pro nosso caso, o state útil tem três blocos:

• Estado do usuário: fuso, horário local, se está em janela de foco, preferências declaradas
• Urgência do evento: o que aconteceu, quem disparou, se tem prazo
• Histórico recente: quantos pushes foram mandados nas últimas horas e se a pessoa abriu ou ignorou

O erro comum deste passo: despejar o histórico inteiro. Com 32.000 tokens de contexto, dá pra ser bem generoso, mas state inflado é dinheiro queimado em TODA notificação, já que só a entrada é paga. Manda contagem e resumo, não o log cru

3. Faça a chamada

Na unha, é um POST pra https://api.typesafe.ai/v1/systemone:

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d @payload.json

O payload.json carrega o campo state com o texto que tu montou no passo 2 e o bloco de perguntas, cada uma com o ID que TU escolhe (o ID é por onde a resposta volta identificada). Confere o nome e o formato exato dos campos de cada primitiva na doc antes de subir, que isso muda de primitiva pra primitiva

Com o SDK Python fica mais curto, porque o cliente já lê a chave do ambiente e usa jev-latest por padrão:

from typesafe_sdk import TypeSafeClient

# lê TYPESAFE_API_KEY da variável de ambiente
# e chama jev-latest por padrão
client = TypeSafeClient()

Quando fixar a versão? Se a decisão está em produção e teus thresholds foram calibrados em cima de um comportamento específico, aponta pro modelo versionado jev-1.13.0 em vez de jev-latest

Troca de modelo por baixo dos panos é ótimo em desenvolvimento e péssimo no dia em que teu push some sem ninguém ter feito deploy

O erro comum deste passo: deixar jev-latest em produção e calibrar threshold em cima dele como se fosse pedra

4. Leia a resposta: opção + confiança

Volta a opção escolhida e um campo confidence entre 0 e 1, derivado da distribuição de probabilidade. Esse número é o que o teu código realmente usa

Respostas de Choice e Score carregam esse campo. O Noul devolve direto a probabilidade de a resposta ser sim, também entre 0 e 1

O erro comum deste passo: tratar a saída como se fosse texto de LLM e ficar fazendo parse de string. Não é. É valor tipado, usa como valor

5. Roteie por faixa de confiança, com threshold por ação

A documentação recomenda dividir a confiança em três faixas:

No nosso caso, "não age" tem um significado bem concreto: cai no caminho determinístico de fallback, que no pior cenário joga a notificação no resumo

E aqui vem a parte que a doc bate na tecla: threshold diferente por ação, conforme a consequência do erro

Descartar uma notificação errada é irreversível pro usuário. Jogar no resumo por engano custa uma hora de atraso. Não é o mesmo erro, então não pode ser o mesmo número

Na prática, tu exige confiança bem alta pra descartar, confiança média pra enviar agora, e deixa o resumo como destino padrão de tudo que não bateu threshold nenhum

O erro comum deste passo: um único threshold global tipo if confidence > 0.8 pra tudo. Funciona na demo, machuca em produção

6. Calibre os thresholds com exemplos rotulados

O padrão de roteamento por confiança recomenda calibrar em cima de exemplos rotulados e do custo do erro de cada caminho

Tradução: pega um lote de notificações reais que já saíram, rotula na mão qual era a decisão certa, roda o Jev em cima e olha onde ficou a confiança nos acertos e nos erros

Só depois disso tu escolhe os números. Chutar threshold é como chutar índice de banco: às vezes funciona, e quando não funciona ninguém entende por quê

Enriquecendo a decisão: várias perguntas na mesma chamada

Esse bloco é opcional, mas é onde o desenho fica bom de verdade

A API permite mandar várias perguntas numa mesma requisição: 1 requisição = 1 state + N perguntas. Todas veem o MESMO state, são avaliadas de forma independente e voltam identificadas pelo ID de cada uma

Então, além do Choice principal, dá pra somar:

1. Um Score de urgência, contra níveis ordenados e descritivos (algo como: rotina, relevante, precisa de atenção hoje, precisa de atenção agora). Esse score vira insumo de priorização depois, não só de envio
2. Um Noul do tipo "este evento é sensível ao tempo?", que volta como probabilidade de sim entre 0 e 1. Útil pra separar "fulano comentou" de "seu pagamento falha em 2 horas"
3. Um Noul de janela de foco, tipo "interromper este usuário agora seria inoportuno?"

Tudo isso numa chamada só, olhando o mesmo state

E por que agrupar, além de ser mais organizado? Porque tem número sobre isso. O cookbook de perguntas paralelas da TypeSafe mostra 13 perguntas numa chamada saindo 11,5x mais barato e 9,6x mais rápido do que 13 chamadas separadas

E não é ganho pago com qualidade: no mesmo cookbook, a maioria das respostas saiu idêntica nas 5 repetições, com desvio padrão 0,0

Faz sentido quando tu pensa no que é caro: o state. Mandar o mesmo contexto 13 vezes é pagar 13 vezes pela mesma leitura

O erro comum aqui: transformar cada sinal numa chamada separada dentro do caminho de envio. Aí tu empilha latência e empilha custo de entrada, pelo mesmo resultado

Variações que valem a pena no seu app de notificações

O desenho é o mesmo, muda a pergunta:

• Priorização da fila do digest: quando o resumo tem 40 itens e cabem 5 no e-mail, um Score de relevância ordena. É a mesma mecânica de pontuar e cortar por threshold que rende quando tu usa o Jev pra qualificar leads no funil
• Roteamento de canal: um Choice entre push, e-mail e in-app, com o mesmo state. Nota que aqui o conjunto de respostas também já é conhecido e fechado
• Rubrica de relevância: Score contra níveis descritivos que TU escreve, tipo uma rubrica de correção. Bom pra manter consistência entre times
• Silêncio em janela de foco: Noul simples, rodando antes do Choice ou junto dele
• Filtro de conteúdo antes do push: se a notificação carrega texto de outro usuário, vale encadear com a moderação de conteúdo enviado por usuários na mesma requisição, já que o state é o mesmo

Repara no padrão. A documentação da TypeSafe indica classificação, roteamento, avaliação por rubrica e priorização como os encaixes do modelo, e o critério é bem direto: o conjunto de respostas possíveis já existe, a decisão se repete, e o código consegue agir em cima de um score de confiança

Notificação bate nos três com folga

Se o teu caso não bate (tipo: a resposta certa é um texto que ninguém sabe de antemão), esse não é o modelo

Problemas comuns ao colocar isso em produção

Sintoma: a confiança vive na faixa média, quase nunca alta

Causa provável: opções mal descritas ou state pobre

"Enviar agora" e "enviar" não são opções distinguíveis. E state sem histórico recente deixa o modelo sem o sinal mais importante da decisão de fadiga

Como prevenir: escreve as opções como frases que um humano conseguiria decidir lendo só elas, e confere se os três blocos de state (usuário, urgência, histórico) estão realmente preenchidos e não vazios por bug de ETL

Sintoma: no agregado acerta, mas errou feio num caso específico

Causa: calibração é estatística

Modelos System One são treinados pra decisão calibrada, só que a calibração é medida em GRUPOS de predições. Ela não garante que uma resposta individual esteja correta

Como prevenir: mantém um caminho determinístico de fallback e regras duras que o modelo não pode atropelar. Alerta de segurança, cobrança e 2FA não entram na roleta, vão direto. O Jev decide o que é discricionário, não o que é obrigatório

Sintoma: a conta veio maior que o previsto

Causa: state inflado

Lembra que só a entrada é paga (US$ 0,042 por 1 milhão de tokens de entrada, US$ 0,00 na saída). Cada campo a mais que tu joga no state é multiplicado por todo evento do sistema

Como prevenir: mede o tamanho médio do teu state em tokens e corta o que não muda a decisão. Histórico vira contagem, preferência vira flag, texto longo vira resumo curto

Sintoma: latência fora do esperado bem no caminho de envio

Causa: a decisão está bloqueando o envio e a rede não colabora todo dia

A faixa divulgada é de 70 a 500 ms, e o topo dessa faixa pode não caber no teu orçamento

Como prevenir: decide conscientemente entre rodar a decisão de forma assíncrona (o evento entra numa fila curta, a decisão volta, aí o push sai) ou aceitar a fila com um timeout duro que cai pro fallback determinístico. Timeout sem fallback é o pior dos dois mundos

Conclusão

O desenho todo cabe em três linhas: um Choice com três saídas (agora, resumo, não vai), um state enxuto com estado do usuário, urgência e histórico recente, e roteamento por faixa de confiança com threshold diferente por ação

O resto é calibração

Próximo passo prático, na ordem: rotula um lote de notificações reais que já saíram, roda o Jev em cima, mede acerto por caminho, e SÓ ENTÃO mexe nos thresholds. Nessa ordem, não na inversa

Dois cuidados pra não tomar susto: o cadastro direto está pausado desde 22/09/2026 (contas existentes seguem funcionando, e dá pra chegar no modelo via OpenRouter ou Vercel AI Gateway), e o caminho determinístico de fallback não é opcional, é o que segura a peteca quando a resposta individual sai errada

Decisão tipada com probabilidade calibrada é uma baita ferramenta, mas ela entra no teu sistema como camada de julgamento, não como oráculo =)

Bora testar e me conta como foi na tua fila?

Até o próximo post!

Matheus Battisti