Não existe um número máximo de perguntas. A documentação oficial é direta:
o número de perguntas em uma requisição é limitado apenas pelo orçamento de
tokens, que o state e as perguntas dividem.
São dois orçamentos, e vale saber os dois:
| 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 surpreende: o tamanho do conteúdo compete com o tamanho da sua pergunta mais longa, não com a soma de todas.
A conta
Quem consome o orçamento, em praticamente todo caso real, é o state. Uma
pergunta curta — instrução mais três ou quatro descrições de opção — fica na
casa das dezenas de tokens. O documento avaliado fica na casa dos milhares.
Um exemplo com números que medimos. Nas nossas cinco chamadas à API oficial em
18 de setembro de 2026, com seis perguntas cada sobre textos de
atendimento em português, a média foi de 955 tokens de entrada por
chamada, com o modelo jev-1.13.0 respondendo. Ou seja: uma triagem completa,
com escolha, réguas e perguntas de sim ou não, ocupou cerca de 3% do
orçamento menor.
Fazendo a conta ao contrário, para estimar quantas perguntas cabem:
orçamento útil = 32.000 tokens
menos o state = 32.000 - tamanho do seu conteúdo
dividido pelo custo = ÷ ~50 a 150 tokens por pergunta curta
Com um state de 2.000 tokens sobram 30.000, o que comporta algumas centenas
de perguntas curtas. Com um state de 30.000 tokens sobram 2.000, e o limite
real passa a ser bem menor. A variável é o conteúdo, não a lista.
Para estimar antes de chamar, a documentação de primitivas dá a 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; português tende a
render menos caracteres por token. Medir é melhor que estimar, e o campo
usage.input_tokens volta em toda resposta.
Os dois orçamentos, com as estratégias de recorte, estão em o contexto de 64k.
Por que você deveria mandar muitas
A pergunta do título costuma vir de quem teme empilhar perguntas. Com o Jev a
recomendação é a oposta: mande todas as perguntas que usam o mesmo state na
mesma requisição.
Três razões, todas da documentação:
O state entra uma vez. Ele é ingerido por requisição e todas as perguntas
são avaliadas contra ele. Em chamadas separadas, o mesmo conteúdo é reenviado e
recobrado a cada vez.
As perguntas são avaliadas em paralelo. Acrescentar perguntas normalmente não acrescenta latência à resposta.
Elas não interferem umas nas outras. A documentação afirma que cada pergunta é avaliada de forma independente, e que uma resposta não vira contexto para outra.
O número que fecha o argumento vem do cookbook oficial: treze perguntas em uma chamada saíram 12,2 vezes mais baratas e 10,0 vezes mais rápidas que treze chamadas separadas, sem mudança nas respostas. A receita está em perguntas paralelas, e o padrão que nasce disso em fan-out especulativo.
Os limites de forma, que são outros
Não confunda o orçamento de tokens com os tetos de cada primitiva:
- um Choice aceita no máximo 255 opções;
- um Score aceita de 2 a 10 níveis;
- um Noul não tem teto de forma, porque não tem lista.
Esses limites aparecem em casos reais. O cookbook de busca linha a linha pontua ids de linha como opções de um Choice, então ele cobre documentos de até 255 linhas por requisição — acima disso, duas passagens. Em busca linha a linha.
Quando parar de acrescentar
O teto técnico raramente é o que limita. Dois outros chegam antes.
O teto de manutenção. Um mapa com sessenta perguntas é um arquivo que alguém vai ler daqui a um ano. Vale agrupar por assunto, nomear as chaves com o vocabulário do domínio e apagar a pergunta que nenhum ramo lê há meses.
O teto do state. Se você está perto do orçamento, quase sempre está
mandando conteúdo demais, e isso custa acurácia antes de custar erro: “state
grande cheio de detalhe irrelevante” é um dos nove modos de falha declarados.
O efeito está em context rot.
Quando dividir em duas chamadas
A documentação trata isso como exceção, e o critério é claro: duas requisições
só se justificam quando o seu código não consegue montar a segunda sem a
primeira resposta — porque precisa dela para buscar mais dados, para decidir do
que o state é feito, ou para escolher as opções da próxima pergunta.
Se as perguntas da segunda chamada poderiam ter sido feitas contra o state
original, faça tudo na primeira e deixe o código ignorar o que não precisa. O
raciocínio completo está em
várias perguntas numa chamada.
As outras perguntas diretas estão em perguntas.
Perguntas frequentes
Quantas perguntas cabem numa chamada?
Não há limite de contagem. A documentação diz que o número de perguntas é limitado apenas pelo orçamento de tokens, que o state e as perguntas dividem: 64 mil tokens por requisição e 32 mil para o state mais a pergunta mais longa.
Quantos caracteres são 32 mil tokens?
A documentação de primitivas dá a referência aproximada de 150 mil caracteres de texto em inglês. É estimativa para planejar, não conversão exata, e texto em português tende a render menos caracteres por token.
Agrupar perguntas piora a resposta?
No experimento oficial, não. O cookbook de perguntas paralelas fez cada pergunta cinco vezes em lote e cinco vezes sozinha e não encontrou mudança nas respostas. A documentação afirma que cada pergunta é avaliada de forma independente contra o mesmo state.
Qual é o limite de opções de uma pergunta de escolha?
Uma pergunta Choice aceita no máximo 255 opções, e um Score aceita de dois a dez níveis. Esses limites são de forma, diferentes do orçamento de tokens.
Como sei quantos tokens a minha chamada gastou?
Pelo campo usage.input_tokens da resposta. Medir é mais confiável que estimar: nas nossas cinco chamadas de 18/09/2026, com seis perguntas cada, a média foi de 955 tokens de entrada.