Contador de Tokens LLM

Esta página es la guía canónica para contar tokens LLM en el navegador con DevUtilities. Use el Prompt Budget Cockpit interactivo de arriba mientras lee, o salte a un tema abajo. Todo se ejecuta en el cliente vía js-tiktoken — los prompts nunca salen de su máquina.

El LLM Token Counter (Prompt Budget Cockpit) tokeniza texto con las mismas tablas BPE que OpenAI incluye en tiktoken. Compara tres codificaciones en paralelo, visualiza límites de tokens, estima el coste de entrada para GPT-4o, GPT-4o mini y Claude 3.5 Sonnet, y le ayuda a reducir prompts antes de que lleguen a una API de producción.

Qué obtiene

• Conteos concurrentes para o200k_base (GPT-4o), cl100k_base (aproximación GPT-4 / Claude) y p50k_base (Codex legado)
• Mapa de límites de tokens con código de color e IDs de token al pasar el cursor
• Acciones Minify JSON y Strip Spaces para reducir el peso del prompt
• Extrapolaciones de coste por consulta y mensuales a partir de tarifas de entrada publicadas estáticas
• Métricas multi-codificación copiables para documentos de diseño y revisiones de presupuesto

Use esta herramienta cuando

• Necesite saber si un system prompt + tools + mensaje de usuario cabe en una ventana de contexto
• Esté comparando presupuestos de tokens GPT-4o vs estilo Claude antes de elegir un modelo
• Quiera un conteo local y privado sin llamar a las APIs de OpenAI o Anthropic
• Esté recortando chunks RAG, ejemplos few-shot o schemas JSON que inflan el coste

No espere

• Facturación Claude idéntica byte a byte — Anthropic usa otro tokenizador de producción; cl100k_base es una aproximación útil en inglés
• Overhead del envoltorio de chat (etiquetas de rol, envelopes de tools) que las APIs añaden alrededor del texto crudo
• Precios de mercado en vivo — el panel de costes usa tarifas publicadas estáticas que pueden desfasarse

Los IDs de token son específicos de la codificación. La misma frase en inglés puede producir longitudes e IDs distintos bajo o200k_base vs cl100k_base. Presupueste siempre con la codificación que usa realmente su modelo objetivo.

Cambie la codificación del Token Boundary Map de forma independiente de las tarjetas de comparación cuando necesite inspeccionar merges de una familia de modelos concreta.

Siga esta guía la primera vez que abra el cockpit. Después, la mayoría de sesiones son pegar → comparar → optimizar → copiar.

1. Pegue el payload completo del prompt que le importa: mensaje de sistema, turno de usuario, JSON de tools o un bloque de contexto RAG concatenado.
2. Lea las tres tarjetas de comparación. Anote qué codificación es la más alta — ese es su presupuesto conservador si aún debe elegir un modelo.
3. Abra el Token Boundary Map y pase el cursor por tramos que parezcan sorprendentemente largos (URLs, emoji, JSON indentado) para ver IDs de token concretos.
4. Si la entrada es densa en JSON, pulse Minify JSON. Si es prosa con dobles espacios o saltos de línea rellenos, pulse Strip Spaces.
5. Introduzca su volumen mensual estimado de llamadas para proyectar el gasto de entrada de GPT-4o, GPT-4o mini y Claude 3.5 Sonnet.
6. Copie el resumen de métricas a un documento de diseño, ticket o descripción de PR para que el equipo comparta un solo número.

Cómo se ve un resultado «bueno»

• System + tools + turno medio de usuario dejan margen para la respuesta del modelo dentro de la ventana de contexto elegida
• Los schemas JSON se minifican en prompts de producción aunque los humanos editen copias con formato bonito
• Las extrapolaciones de coste usan la codificación que coincide con el modelo facturado

Problema: un prompt de agente de soporte se trunca a mitad de conversación tras añadir políticas, reglas de tono y tres ejemplos few-shot.

Cómo lo resuelve esta herramienta

