Como enxugar o state do Jev e reduzir o custo da conta?

Fala aí, beleza? No Jev a saída custa US$ 0,00 por 1 milhão de tokens e a entrada custa US$ 0,042 por 1 milhão de tokens

Leia de novo: a resposta é de graça, a conta inteira é decidida pelo que você MANDA

Isso muda completamente onde você coloca o esforço de otimização. Cada campo que você joga no state e que não participa da decisão é dinheiro queimado, e tem um agravante: a doc da TypeSafe é clara que a precisão do Jev cai quando o state cresce com conteúdo não relacionado à decisão, porque o detalhe irrelevante age como distrator

Ou seja, state gordo é caro E pior. Neste post a gente vai cortar esse ruído sem estragar a qualidade da decisão, e no fim você vai ter um jeito de MEDIR se o corte doeu ou não 🙂

O que você precisa antes de começar

Antes de sair cortando, o básico do setup:

• Acesso ao Jev: a API direta da TypeSafe segue em early access com fila de espera, o acesso sai pela waitlist em console.typesafe.ai
• Ou um dos gateways: o Jev também é oferecido pelo AI Gateway da Vercel (com janela promocional de uso gratuito até 25 de setembro de 2026) e está no catálogo de modelos da Cloudflare
• Uma chave para autenticação Bearer
• O formato da chamada na cabeça: um POST para https://api.typesafe.ai/v1/systemone, com Content-Type: application/json e corpo JSON de três campos no nível superior: state, model e questions (um mapa de ids para objetos de pergunta)

E um detalhe que derruba gente logo no primeiro pipeline: o Jev avalia apenas texto

Imagem, áudio, vídeo e binário não entram direto no state. Tudo isso precisa virar texto ou campo estruturado antes da chamada. Guarda essa informação porque ela volta lá embaixo como uma das maiores fontes de state inchado

Curso Recomendado

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

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

Conhecer curso

Por que o custo do Jev mora no state e não na resposta

O Jev é o modelo System One da TypeSafe: ele recebe um state (o contexto) mais perguntas tipadas e devolve decisões tipadas com probabilidades calibradas, sem gerar texto

Ele não é um modelo de geração de texto, é um modelo de decisão tipada. Se você conhece a lógica de um classificador que você chama mil vezes por dia no backend, é por aí

E é justamente por não gerar texto que a cobrança fica assimétrica:

• entrada: US$ 0,042 por 1 milhão de tokens
• saída: US$ 0,00 por 1 milhão de tokens

A versão jev-1.13 aparece com o mesmo preço de entrada em provedor externo, então não tem pegadinha de tabela diferente por canal

Os limites que você precisa respeitar por requisição:

São dois, e eles se somam ao raciocínio de custo:

• 64k tokens para o state mais todas as perguntas somadas
• 32k tokens para o state mais a pergunta mais longa

E aqui vem o detalhe que vale ouro: o state conta uma vez por requisição

O Jev ingere o state uma vez e avalia todas as perguntas daquela requisição em paralelo. Cada pergunta é avaliada de forma independente contra o mesmo state, então a resposta de uma não depende da presença das outras

Traduzindo pro seu bolso: se você tem 13 perguntas sobre o mesmo documento e faz 13 chamadas de uma pergunta cada, você pagou o documento 13 vezes

Como transformar suposição em número:

A resposta do endpoint traz as respostas sob os mesmos ids das perguntas e um objeto usage com a contagem de tokens da requisição

{
  "usage": {
    "input_tokens": 275,
    "output_tokens": 20
  }
}

Esse input_tokens é a sua fatura. A conta é direta:

const custoUSD = (usage.input_tokens / 1_000_000) * 0.042

O output_tokens você loga por curiosidade, porque ele custa US$ 0,00

Tome cuidado com um hábito ruim aqui: contar token no olho, chutando por caracteres. Não existe utilitário oficial documentado pra contar o state antes de enviar, então o caminho honesto é chamar, ler o usage e trabalhar em cima do número real

Passo a passo para enxugar o state do Jev

Bora ver na prática? A ordem importa, porque o passo 6 costuma dar mais economia sozinho do que os outros somados

1. Meça a linha de base

Antes de cortar qualquer coisa, rode a chamada como ela está hoje e registre usage.input_tokens em log, por tipo de chamada

