Por que os tokens de saída do Jev são gratuitos e o que isso muda no desenho do sistema

Fala aí, beleza? Tem uma tabela de preços rodando por aí com US$ 0,00 na coluna de tokens de saída, e isso não é promoção de lançamento: é a arquitetura do modelo aparecendo no boleto

A TypeSafe AI saiu do stealth em 15 de setembro de 2026, com uma rodada seed de cerca de US$ 40 milhões liderada pela DCVC, e no mesmo dia colocou o Jev em early access

A empresa foi fundada por Diogo Almeida, que é cofundador e CEO

E o detalhe que interessa pra quem desenha sistema: a conta inteira do Jev depende do que você MANDA, não do que ele responde

O que é o Jev e por que ele não gera texto livre

Antes de falar de preço, precisa entender o bicho, senão o US$ 0,00 parece mágica (e não é)

O Jev não é autorregressivo

Ele não decodifica token a token num loop, como você está acostumado a ver num chat. Ele calcula a distribuição de probabilidade sobre todas as opções definidas em uma única passagem, um forward pass só

E aqui vem a consequência dura: o Jev não consegue gerar strings livres

Ele só devolve valores de três primitivos tipados:

• Choice: escolha entre opções, com probabilidade por opção e confiança
• Score: nota contra níveis ordenados
• Noul: booleano, com probabilidade de ‘sim’

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

É isso. Não tem redação, não tem resumo, não tem código gerado

"Então o que é ‘saída’ aqui?"

Boa pergunta. Saída no Jev é uma distribuição de probabilidade sobre opções que VOCÊ definiu na pergunta. Não é um texto que cresce enquanto o modelo pensa

Quando você entende isso, o US$ 0,00 deixa de ser marketing e vira consequência: não existe loop de geração pra cobrar

A versão documentada é a jev-1.13.0, com entrada somente texto (no OpenRouter esse mesmo modelo aparece com o id typesafe/jev-1.13, é a mesma versão)

O acesso é via POST em https://api.typesafe.ai/v1/systemone, com o model id jev-latest

E o formato da chamada é o pulo do gato: 1 state + N perguntas tipadas

Você manda um state (texto livre ou o estado do seu programa) e qualquer número de perguntas tipadas em cima dele, e TODAS são respondidas na mesma passagem paralela

Guarda essa ideia, porque ela é a peça central do resto do post

Entrada paga, saída zero: como o preço do Jev se compara

Se liga na assimetria:

US$ 0,042 por milhão de entrada dá US$ 42 por bilhão de tokens

E a tabela de preços da TypeSafe descreve a saída do Jev como too cheap to meter, ou seja, barata demais pra medir

A latência anunciada é de 70 ms a 500 ms de ponta a ponta

Nas avaliações publicadas pela própria TypeSafe, o comparativo fica assim:

Agora a ressalva, que é obrigatória: esses números são benchmark do próprio fornecedor

E tem um detalhe metodológico que muda bastante a leitura: a acurácia é medida por concordância com a saída de outros modelos de fronteira na mesma tarefa, não contra um dataset independente rotulado com ground truth

Ou seja, 68% ali quer dizer "concorda com o modelo grande em 68% dos casos", não "acerta 68%"

E cuidado pra não confundir base de medição: os números de manchete de 193,6x mais rápido e 444,6x mais barato NÃO saem dessa tabela por caso aí de cima, eles vêm das avaliações de workflow completo da própria TypeSafe, que já avisa que espera esses valores na ponta alta dos ganhos reais. Comparando caso a caso, como na tabela, a distância entre os dois é bem menor

Traduzindo: use como ordem de grandeza, não como promessa

O custo vira função do contexto enviado, não da resposta

Aqui tá o ponto do post

No desenho tradicional, você paga os dois lados, e a saída costuma ser o lado CARO. Olha o GPT-5.6 Terra ali em cima: US$ 12,00 de saída contra US$ 2,00 de entrada

Por isso a gente aprendeu a otimizar resposta: pedir resposta curta, limitar tokens, cortar verbosidade. Em modelos que geram texto, o limite de tokens de saída numa resposta só vira uma variável de projeto inteira

No Jev isso simplesmente não existe como alavanca

Com saída a zero, a única coisa que você controla no custo é o tamanho do state e das perguntas

O que isso muda na prática:

• Muitas perguntas por chamada em vez de muitas chamadas: como o formato é 1 state + N perguntas na mesma passagem, cada pergunta extra empilhada na mesma requisição aproveita um state que você já está pagando
• Você corta o state, não a resposta: enxugar contexto virou a otimização de custo, e não "pedir pro modelo ser breve"
• O custo fica previsível ANTES da chamada: dá pra contar os tokens de entrada e saber a conta, porque não tem uma resposta de tamanho imprevisível inflando o total depois

Esse último ponto é subestimado. Previsibilidade de custo antes da execução muda como você monta orçamento, rate limit interno e circuit breaker

Mas tem teto, claro

Os limites de contexto documentados pela TypeSafe são 64k tokens por requisição (state mais todas as perguntas) e 32k para o state mais a pergunta mais longa

Então não dá pra sair empilhando pergunta infinitamente: existe um ponto onde a chamada não cabe mais e você precisa quebrar em duas, pagando o state de novo

É um desenho bem diferente do mundo dos modelos de chat, onde a conversa sobre janelas de contexto de 1M de tokens já virou padrão. Aqui o contexto é apertado de propósito, porque a tarefa é decidir, não redigir

Onde essa assimetria muda a arquitetura em volume alto

Em chamada única, isso tudo é curiosidade. Em volume, vira decisão de arquitetura

