O que muda no código com o Jev: como a saída tipada elimina parsing, validação e retry

Fala aí, beleza? Se você já pediu JSON pra um LLM em produção, você conhece a cena: a resposta volta com uma crase solta, um campo faltando, um enum que o modelo inventou na hora, e aí tua função de parse explode

Daí vem o ritual: try/except, validação de schema, retry com backoff, um log de "resposta malformada" que ninguém olha, e um contador de tentativas que você jura que vai refatorar semana que vem 😅

A TypeSafe AI anunciou em 15 de setembro de 2026 o Jev, apresentado como o primeiro modelo da classe System One, feito justamente pra atacar essa camada

A ideia é simples de enunciar e estranha de digerir: o modelo não devolve texto pra você interpretar, ele devolve uma decisão tipada que teu código consome direto

Bora entender o que isso muda na prática?

O que é o Jev e por que ele não devolve texto

A sacada da classe System One é inverter o contrato

No fluxo tradicional, tu manda um prompt e recebe uma string, e a string PODE ser um JSON válido se o modelo colaborar. No Jev, tu declara a pergunta já tipada e recebe o valor estruturado, sem geração de texto e sem parsing no meio

O formato é definido antes, não interpretado depois

Um estado, N perguntas, uma chamada

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O modelo recebe um estado uma única vez e avalia todas as perguntas contra ele em paralelo, na mesma requisição

Isso é diferente de mandar N prompts pro mesmo contexto e rezar pra cada um voltar no formato certo. Aqui é um estado + várias perguntas tipadas, tudo junto

E a saída inteira sai em uma única passagem paralela, não token a token

Como ele é treinado pra decidir

Os modelos System One são treinados com um método chamado Reinforcement Learning for Calibrated Decisions, o RLCD

O nome é feio mas a ideia é boa: as probabilidades são otimizadas contra resultados reais, com calibração medida em grupos de previsões. Ou seja, o foco não é "escrever bonito", é a probabilidade que ele te entrega fazer sentido quando tu agrupa muitas decisões

Quem toca a TypeSafe AI é o Diogo Almeida, pesquisador que saiu da OpenAI em 2024

Antes de empolgar: de onde vêm os números

Aqui vai o aviso honesto que eu sempre faço

A latência divulgada (70 ms a 500 ms), o claim de 0% de erro de schema e as comparações de velocidade e preço são medições e avaliações da PRÓPRIA TypeSafe. Não tem benchmark independente público de acurácia do Jev contra LLMs até agora

E o acesso direto pela TypeSafe está em early access, com lista de espera e chaves liberadas em lotes, sem data anunciada de disponibilidade geral

Ou seja: a proposta arquitetural é MUITO interessante, o marketing merece o ceticismo de sempre

Antes e depois: o fluxo de tratamento de erro com LLM de texto e com saída tipada

O jeito mais fácil de ver o ganho é olhar etapa por etapa do que teu código faz hoje

Repara no que some do repositório: a função que limpa markdown em volta do JSON, o schema validator, o wrapper de retry, o fallback pro "pede de novo com a instrução mais firme"

E tem um detalhe de custo que passa batido: a tentativa que falhou também foi paga

No modelo de texto, cada retry queima tokens de entrada E de saída. No Jev, o preço é de US$ 0,042 por 1 milhão de tokens de entrada e os tokens de saída custam US$ 0,00

Pelo câmbio de 1 USD = R$ 5,14 em 19/09/2026, isso dá algo perto de R$ 0,22 por 1 milhão de tokens de entrada

Não é só "mais barato", é uma conta com menos variáveis: tu paga o estado que mandou, e pronto

O que você precisa para chamar o Jev

Antes do código, o básico de acesso e runtime

Acesso ao modelo, por um destes caminhos:

• Chave da própria TypeSafe, entrando na waitlist em typesafe.ai (early access, chaves liberadas em lotes)
• OpenRouter, onde o modelo está listado como typesafe/jev-1.13, com janela de contexto de 32 mil tokens
• Cloudflare Workers AI, onde ele aparece na documentação como typesafe/jev

Runtime, conforme tua stack:

• Python 3.10 ou superior, com pip install typesafe-sdk (ou uv add typesafe-sdk)
• Node.js 20 ou mais novo, com npm install @typesafe-ai/sdk

Configuração: o cliente Python lê a chave da variável de ambiente TYPESAFE_API_KEY e usa o modelo jev-latest por padrão

