Como gastar menos tokens de entrada no Jev

A fatura do Jev tem uma variável só. Você paga tokens de entrada, a US$ 0,042 por milhão segundo a documentação oficial, e a saída é gratuita. Não há preço de raciocínio, de cache nem de saída longa para administrar.

Isso simplifica a otimização e também a torna contraintuitiva para quem vem de LLM: não adianta pedir respostas mais curtas. Adianta mandar menos coisa.

Onde o token vai embora

Três lugares, em ordem de impacto.

1. O state gordo. É quase sempre o maior componente. Cabeçalho de e-mail, assinatura, aviso de confidencialidade, histórico encadeado, o registro inteiro do cliente quando a pergunta usa três campos, o contrato completo quando a dúvida é sobre uma cláusula.

2. A pergunta repetida. Chamar dez vezes o mesmo conteúdo com uma pergunta cada envia o state dez vezes. O texto da pergunta é barato; o reenvio do conteúdo não é.

3. A chamada por item quando o lote caberia. Variação do anterior, comum em laços gerados por agentes de código: um for que faz uma requisição por pergunta em vez de montar um mapa.

O corte que rende mais, e de graça

Filtrar o state antes de enviar é a única otimização deste site que melhora a acurácia enquanto reduz o custo.

O motivo está na documentação oficial: “state grande cheio de detalhe irrelevante” é um dos nove modos de falha declarados do jev-1.13, e o texto explica que o conteúdo não relacionado age como distrator e ainda dificulta descobrir qual parte da entrada produziu a resposta errada. O efeito tem página própria em context rot.

Na prática:

• mande os campos que a pergunta usa, não o registro inteiro;
• calcule em código o que é número — dias de atraso, contagem, saldo — e mande o resultado pronto, em vez do histórico de onde ele sai;
• corte cadeia de e-mail, assinatura e rodapé na ingestão;
• quando não souber o que é relevante, use uma passagem barata de filtro, como na receita de classificar passagens de RAG.

Agrupar perguntas, com o número oficial

Esta é a segunda maior economia, e ela está medida.

O cookbook oficial de perguntas paralelas fez uma tarefa de conformidade com 13 perguntas sobre um artigo longo, de duas formas: uma chamada com as treze, ou treze chamadas com uma pergunta cada. O resultado publicado foi 12,2 vezes mais barato e 10,0 vezes mais rápido, sem mudança nas respostas — a maioria das perguntas devolveu valor idêntico nas repetições, e as duas que variaram variaram igual nas duas estratégias.

A explicação é a mecânica do produto: o state entra uma vez e cada pergunta soma apenas os próprios tokens. A consequência é o padrão de fan-out especulativo — perguntar algo que talvez você não use é quase gratuito, e a receita completa está em perguntas paralelas.

Uma ressalva honesta que o próprio cookbook faz: o ganho de tempo supõe as treze chamadas em sequência. Disparadas em paralelo, a diferença de tempo encolhe — mas o custo de reenviar o documento treze vezes continua igual.

O que a conta mostra

Usando a fórmula do site — tokens de entrada divididos por um milhão, vezes US$ 0,042, vezes o dólar estimado em R$ 5,40 — e assumindo cem mil chamadas por mês como volume de exemplo:

O volume e os tamanhos de state são suposições deste artigo, não dado de mercado. A cotação é estimativa comercial do site, revisada em 17 de setembro de 2026, não cotação oficial. A fórmula e as ressalvas estão em quanto custa uma decisão.

A leitura útil da tabela não é o valor absoluto: é a proporcionalidade. Cortar o state pela metade corta a conta pela metade, sempre.

O que não vale a pena cortar

As descrições das opções e dos níveis. Elas são dezenas de tokens por chamada e são exatamente o que separa uma decisão boa de uma ruim. Encurtar a régua para economizar é trocar qualidade por frações de centavo. O assunto está em critérios que separam.

A pergunta especulativa que evita uma segunda chamada. Ela custa os próprios tokens; a segunda chamada custaria o state inteiro de novo.

A precisão do recorte. Cortar demais é pior que cortar de menos: se o trecho que responde à pergunta ficou de fora, você economizou e errou.

Um exercício de uma tarde

Pegue vinte casos com resposta conhecida. Rode duas vezes: com o state que você manda hoje e com o state recortado para os campos que a pergunta usa. Compare três colunas: acerto, confiança média e usage.input_tokens.

Esse experimento responde de uma vez se o corte melhora a decisão, quanto ele economiza e se a confiança sobe junto. Para montar a primeira chamada e ler os tokens da resposta, veja primeiros passos e o contexto de 64k.

Para o orçamento completo de um volume grande, veja o orçamento de 100 mil decisões, e para a calculadora com o seu número, preço.