Planejador de Orçamento de Tokens

Sobre o Planejador de Orçamento de Tokens

Prompts longos são silenciosamente truncados, pipelines de geração aumentada por recuperação falham no meio do caminho e a fatura do modelo explode — quase sempre porque o orçamento nunca foi planejado. Este planejador oferece uma estimativa sem API, totalmente no navegador, de quantos tokens seu texto consumirá em Claude Opus/Sonnet, Claude 1M, GPT-4o, GPT-5/o3, Gemini 2.x, Llama 3.1, Mistral Large ou qualquer limite personalizado, e depois divide o texto em pedaços seguros com uma janela de sobreposição configurável.

Reserve tokens para a resposta, system prompt e schemas de ferramentas; depois escolha divisão por parágrafo, frase ou caracteres. Cada pedaço pode ser copiado individualmente para pipelines de recuperação, resumo em lote ou conversas sequenciais.

Qual a precisão da estimativa comparada ao tokenizador real da Anthropic, OpenAI ou Google?

Nossa estimativa é uma heurística de planejamento, tipicamente dentro de 5-15% da contagem real para prosa em inglês, 10-20% para código-fonte e 15-25% para idiomas CJK. Deliberadamente não carregamos bibliotecas de tokenização (tiktoken, anthropic-tokenizer, gemini tokenizer) porque adicionam 2-15 MB de WASM e algumas requerem chamadas ao servidor. O estimador usa a regra bem documentada de 1 token ≈ 4 caracteres em inglês ≈ 0,75 palavras, refinada por tipo: caracteres CJK são geralmente 1 token cada (~1,5 chars/token), código tem mais pontuação (~3,5 chars/token), e conteúdo misto/markdown combina os dois. Para faturamento exato use o tokenizador do provedor; para planejar se um documento de 240k tokens cabe em janela de 200k, esta ferramenta dá a resposta certa.

Por que dividir com sobreposição em vez de cortes limpos nos parágrafos?

Sem sobreposição, uma pergunta ou fato mencionado no fim do pedaço 1 não tem resposta visível no pedaço 2 mesmo que a resposta esteja no corpo do pedaço 2, porque o modelo no pedaço 2 não tem o contexto da pergunta. Uma sobreposição de 5-15% (padrão 10%) repete a cauda do pedaço N como cabeçalho do N+1, preservando correferência, argumentos em andamento, itens de lista e cabeçalhos de tabela. Para RAG puro, 10% costuma bastar; para resumo jurídico ou científico com raciocínio multi-parágrafo, aumente para 20-25%; para chat curto ou extração de FAQs independentes, pode baixar para 0%.

O que devo colocar em 'reservado para saída' e por que importa?

Toda API LLM moderna consome entrada + saída da mesma janela de contexto. Se seu modelo tem 200.000 tokens e você enche 199.000 com o prompt, o modelo só pode gerar 1.000 antes de truncar — frequentemente no meio da frase. Reserve pelo menos max_tokens (o valor que vai passar na chamada API) mais uma margem. Padrões práticos: 4.096 para chat normal, 8.192 para resumo longo, 16.384-32.768 para geração de código, e 64.000+ para modelos de raciocínio como o3/o1 que consomem muitos tokens de pensamento invisíveis. Extended thinking do Claude e thinking mode do Gemini também gastam orçamento reservado invisivelmente — aumente a reserva 30-50% se ativar.

System prompts, schemas de funções e arquivos enviados contam no limite de contexto?

Sim — toda entrada que a API recebe conta na mesma janela total. Um stack típico de agente queima 2.000-8.000 tokens antes da entrada do usuário: system prompt de 500-2.000, schemas de tools/functions (cada schema JSON é cerca de 50-300 tokens, agentes expõem 5-20 = 1.000-6.000 tokens), mais PDFs/imagens convertidos em texto. Preencha 'system prompt tokens' e 'tokens de ferramentas' honestamente — se o planejador mostra 195k disponíveis de 200k, esse é o orçamento real após overhead do agente.

Quando escolher Claude 1M, Gemini 2.x 1M ou dividir em modelo menor?

Modelos de 1M parecem mágicos mas têm três custos reais: (1) latência — primeiro token pode levar 30-90 segundos com 800k+ de entrada; (2) preço — tokens de entrada são cobrados mesmo quando o modelo atende a só uma fração; (3) degradação de recall — a maioria dos modelos 1M mostra queda mensurável após ~400k tokens, especialmente em recuperação no meio do documento ('lost in the middle'). Regra: documento total abaixo de 150k tokens — use modelo padrão de 200k. 150k-500k com raciocínio de longo alcance — use 1M nativo. 500k+ ou cargas repetitivas em produção — divida e use modelo menor com recuperação.

Como usar os pedaços para RAG ou resumo em lote?

Três padrões comuns. (1) Map-reduce: envie cada pedaço separado com o mesmo prompt ('resuma esta seção'), colete as saídas e faça um segundo passe fundindo. (2) Recuperação aumentada: embede cada pedaço com modelo de embeddings (text-embedding-3-small, voyage-3, gemini-embedding), guarde em vector DB (Qdrant, pgvector, Pinecone), recupere top-K na consulta. Para embeddings, use chunks de 200-800 tokens — bem menores; ajuste 'janela de contexto' ao limite do modelo de embeddings (8192 OpenAI, 32k Voyage). (3) Conversa sequencial: alimente os pedaços um a um em diálogo multi-turno pedindo ao modelo para lembrar fatos-chave.

Por que estimativas para CJK e código diferem do inglês?

Tokenizadores BPE e SentencePiece dividem substrings comuns em tokens únicos. Em inglês, 'the', 'and', 'tion' são um token, mas palavras raras se dividem em 2-4 tokens, em média ~4 caracteres/token. Textos em chinês, japonês e coreano são majoritariamente caracteres individuais — os tokenizadores da Anthropic, OpenAI e Google mapeiam a maioria dos CJK para 1 token, dando ~1,5 chars/token. Código-fonte é cheio de pontuação de um caractere ({}, [], (), ;, :, .) e identificadores curtos que cada um consome um token, mais indentação — ~3,5 chars/token. Use 'misto' para markdown, JSON ou escrita técnica que mistura prosa e código.

Funciona offline e meu prompt é enviado para algum lugar?

Totalmente offline após carregar a página. Toda a estimativa, divisão e cálculo de sobreposição roda no seu navegador em JavaScript puro — sem chamadas API, sem telemetria, sem upload. Pode desconectar a rede e a ferramenta continua funcionando. Escolhemos estimativa heurística justamente para nunca precisar enviar seu prompt a um tokenizador remoto. Para conteúdo sensível (contratos jurídicos, prontuários médicos, código-fonte, documentos internos), esta ferramenta é segura. A única coisa que sai do navegador é analytics de visita padrão se você não desativou nas configurações de privacidade.