E se tu for do time HTTP puro, sem SDK, o endpoint da System One API é POST https://api.typesafe.ai/v1/systemone

Tome cuidado com uma coisa: a janela de contexto de 32K citada no OpenRouter limita o tamanho do estado que tu manda. Se teu "estado" é um dump gigante de conversa, ele precisa ser reduzido antes

Como escrever a chamada tipada passo a passo

1. Instale o SDK e exporte a chave

pip install typesafe-sdk
# ou, se você usa uv:
# uv add typesafe-sdk

export TYPESAFE_API_KEY="sua-chave"

O erro comum deste passo: rodar em Python abaixo do 3.10. O SDK exige 3.10 ou superior, então se aparecer erro esquisito na importação, confere a versão do interpretador ANTES de sair procurando bug no pacote

2. Importe os tipos e instancie o client

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()

O client usa o modelo jev-latest por padrão e lê a chave da variável de ambiente, então não precisa passar credencial na mão no código

O erro comum deste passo: deixar a chave hardcoded no arquivo e subir pro repo. Clássico, e dói 😬

3. Escolha a primitiva certa pra pergunta

São três, e cada uma resolve um tipo de decisão:

• Choice: escolha entre alternativas declaradas, com suporte a até 255 opções
• Score: nota em níveis ordenados
• Noul: pergunta binária, que retorna a probabilidade de a resposta ser sim

Pensa assim, pra aproximar do que tu já conhece: Choice é o teu enum, Score é o teu rating de 1 a 5, Noul é o teu boolean (só que melhor, porque vem com o grau de certeza junto)

O erro comum deste passo: estourar o limite de 255 opções no Choice porque alguém resolveu jogar a tabela inteira de categorias do banco como alternativa. Se tua lista cresce sem teto, ela não é um Choice, é uma busca

4. Mande um estado com N perguntas na mesma requisição

Esse é o ponto que muda a arquitetura: o Jev recebe o estado uma única vez e avalia todas as perguntas contra ele em paralelo, na mesma chamada

Depois é só consumir o valor direto. Sem json.loads, sem validar chave, sem normalizar string

O erro comum deste passo: disparar uma requisição por pergunta, do jeitinho que a gente faz com LLM de texto. Isso reenvia o mesmo estado várias vezes, paga entrada repetida e joga fora exatamente a vantagem do modelo

O formato exato do payload e o nome de cada método ficam na documentação oficial do SDK, que é o teu próximo passo aqui

5. Use a confiança e as probabilidades pra decidir threshold e fallback

Cada resposta vem com probabilidades e um valor de confiança

É aqui que mora a parte interessante do design: em vez de "deu erro, tenta de novo", tu passa a ter "a decisão veio com confiança baixa, manda pro humano"

O erro comum deste passo: tratar o retorno do Noul como booleano. Ele não é true/false, ele é a probabilidade de a resposta ser sim. Quem compara isso direto num if sem definir o corte tá inventando um threshold implícito de zero e não sabe

Os erros que somem e os que continuam existindo

Agora a parte honesta: nem todo problema evapora

O que deixa de fazer sentido

Sintoma: JSON truncado no meio, chave faltando, enum inventado, aspas escapadas errado

Causa: o modelo estava escrevendo TEXTO e você estava torcendo pra esse texto ser estrutura válida

Prevenção: com o schema garantido por construção, essa classe inteira de defeito sai do escopo. A TypeSafe afirma 0% de erro de schema (claim do próprio fornecedor, vale repetir)

Sintoma: retry em loop, custo estourando em tentativas que nunca chegam a um JSON válido

Causa: a única estratégia possível contra saída malformada era pedir de novo

Prevenção: não existe "resposta malformada" pra tentar de novo. E com a saída a US$ 0,00, a tentativa perdida também deixa de ser um item de custo

Vale dizer: parsing não some da tua vida, viu 😄 continua existindo erro de parsing em todo canto do teu projeto, e quem já perdeu uma tarde num erro de parsing no ESLint sabe bem disso. O que some é o parsing da RESPOSTA DO MODELO

O que continua te dando trabalho

Sintoma: 429 Too Many Requests

Causa: a API tem limites de taxa medidos em tokens por segundo e em requisições por minuto, e estourar qualquer um dos dois retorna 429

Prevenção: trate 429 como cidadão de primeira classe no teu cliente, com fila e espera. E olha: a documentação avisa que os limites podem mudar sem aviso nesta fase, então não chumbe número nenhum no código

Sintoma: o estado não cabe

