O Jev tem dois orçamentos de contexto, e confundi-los é a origem de um erro
422 que parece inexplicável: a requisição inteira cabe, e mesmo assim é
recusada.
Os dois números
A página oficial de modelos declara:
| Orçamento | Cobre |
|---|---|
| 64.000 tokens | o state mais todas as perguntas combinadas |
| 32.000 tokens | o state mais a maior pergunta, sozinha |
O segundo é o que costuma apertar primeiro, e é o menos intuitivo. Ele
significa que o tamanho do seu documento compete com o tamanho da sua
pergunta mais longa, não com a soma de todas. Uma pergunta de Choice com
duzentas opções descritas é grande, e ela sozinha come esse orçamento junto com
o state.
Para estimativa rápida, a documentação de primitivas dá uma referência: o orçamento de cerca de 32 mil tokens equivale a mais ou menos 150 mil caracteres de texto em inglês. É aproximação para planejar, não conversão exata.
Por que o state entra uma vez
A mecânica que explica os dois números é a mesma que explica o preço: o Jev
ingere o state uma vez e avalia todas as perguntas contra ele em paralelo. Os
64 mil cobrem o pacote inteiro; os 32 mil protegem o par mais pesado.
A consequência prática é boa: a documentação afirma que o número de perguntas
em uma requisição é limitado apenas pelo orçamento de tokens, que o state e
as perguntas dividem. Como o state domina em quase todo caso real, sobra
espaço para dezenas de perguntas curtas. É o que sustenta o padrão de
fan-out especulativo e está detalhado em
várias perguntas numa chamada.
Como contar
O jeito confiável é medir depois: a resposta traz usage.input_tokens.
Guarde esse número junto com o identificador do item, e em uma semana você tem
a distribuição real do seu tráfego, que vale mais que qualquer estimativa.
Nas nossas cinco chamadas de 18 de setembro de 2026, com seis perguntas cada sobre textos curtos de suporte em português, a média foi de 955 tokens de entrada. Uma análise do nosso playground em produção registrou 994 tokens e 422 milissegundos. Ou seja: um caso típico de triagem usa cerca de 3% do orçamento menor. Quem está longe do teto é a maioria.
Para estimar antes de chamar, use a equivalência de caracteres e deixe folga. Quem precisa de precisão no limite deve medir com o próprio conteúdo, porque texto em português tende a render menos caracteres por token que inglês, e JSON com muitas chaves curtas rende ainda menos.
Como fatiar quando não cabe
Três estratégias, em ordem de preferência.
Primeiro, corte. A maior parte dos state grandes é grande por acidente:
cabeçalho, rodapé, assinatura, histórico encadeado, campos que a pergunta não
usa. Cortar é melhor que fatiar, porque também melhora a resposta.
Segundo, filtre com uma pergunta. Quando você não sabe de antemão o que é relevante, use uma passagem barata que pontua trechos e só depois mande os aprovados. É o desenho da receita de classificar passagens de RAG.
Terceiro, divida em janelas com sobreposição. Para um documento que precisa ser lido inteiro, fatie em blocos que caibam com folga, com alguma sobreposição para não cortar uma frase no meio, e combine as respostas no seu código. A receita de busca linha a linha mostra uma variante: numerar as linhas e pontuar cada uma — com o teto de 255 opções por pergunta de escolha, o que dá 255 linhas por passagem.
Caber não é o mesmo que ajudar
Este é o ponto que fecha a página. O limite de 64 mil é uma barreira de API: ou você passa ou recebe erro. A queda de qualidade começa muito antes dele.
A documentação lista “state grande cheio de detalhe irrelevante” entre os nove
modos de falha declarados do jev-1.13, e explica o mecanismo: o conteúdo não
relacionado age como distrator, e um state grande ainda dificulta descobrir
qual parte da entrada produziu a resposta errada. O efeito tem nome próprio e
página própria em context rot.
Há ainda o lado da fatura. O Jev cobra por token de entrada, e o state domina
essa conta. Cortar contexto irrelevante é a rara decisão que melhora a
acurácia e reduz o custo ao mesmo tempo; a conta está em
quanto custa uma decisão e as táticas em
economizar tokens de entrada.
Uma regra de bolso
Se você está perto do orçamento, quase sempre está mandando coisa demais. O
teste que resolve a dúvida leva uma tarde: pegue vinte casos com resposta
conhecida, rode com o state que você manda hoje e com o state recortado
para os campos que a pergunta usa, e compare acerto, confiança média e tokens
de entrada.
O índice da integração está em como usar, e os limites de requisição por minuto em limites de taxa.
Perguntas frequentes
Quais são os limites de contexto do Jev?
A página oficial de modelos declara 64 mil tokens por requisição, cobrindo o state mais todas as perguntas combinadas, e 32 mil tokens para o state mais a pergunta mais longa.
Quantos caracteres cabem em 32 mil tokens?
A documentação de primitivas dá a referência: cerca de 150 mil caracteres de texto em inglês. É uma aproximação para você estimar antes de medir, não uma conversão exata, e português costuma render menos caracteres por token que inglês.
Existe limite de quantas perguntas eu posso mandar?
Não em contagem. A documentação diz que o número de perguntas em uma requisição é limitado apenas pelo orçamento de tokens, que o state e as perguntas dividem. Como o state domina, sobra espaço para dezenas de perguntas curtas.
Se eu couber no limite, a resposta é boa?
Não necessariamente. O limite é uma barreira de API; a queda de acurácia por state grande com conteúdo irrelevante começa muito antes dele. A documentação chama esse efeito de context rot e o lista entre os modos de falha declarados.
Como eu conto os tokens antes de chamar?
O caminho confiável é medir depois: a resposta traz usage.input_tokens. Para estimar antes, use a equivalência aproximada de caracteres da documentação e deixe folga, porque a contagem exata depende do tokenizador.