Onde a conta muda de forma:

• Classificação e roteamento em massa: aquela camada que decide pra onde vai cada item da fila, que hoje você paga caro pra um modelo generalista fazer
• Scoring de itens em fila: Score contra níveis ordenados é exatamente o formato de "dá uma nota de prioridade nisso aqui"
• Gates booleanos dentro de pipelines: Noul devolve booleano com probabilidade de ‘sim’, então você tem um if com confiança anexada
• Avaliação de muitos critérios sobre o mesmo contexto: esse é o caso mais bonito, um state compartilhado e N perguntas em cima dele

Esse último merece parada

Se você precisa avaliar 12 critérios sobre o mesmo documento, o desenho ingênuo é 12 chamadas. E aí você paga o documento inteiro 12 vezes

O desenho certo é 1 chamada com o state uma vez e as 12 perguntas tipadas juntas, tudo respondido na mesma passagem paralela

Tome cuidado com isso: o mesmo state repetido em chamadas separadas é cobrado de novo, cheio

Não existe prompt caching publicado pro Jev. Não tem desconto de entrada repetida documentado. Se você mandou 20k tokens de state duas vezes, pagou 40k

Agrupar pergunta não é micro-otimização aqui, é a otimização

Os limites que essa conta esconde

Três armadilhas que aparecem justamente quando você começa a confiar demais no US$ 0,00

1. State repetido custa cheio toda vez

Sintoma: sua conta de entrada cresce linear com o número de chamadas, mesmo quando o contexto é sempre o mesmo

Causa: não há prompt caching publicado e o SDK JavaScript da TypeSafe expõe na interface Usage apenas input_tokens e output_tokens na v0.6.0. Não existe campo cached_tokens, e tem issue aberta pedindo prompt caching justamente por isso

Como prevenir: dimensione o sistema por tokens de entrada desde o dia 1 e agrupe perguntas por chamada sempre que o state for compartilhado. Enquanto não existir cache publicado, o agrupamento é o seu cache

2. Limites de conta que podem mudar no meio do caminho

Sintoma: você desenha pra throughput alto e esbarra em teto de plataforma, não de custo

Causa: os limites de taxa publicados são de 1.200 requisições por minuto e 250.000 tokens por segundo, limites de conta que a própria TypeSafe avisa que podem mudar durante o early access

Como prevenir: trate esses números como variável de configuração, não como constante no código. Early access é early access

E olha que isso conversa direto com a armadilha 1: menos chamadas com mais perguntas também te ajuda no teto de req/min

3. A saída grátis é decisão comercial, não lei da física

Sintoma: você monta o orçamento contando com saída zero e um dia a linha aparece

Causa: a TypeSafe afirma que hoje não cobra pela saída, mas que em algum momento vai precificá-la. Tanto que o SDK já devolve output_tokens no objeto usage, só que precificado em zero

Ou seja, o campo já está lá, esperando um número

Como prevenir: registre output_tokens no SEU log de custo desde agora, mesmo multiplicando por zero. No dia em que o preço existir, você já vai saber exatamente quanto consome, em vez de descobrir junto com a fatura

Já me ferrei com esse tipo de coisa em outros contextos: o campo existir e você ignorar é convite pra susto depois 😅

Vale desenhar sistema em cima da saída gratuita?

Veredito honesto, sem torcida

A assimetria é real e tem causa técnica, não é só agressividade comercial. Quando a inferência acontece em passagem única sobre primitivos tipados, não tem loop de decodificação gerando volume de saída pra cobrar. A saída do Jev é uma distribuição sobre opções que você já definiu

Por isso a aposta razoável é que, mesmo se for precificada, essa saída continue barata perto do que você paga em modelo de texto livre

Mas depender de US$ 0,00 no orçamento é apostar numa decisão comercial, e a própria TypeSafe já sinalizou que vai precificar. Não tem data, prazo ou gatilho anunciado, o que é justamente o motivo de não construir planilha em cima disso

Quem ganha muito aqui: pipelines de decisão de alto volume, onde você tem milhares de classificações, scores e gates por minuto e paga uma fortuna pra um modelo generalista fazer trabalho de if

Quem NÃO ganha nada: quem precisa de texto livre. O Jev não gera string, ponto. Não adianta querer usar como substituto de chat

Sobre distribuição, dois sinais: o modelo aparece no OpenRouter como typesafe/jev-1.13, chamado pela Decisions API e não pelo endpoint padrão de chat completions, e também está listado na documentação de modelos de AI da Cloudflare como typesafe/jev

Pra um produto que saiu do stealth há poucos dias, estar nesses dois lugares já diz alguma coisa sobre a intenção de virar infraestrutura, e não demo

Conclusão

O recado é curto: com os tokens de saída do Jev a zero, você otimiza o contexto, não a resposta

Todo o instinto que a gente construiu nos últimos anos (pedir resposta curta, limitar geração, cortar verbosidade) simplesmente não move o ponteiro aqui. O que move é o tamanho do state e quantas perguntas você consegue empilhar numa chamada só, dentro dos 64k por requisição

Próximo passo prático, se o tema te interessou:

1. Mapeia no teu sistema quais decisões de hoje cabem em Choice, Score ou Noul. Se a resposta precisa ser texto corrido, não cabe e acabou
2. Mede o tamanho MÉDIO do state que você mandaria. É ele que define tua conta, não o volume de respostas
3. Já instrumenta output_tokens no teu log de custo, antes que ele tenha preço

O passo 3 é o mais chato e o mais valioso. Custa dez minutos agora e te salva de uma surpresa depois…

Até o próximo post! 🙂