1. Pegue solo el system prompt actual y registre el conteo o200k_base (o cl100k_base).
2. Añada cada ejemplo few-shot de uno en uno y anote el delta — elimine primero el ejemplo menos valioso.
3. Pegue un mensaje de usuario representativo y el JSON de tools que envía en cada llamada; sume las piezas frente a la ventana de contexto de su modelo.
4. Use Strip Spaces en la prosa y Minify JSON en los schemas, luego vuelva a contar para cuantificar el ahorro.
5. Copie el presupuesto final a su runbook del agente para que futuras ediciones del prompt respeten el mismo techo.

Resultado: sabe exactamente qué sección rompió el presupuesto y cuántos tokens recuperó cada optimización — antes de otro truncado en producción.

Problema: los schemas de function-calling de OpenAI se escriben con indentación para legibilidad y luego se pegan en peticiones en vivo. El gasto de tokens sube aunque el schema lógico no cambió.

Cómo lo resuelve esta herramienta

1. Pegue el array de tools o el objeto parameters con formato bonito en el panel de entrada.
2. Anote el conteo de tokens en la codificación que usa su modelo de API (normalmente o200k_base para GPT-4o).
3. Pulse Minify JSON y compare el nuevo conteo — la diferencia es puro impuesto de espacios en blanco.
4. Inspeccione el boundary map: claves repetidas y listas enum largas suelen dominar; acorte descripciones antes de cortar campos.
5. Envíe el schema minificado en las llamadas API; conserve la copia bonita solo en el control de versiones o en el editor de Agent Builder.

Resultado: menor coste de entrada en cada llamada con tools sin cambiar el comportamiento de las herramientas.

Problema: finanzas pide una estimación mensual de gasto LLM antes de lanzar una función que llamará al modelo miles de veces.

Cómo lo resuelve esta herramienta

1. Construya un payload medio realista (system + tools + texto típico de usuario) y péguelo aquí.
2. Confirme la tarjeta de comparación de la codificación que coincide con su modelo de producción.
3. Establezca Estimated monthly volume en su recuento de llamadas proyectado.
4. Lea las columnas mensuales de GPT-4o, GPT-4o mini y Claude 3.5 Sonnet para comparar proveedores con el mismo payload.
5. Documente que las tarifas son precios de entrada publicados estáticos — actualice la estimación cuando los proveedores cambien sus páginas de precios.

Resultado: un pronóstico defendible y específico del payload en lugar de una conjetura vaga de que «los tokens son baratos».

Problema: un pipeline RAG recupera cinco chunks por consulta. Algunos son sobre todo espacios o cabeceras boilerplate, y el modelo sigue fallando la respuesta porque el texto útil se truncó.

Cómo lo resuelve esta herramienta

1. Pegue cada chunk candidato por separado y registre los conteos bajo la codificación de su modelo de recuperación.
2. Prefiera chunks más densos: Strip Spaces, quite cabeceras de navegación repetidas y elimine párrafos casi duplicados.
3. Concatene el conjunto top-k que planea enviar y verifique que el total aún deja espacio para la pregunta y la respuesta.
4. Use el boundary map para detectar secuencias caras para el tokenizador (URLs largas, tablas, emoji) que parecen cortas a los humanos.
5. Fije un presupuesto duro de tokens por consulta en su retriever usando los totales medidos con esta herramienta.

Resultado: la recuperación empaqueta más señal por token y falla menos por truncado silencioso de contexto.

Síntomas: API 400 context_length_exceeded, completions truncadas o agentes que «olvidan» instrucciones tempranas a mitad de sesión.

Por qué ocurre

El system prompt, tools, historial y turno de usuario combinados superan la ventana de contexto del modelo. El JSON con formato bonito y bancos few-shot largos son ofensores silenciosos habituales.

Diagnosticar

Pegue el payload exacto que envía su cliente (o reconstruyalo). Compare el total de tokens con la ventana de contexto listada para su modelo. Identifique las secciones más grandes contándolas por separado.

Soluciones

1. Minify JSON de schemas de tools y quite el exceso de espacios en blanco de la prosa.
2. Mueva políticas poco usadas a recuperación bajo demanda en lugar del system prompt siempre activo.
3. Limite el historial de chat (resuma o elimine los turnos más antiguos) antes de cada llamada.
4. Cambie a un modelo de mayor contexto solo después de medir — no adivine.