Causa: no OpenRouter, o typesafe/jev-1.13 está listado com janela de contexto de 32 mil tokens

Prevenção: resuma, filtre ou fatie o estado antes de enviar. Como o modelo avalia N perguntas contra o MESMO estado, vale investir em montar um estado enxuto e reaproveitá-lo pra várias decisões

Sintoma: a decisão volta bonitinha, tipada, e mesmo assim está errada

Causa: schema garantido não é acurácia garantida. O tipo estar certo não quer dizer que a escolha esteja certa

Prevenção: essa é regra de negócio, não retry. Use o valor de confiança e as probabilidades pra definir corte, rota de revisão humana e caminho padrão. Pedir de novo a mesma coisa pro mesmo estado não conserta decisão de baixa confiança

Onde a saída tipada resolve melhor que um prompt com JSON

Roteamento e triagem, com Choice

Ticket que precisa cair num de N times, mensagem que vai pro agente certo, intenção do usuário

O trecho que deixa de ser escrito: aquele if resposta not in CATEGORIAS_VALIDAS seguido de fallback pra "outros", que existe só porque o modelo às vezes inventa uma categoria nova 😅

Moderação e priorização por nível, com Score

Gravidade de um report, prioridade de um chamado, nota de risco

O trecho que some: o normalizador que aceita "4", 4, "quatro" e "nota 4 de 5" como se fossem a mesma coisa. Com níveis ordenados declarados, a resposta já vem no nível

Gates booleanos e feature flags de agente, com Noul

"Esse passo precisa de aprovação humana?", "essa mensagem contém dado sensível?", "esse agente pode seguir?"

Como o Noul retorna a probabilidade de sim, o gate fica explícito: tu escolhe o corte em vez de herdar o corte que o modelo decidiu sozinho na hora de escrever "yes" ou "no"

Classificação em lote sobre o mesmo estado

Esse é o caso que mais aproveita o desenho do modelo: um estado, várias perguntas tipadas, uma requisição

Sai do código o orquestrador de chamadas paralelas, o agrupamento de resultados e o tratamento de "a pergunta 3 falhou mas a 1 e a 2 foram"

Onde ele NÃO serve

Se o teu problema pede texto gerado, o Jev não é a ferramenta

Resumo, redação, resposta pro usuário, geração de código: nada disso. Ele não gera texto, ponto. O papel dele é decidir dentro do software, não conversar

Vale trocar o parsing pelo Jev agora?

Meu veredito, sem empolgação de lançamento

A ideia arquitetural é boa de verdade. Tirar a etapa de interpretação da resposta não é otimização de performance, é remoção de uma classe inteira de bug do teu repositório. Menos código defensivo, custo de saída zerado, decisão que já chega com probabilidade calibrada junto

Agora, os números

0% de erro de schema, 70 ms a 500 ms de latência, 193,6x mais rápido que o Claude Sonnet 5 e 444,6x mais barato que o Claude Opus 5: tudo isso é medição e avaliação da própria TypeSafe. E repara que as duas comparações são contra modelos DIFERENTES, uma de velocidade contra um, outra de preço contra outro. Sem validação independente, isso é claim de fornecedor, não resultado de benchmark neutro

Soma a isso o acesso direto ainda em early access por waitlist, sem data de disponibilidade geral, e limites de taxa que podem mudar sem aviso nesta fase

Faz sentido testar hoje se você tem uma decisão fechada e repetitiva no pipeline (roteamento, triagem, gate booleano), já sofre com retry de JSON e consegue acessar via OpenRouter ou Cloudflare Workers AI

Vale esperar se o teu caso mistura decisão com geração de texto, se você depende de SLA firme de rate limit, ou se você não pode apostar numa dependência que ainda está liberando chave em lotes

Conclusão

O ponto central não é o modelo escrever melhor

É o teu código parar de se defender da saída do modelo

Quando o formato é definido antes e o retorno chega como valor estruturado, o parse, o schema check e o retry com backoff simplesmente deixam de ter função. Sobra regra de negócio em cima de confiança e probabilidade, que é o tipo de código que a gente REALMENTE quer manter

Próximo passo prático: entra na waitlist ou testa via OpenRouter (typesafe/jev-1.13) ou Cloudflare Workers AI, pegando UMA decisão que já existe no teu pipeline

Depois conta quantas linhas de parsing e retry saíram do repositório. Esse é o número que importa pra tua base de código, e esse número só tu consegue medir 🙂

Abraço e até o próximo post!

Matheus Battisti