const res = await fetch("https://api.typesafe.ai/v1/systemone", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.TYPESAFE_API_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({ state, model: "jev-1.13", questions })
})

const data = await res.json()
console.log("baseline input_tokens:", data.usage.input_tokens)

O erro comum deste passo: medir uma chamada só e achar que é a média. Meça uma amostra de casos reais, porque state de ticket curto e state de ticket com 40 mensagens são universos diferentes

2. Separe o que é state do que é question

A divisão recomendada pela TypeSafe é simples: no state vai o conteúdo e os fatos de apoio, nas questions vão os julgamentos a serem feitos sobre esse material

O exemplo da própria doc: o pedido de reembolso e a política vão no state, e as perguntas são se houve pedido e se a política suporta esse pedido

{
  "state": {
    "mensagem_cliente": "quero meu dinheiro de volta, comprei dia 03",
    "politica_reembolso": "reembolso integral em até 7 dias da compra"
  },
  "model": "jev-1.13",
  "questions": {
    "pediu_reembolso": { "type": "noul", "question": "O cliente pediu reembolso?" },
    "politica_cobre": { "type": "noul", "question": "A política suporta esse pedido?" }
  }
}

O erro comum deste passo: escrever o critério de julgamento dentro do state, em prosa. Critério é pergunta, não contexto

3. Remova os campos irrelevantes, filtrando em código ANTES da chamada

Essa é a recomendação oficial: recuperar e filtrar em código primeiro, enviando só os campos que a pergunta usa

Dois exemplos que a doc dá e que resolvem a maior parte dos casos reais:

• ao pontuar um ticket de suporte, não envie o histórico inteiro do cliente
• ao classificar um parágrafo, não envie o documento inteiro

// em vez de: state: cliente
const state = {
  ticket_atual: cliente.tickets.at(-1).texto,
  plano: cliente.plano
}

O erro comum deste passo: mandar o objeto do ORM inteiro porque "já está na memória mesmo". Está na memória de graça, mas na requisição custa

4. Resuma ou recorte histórico longo

O state aceita string simples ou dado estruturado (objeto ou array JSON), então você escolhe o formato que mais compacta o seu caso

Log de chat gigante costuma cair muito bem como array de mensagens já recortado na janela que interessa, e nota de atendimento antiga costuma caber numa linha resumida

const state = {
  thread: mensagens.slice(-6).map(m => `${m.autor}: ${m.texto}`),
  resumo_anterior: "cliente já teve 1 troca aprovada em agosto"
}

O erro comum deste passo: resumir com a mão pesada e jogar fora justamente o trecho que sustenta o julgamento. Por isso resumo é o ÚLTIMO corte da fila, e sempre com a medição da próxima seção

5. Quando não dá pra filtrar antes, use um Noul de relevância

Tem caso em que você não sabe o que é relevante até olhar. A doc indica usar um Noul pra filtrar relevância, e o cookbook de classificação de passagens de RAG mostra exatamente esse padrão: Nouls como is_relevant e contains_answer_evidence pontuando cada passagem recuperada

Aí você manda pro pacote final só as passagens que passaram do seu corte

{
  "is_relevant": { "type": "noul", "question": "Esta passagem é relevante para a pergunta do usuário?" },
  "contains_answer_evidence": { "type": "noul", "question": "Esta passagem contém evidência da resposta?" }
}

O erro comum deste passo: rodar uma chamada de filtro por passagem. Junta as passagens no mesmo state e faz as perguntas em lote, senão o filtro custa mais que o problema que ele resolve

6. Pare de repetir o state: agrupe as perguntas

Esse é o corte mais barato de implementar e o mais violento no resultado

Todas as perguntas que usam o mesmo material devem ir juntas numa única chamada, porque o state é ingerido uma vez e as perguntas rodam em paralelo

// N chamadas de 1 pergunta = state reenviado N vezes
// 1 chamada com N perguntas = state pago uma vez
const questions = {
  q1: { type: "noul", question: "..." },
  q2: { type: "noul", question: "..." },
  q3: { type: "choice", question: "...", options: ["a", "b", "c"] }
}

O erro comum deste passo: ter medo de que agrupar contamine as respostas. Não contamina: cada pergunta é avaliada de forma independente contra o mesmo state