Vuelva a contar tras cada cambio. Un recorte del 10% de espacios en un blob de tools de 8k tokens suele recuperar más margen que borrar un párrafo corto de política.

Síntomas: los conteos locales parecen bien, pero los paneles de uso de OpenAI discrepan — o Claude factura distinto a su hoja de cálculo.

Por qué ocurre

Presupuestó con la codificación incorrecta, o comparó texto crudo con una API que envuelve mensajes con envelopes de rol y tools.

Diagnosticar

Confirme el tokenizador documentado del modelo. Para la familia GPT-4o use o200k_base; para GPT-4 / 3.5 use cl100k_base. Trate las cifras Claude aquí solo como aproximaciones.

Soluciones

1. Cambie el foco de comparación y el boundary map a la codificación coincidente.
2. Cuente los mensajes serializados que su SDK envía realmente, no solo el borrador legible del prompt.
3. Añada un pequeño buffer de overhead (a menudo de unas docenas a unos cientos de tokens) por el formato de chat al planificar límites duros.
4. Para facturación Anthropic, valide prompts críticos con el contador propio de Anthropic antes de fijar SLAs.

Síntomas: el conteo de tokens cae drásticamente tras Minify JSON o Strip Spaces sin cambio semántico del prompt.

Por qué ocurre

Las codificaciones BPE cobran por saltos de línea de indentación, espacios de alineación y líneas en blanco repetidas. Los humanos los ignoran; los tokenizadores no.

Diagnosticar

Pegue el payload bonito, anote el conteo, ejecute Minify JSON / Strip Spaces y compare. Deltas grandes significan que el espacio en blanco era un motor principal de coste.

Soluciones

1. Guarde JSON bonito editable por humanos en git; minifique en el momento de la petición.
2. Evite rellenar diagramas ASCII o logs enormes indentados dentro de system prompts.
3. Colapse separadores de sección con varias líneas en blanco en documentos de política largos.

El boundary map hace visibles los tokens de espacio en blanco como tramos de color separados — útil al enseñar al equipo por qué importa minificar.

El Token Boundary Map pinta cada merge BPE como un tramo de color. Los colores ciclan solo para separación visual — no codifican categorías de token.

Cómo leerlo

• Pase el cursor por un tramo para ver su Token ID numérico de la codificación del mapa seleccionada
• Tramos largos ininterrumpidos en URLs o base64 suelen significar chunks caros de uno o pocos tokens que conviene acortar
• Emoji y texto CJK pueden usar más tokens que prosa latina de la misma longitud visual
• Cambie la codificación del mapa al comparar cómo GPT-4o vs GPT-4 segmentarían la misma cadena

Las tarjetas de coste multiplican conteos locales de tokens por tarifas de entrada publicadas estáticas: GPT-4o $5 / 1M, GPT-4o mini $0.15 / 1M, Claude 3.5 Sonnet $3 / 1M. El volumen mensual escala el coste por consulta.

Advertencias

• Los tokens de salida no están incluidos — añada estimaciones de completion por separado para el TCO completo
• No se modelan descuentos de input en caché ni por lotes
• Los precios de lista de los proveedores cambian; trate las cifras como ayudas de planificación, no como facturas

• Presupueste con la codificación que coincide con producción, luego mantenga un margen de seguridad del 10–20% para wrappers de chat y reintentos
• Cuente la forma completa de la petición (system + tools + historial + usuario), no solo el system prompt
• Minifique el JSON consumido por máquinas; conserve copias bonitas para humanos
• Vuelva a contar cada vez que añada ejemplos few-shot, configs MCP o apéndices de política largos
• Use proyecciones de volumen mensual en revisiones de diseño para que el coste sea visible antes del lanzamiento
• Prefiera el conteo local para prompts propietarios — esta herramienta nunca sube su texto

Los colores de límite se mapean a codificaciones byte-pair de tiktoken. Tokens especiales como <|endoftext|> se cuentan cuando están presentes como texto literal.