Planificador de Presupuesto de Tokens

Sobre el Planificador de Presupuesto de Tokens

Los prompts largos se truncan en silencio, los pipelines de generación aumentada por recuperación fallan a mitad de camino y la factura del modelo se dispara — casi siempre porque nunca se planificó el presupuesto. Este planificador te ofrece una estimación sin API, totalmente en el navegador, de cuántos tokens consumirá tu texto en Claude Opus/Sonnet, Claude 1M, GPT-4o, GPT-5/o3, Gemini 2.x, Llama 3.1, Mistral Large o cualquier límite personalizado, y luego divide el texto en fragmentos seguros con una ventana de solapamiento configurable.

Reserva tokens para la respuesta, el system prompt y los esquemas de herramientas; después elige división por párrafo, oración o caracteres. Cada fragmento se puede copiar individualmente para pipelines de recuperación, resumen por lotes o conversaciones secuenciales.

¿Qué tan precisa es la estimación frente al tokenizador real de Anthropic, OpenAI o Google?

Nuestra estimación es una heurística de planificación, típicamente con un margen del 5-15% sobre el conteo real para prosa en inglés, 10-20% para código fuente y 15-25% para idiomas CJK. Deliberadamente no cargamos librerías de tokenización (tiktoken, anthropic-tokenizer, gemini tokenizer) porque añaden 2-15 MB de WASM y algunas requieren llamadas al servidor. El estimador usa la regla bien documentada de 1 token ≈ 4 caracteres en inglés ≈ 0,75 palabras, ajustada por tipo de texto: los caracteres CJK son mayoritariamente 1 token cada uno (~1,5 chars/token), el código tiene más puntuación (~3,5 chars/token) y el contenido mixto/markdown mezcla ambos. Para facturación exacta usa el tokenizador del proveedor; para planificar si un documento de 240k tokens cabe en una ventana de 200k, esta herramienta te da la respuesta correcta.

¿Por qué dividir con solapamiento en lugar de cortes limpios en los párrafos?

Sin solapamiento, una pregunta o dato mencionado al final del fragmento 1 no tiene respuesta visible en el fragmento 2 aunque la respuesta esté en su cuerpo, porque el modelo en el fragmento 2 carece del contexto de la pregunta. Un solapamiento del 5-15% (por defecto 10%) repite la cola del fragmento N como cabecera del N+1, preservando referencias, argumentos en curso, ítems de lista y cabeceras de tabla. Para RAG puro, 10% suele bastar; para resumen legal o científico con razonamiento multi-párrafo, sube a 20-25%; para chat breve o extracción de FAQs donde cada fragmento es independiente, puedes bajar a 0%.

¿Qué debo poner en 'reservado para salida' y por qué importa?

Toda API LLM moderna consume entrada + salida del mismo contexto. Si tu modelo tiene 200.000 tokens y rellenas 199.000 con el prompt, solo puede generar 1.000 antes de truncarse — a menudo a mitad de frase. Reserva al menos max_tokens (lo que pasarás en la llamada API) más un margen. Valores prácticos: 4.096 para chat normal, 8.192 para resumen largo, 16.384-32.768 para generación de código, y 64.000+ para modelos de razonamiento como o3/o1 que consumen muchos tokens de pensamiento ocultos. El extended thinking de Claude y el thinking mode de Gemini también gastan presupuesto reservado invisiblemente — sube la reserva un 30-50% si los activas.

¿Los system prompts, esquemas de funciones y archivos subidos cuentan en el límite de contexto?

Sí — cada entrada que recibe la API cuenta en la misma ventana de contexto total. Un stack típico de agente quema 2.000-8.000 tokens antes de que llegue la entrada del usuario: un system prompt de 500-2.000 tokens, esquemas de tools/funciones (cada esquema JSON ronda 50-300 tokens, y los agentes suelen exponer 5-20 = 1.000-6.000 tokens), más PDFs/imágenes subidos ya convertidos a texto. Configura 'system prompt tokens' y 'tokens de herramientas' con honestidad — si el planificador muestra 195k disponibles de 200k, ese es el presupuesto real tras la sobrecarga del agente.

¿Cuándo usar Claude 1M, Gemini 2.x 1M o fragmentar en un modelo más pequeño?

Los modelos de 1M tokens parecen mágicos pero tienen tres costes reales: (1) latencia — el primer token puede tardar 30-90 segundos con 800k+ de entrada; (2) precio — los tokens de entrada se facturan aunque el modelo atienda solo a una fracción; y (3) degradación del recall — la mayoría de modelos 1M muestran caídas de precisión medibles pasados los ~400k tokens, especialmente en recuperación a mitad de documento ('lost in the middle'). Regla práctica: si tu documento completo está bajo 150k tokens, usa un modelo estándar de 200k. 150k-500k con razonamiento de largo alcance: usa 1M nativo. 500k+ o cargas repetitivas en producción: fragmenta y usa un modelo más pequeño con recuperación.

¿Cómo uso los fragmentos para RAG o resumen por lotes?

Tres patrones comunes. (1) Map-reduce: envía cada fragmento por separado con el mismo prompt ('resume esta sección'), reúne las salidas y haz un segundo pase fusionando los resúmenes. (2) Recuperación aumentada: embebe cada fragmento con un modelo de embeddings (text-embedding-3-small, voyage-3, gemini-embedding), guarda en una BD vectorial (Qdrant, pgvector, Pinecone) y recupera top-K en consulta. Para embeddings, usa fragmentos de 200-800 tokens — mucho más pequeños; ajusta 'ventana de contexto' al límite del modelo de embeddings (8192 OpenAI, 32k Voyage). (3) Conversación secuencial: alimenta los fragmentos uno a uno en diálogo multi-turno pidiendo al modelo que recuerde datos clave.

¿Por qué difieren las estimaciones para CJK y código frente al inglés?

Los tokenizadores BPE y SentencePiece dividen subcadenas comunes en tokens únicos. En inglés, 'the', 'and', 'tion' son un token, pero las palabras raras se dividen en 2-4 tokens, promediando ~4 caracteres/token. Los textos en chino, japonés y coreano son mayoritariamente caracteres individuales — los tokenizadores de Anthropic, OpenAI y Google mapean la mayoría de caracteres CJK a un token, dando ~1,5 chars/token. El código fuente está lleno de puntuación de un solo carácter ({}, [], (), ;, :, .) e identificadores cortos que cada uno consume un token, más indentación — ~3,5 chars/token. Usa la opción 'mixto' para markdown, JSON o escritura técnica que mezcla prosa y código.

¿Funciona offline y mi prompt se envía a algún sitio?

Totalmente offline tras cargar la página. Toda la estimación, división y solapamiento se ejecuta en tu navegador con JavaScript puro — sin llamadas API, sin telemetría, sin subida al servidor. Puedes desconectar la red y la herramienta sigue funcionando. Elegimos estimación heurística precisamente para nunca enviar tu prompt a un servicio remoto. Para contenido sensible (contratos legales, registros médicos, código fuente, documentos internos), esta herramienta es segura. Lo único que sale de tu navegador son las analíticas estándar de visitas si no las has desactivado en la configuración de privacidad.