7. Recalcule o usage e compare com a linha de base

Mesma amostra do passo 1, mesmo log, número contra número

Se o input_tokens caiu e a decisão continuou a mesma (a próxima seção mostra como conferir isso), o corte está aprovado. Se caiu e a decisão mudou, você cortou músculo, não gordura

Quatro cortes que mais economizam na prática

Os mesmos princípios, aplicados nos cenários que mais aparecem

1. Ticket de suporte: recorte a thread

Sai do state: histórico completo do cliente, dados de cadastro que ninguém julga, tickets de anos anteriores

Fica: a thread atual (ou as últimas mensagens) e os fatos que a pergunta realmente usa, tipo plano e data da compra

A doc usa esse caso como exemplo direto de filtro: pra pontuar um ticket, o histórico inteiro do cliente não precisa ir junto

2. RAG: filtre passagem antes de montar o pacote

Sai do state: as passagens recuperadas que o retriever trouxe por desencargo

Fica: as que passaram no Noul de relevância, no padrão do cookbook de classificação de passagens

Aqui o ganho é duplo: menos token e menos distrator competindo com a evidência boa

3. Rubrica de moderação com muitas perguntas: lote único

Sai: o loop que chama o Jev uma vez por critério

Fica: uma chamada só com a rubrica inteira no mapa de questions

O cookbook de perguntas em paralelo mediu esse ganho com 13 perguntas sobre o artigo da GDPR na Wikipedia:

Dá 12,2x mais barato e 10,0x mais rápido, sem mudança nas respostas

Insano, e é só mudar a forma de montar a requisição 😀

4. Pipeline com conteúdo não textual: pré-processe em campos enxutos

Sai: qualquer tentativa de empurrar binário, e também a transcrição bruta de 40 minutos

Fica: campos estruturados curtos com o que a pergunta julga (por exemplo valor_nota, data_emissao, itens)

Como o Jev só avalia texto, esse pré-processamento você vai fazer de qualquer jeito. A escolha é entre despejar o resultado inteiro no state ou entregar só os campos

Como medir se o corte estragou a decisão

Cortar é fácil, a parte séria é provar que a decisão continuou boa. Segue um protocolo:

1. Monte um conjunto de casos com rótulo conhecido

Pega casos reais do seu domínio onde você (ou o time) já sabe a resposta certa. Sem isso, qualquer conversa sobre qualidade vira achismo

2. Rode a mesma rubrica antes e depois do corte

Mesmo modelo, mesmas perguntas, só o state muda. Assim a única variável em jogo é o que você tirou

3. Separe ruído de regressão real com autoconsistência

O método oficial dos cookbooks é repetir a mesma rubrica várias vezes e comparar os rótulos que voltam: no cookbook de Nouls são 15 repetições de uma rubrica de 14 perguntas sobre 1 sinistro de seguro auto, e no de Choices são 15 repetições por condição sobre 1 post limítrofe de moderação

Se o rótulo já oscilava antes do corte, a mudança que você viu pode não ser culpa do corte

4. Olhe a probabilidade, não só o rótulo

As três primitivas devolvem mais do que um sim/não: o Noul devolve probabilidade de verdadeiro numa escala de 0 a 1, o Choice devolve uma opção de um conjunto fixo (máximo de 255 opções) e o Score devolve posição num espectro. Choice e Score ainda trazem probabilities e um confidence de 0 a 1

Um corte pode manter o rótulo e derrubar a confiança de 0,9 pra 0,55. O rótulo passou no teste, mas a decisão ficou frágil

5. Calibre o threshold pela consequência da ação

A doc recomenda thresholds diferentes por ação e testar o corte plotando confiança contra acurácia nos seus próprios dados

O exemplo oficial: 0,6 pode bastar pra ação de baixa consequência (consultar saldo) e acima de 0,85 pra ação de alta consequência (aprovar transferência), com os casos incertos indo pra revisão humana ou pra um modelo mais caro

Esse cuidado de conferir número em vez de confiar no que a IA devolveu é o mesmo raciocínio de conferir quando a IA faz conta, só que aplicado a probabilidade em vez de aritmética

O erro comum aqui: julgar um corte por um único caso. Um caso é anedota, principalmente num sistema onde a própria repetição da mesma rubrica pode variar

Sintomas de state inchado e como corrigir

Sintoma: a conta subiu e o volume de decisões não

Causa provável: state repetido em N chamadas de uma pergunta cada. O state conta uma vez por requisição, então cada chamada extra é uma cópia paga do mesmo material

Solução: agrupar as perguntas que compartilham o state numa requisição só

Como prevenir: logar usage.input_tokens por tipo de chamada e criar um alerta quando o total de tokens crescer mais rápido que o total de decisões

Sintoma: a acurácia caiu justo depois que você adicionou mais contexto

Causa provável: o detalhe irrelevante está agindo como distrator. Além de errar mais, fica difícil identificar qual parte do state gerou a resposta errada

Solução: voltar pro filtro em código, mandando só os campos que a pergunta usa

Como prevenir: tratar o filtro como etapa fixa do pipeline (recupera, filtra, chama), nunca como otimização pra fazer depois

Sintoma: estouro de limite de contexto

Causa provável: anexar documento inteiro no state. São 64k tokens para state mais todas as perguntas e 32k para state mais a pergunta mais longa

Solução: recortar o trecho que a pergunta julga, ou fatiar em passagens e filtrar com Noul de relevância antes

Como prevenir: se o seu state é montado a partir de upload de usuário, assuma que uma hora vai chegar o PDF de 300 páginas. Já me ferrei uma vez por confiar que o input ia continuar pequeno 😛

Sintoma: confiança baixa e instável nas respostas

Causa provável: o material que sustenta a decisão está diluído em contexto que não decide nada, ou o corte anterior levou junto a evidência

Solução: rodar a rubrica de regressão com repetição (o padrão dos cookbooks de autoconsistência) e comparar confidence antes e depois

Como prevenir: manter uma rubrica de regressão versionada no repo, rodando junto com os testes

O que ainda não dá para fazer: cache de state e limites

Hora da parte honesta do post

Não existe cache oficial de state ou de perguntas no Jev

Aquela ideia natural de "meu bloco de critérios é sempre o mesmo, deixa ele cacheado e paga só o que muda" é hoje um pedido em aberto, registrado numa issue no SDK JS da TypeSafe que pede prompt caching do bloco de critérios, perguntas registradas por id e exposição de cached_tokens

Consequência prática pro seu bolso hoje: a economia vem de cortar e agrupar, não de cachear. Quem montou a arquitetura contando com desconto de token reaproveitado vai ter surpresa na fatura

Duas coisas mais pra colocar no radar:

• Rate limits são dinâmicos e podem mudar sem aviso, com limites maiores em planos custom e enterprise (o contato pra isso é [email protected])
• O uso do Jev está gratuito no AI Gateway da Vercel até 25 de setembro de 2026, o que faz dele um ambiente barato pra testar variações de corte enquanto a janela estiver aberta

Vídeo: entendendo o contexto antes de cortar

Pra começar do zero com a ideia de contexto e histórico virando material pra uma IA, este vídeo do canal mostra uma IA que reúne tudo o que você fez nos últimos 30 dias:

Conclusão

Se eu tivesse que deixar uma ordem de prioridade pra atacar o custo do Jev, seria essa:

1. Agrupar perguntas primeiro (é o corte com a maior razão entre ganho e esforço, e não muda as respostas)
2. Filtrar em código depois (tirar campo que a pergunta não usa derruba token e ainda remove distrator)
3. Resumir por último (é o único que tem risco real de levar junto a evidência, então só com medição em cima)

E o próximo passo é bem chato e bem eficaz: instrumentar o usage nas chamadas que você já tem rodando hoje. Sem esse log, tudo o que está aqui vira palpite

Pra quem trabalha com agente de código, a TypeSafe mantém uma agent skill oficial no repo typesafe-ai/skills. No Claude Code a instalação é assim:

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

E aí você invoca com /typesafe:typesafe-ai

Em outros agentes:

npx skills add typesafe-ai/skills --skill typesafe-ai

A instalação é local ao projeto por padrão, e tem a flag -g pra global

É isso, corta o ruído, mede o usage e deixa a rubrica de regressão fazer o trabalho sujo de te avisar quando você exagerou 🙂

até o próximo post!