Un token es la unidad mínima de texto que procesa un modelo de lenguaje: puede ser una palabra completa, parte de ella o un signo de puntuación, y la API factura por número de tokens, no por caracteres ni por palabras. Para estimar el coste de un texto hay que contar por separado los tokens de entrada (prompt, instrucciones e historial) y los de salida (respuesta generada), multiplicar cada cifra por su precio por token y sumar ambos resultados. Con una fórmula sencilla y un ejemplo numérico se obtiene un presupuesto razonable; los desvíos suelen venir de olvidar el prompt del sistema, el historial de conversación o la diferencia entre estimar con una regla rápida y contar con el tokenizador real.
Qué es un token y por qué se factura así en la API
Un token es un fragmento de texto que el modelo trata como unidad atómica. Los modelos no leen letras ni palabras: usan un tokenizador, normalmente basado en BPE (Byte Pair Encoding, un algoritmo que agrupa los caracteres más frecuentes en piezas reutilizables), que convierte el texto en una secuencia de identificadores numéricos. En español, una palabra corriente suele equivaler a uno o dos tokens, y las palabras largas, los acrónimos o los signos poco habituales pueden fragmentarse en más piezas. Los espacios, los saltos de línea y la puntuación también consumen tokens.
La facturación se hace por tokens porque es la unidad que el modelo procesa de verdad: el coste computacional crece con la longitud de la secuencia de tokens, no con el número de caracteres. Además, el precio se divide en dos conceptos: tokens de entrada (todo lo que envías en la petición: instrucciones, ejemplos, contexto e historial) y tokens de salida (lo que el modelo genera). Los precios por token son distintos para cada dirección, así que un presupuesto correcto necesita ambas cifras por separado.
Conviene distinguir tres magnitudes que se confunden con facilidad: caracteres, palabras y tokens. La relación entre ellas no es fija y depende del idioma, del dominio (código, texto jurídico, chat informal) y del tokenizador concreto del modelo. Por eso cualquier regla rápida es una aproximación, no una medición.
Fórmula para estimar tokens de entrada y salida de un texto
La estimación práctica parte de una regla de conversión y de una estructura de coste. Para español, una aproximación razonable es entre 3 y 5 caracteres por token, con una media típica cercana a 4 en texto narrativo y algo menos en texto con muchas palabras largas, cifras o símbolos. En palabras, suele hablarse de aproximadamente 1,3 a 2 tokens por palabra en español, frente a valores algo menores en inglés. Son rangos estimados, no garantías.
La fórmula básica, en pseudocódigo, sería:
tokens_entrada ≈ caracteres_prompt / caracteres_por_token
tokens_salida ≈ caracteres_respuesta_esperada / caracteres_por_token
coste_entrada = tokens_entrada * precio_entrada_por_token
coste_salida = tokens_salida * precio_salida_por_token
coste_total = coste_entrada + coste_salida
Para un presupuesto mensual hay que multiplicar el coste por petición por el número de peticiones y añadir los elementos que se repiten en cada llamada:
tokens_entrada_peticion = tokens_sistema + tokens_historial + tokens_usuario
coste_mensual ≈ peticiones_mes * (tokens_entrada_peticion * precio_entrada
+ tokens_salida_peticion * precio_salida)
Dos precisiones importantes. Primero, el prompt del sistema y el historial de conversación se envían en cada petición, así que su coste se multiplica por el número de llamadas, no se paga una sola vez. Segundo, la salida es la parte menos predecible: fijar un límite de tokens de salida (max tokens) acota el coste máximo, pero no garantiza que el modelo use todo ese margen. Para afinar la estimación, lo recomendable es medir con el tokenizador del modelo en una muestra representativa de textos y calcular el ratio real de caracteres por token en tu caso concreto.
Ejemplo numérico: de un párrafo a un presupuesto mensual
Supongamos que tienes un párrafo de 900 caracteres (con espacios) y quieres estimar su coste. Usamos la regla práctica de que, en español, un token equivale aproximadamente a 4 caracteres (es una estimación: en inglés suele rondar 4; en español, por la mayor longitud media de las palabras y los acentos, suele estar entre 3,5 y 4,5). Trabajamos con 4 como valor de referencia y lo declaramos como supuesto.
tokens_entrada ≈ caracteres / 4 = 900 / 4 = 225
Si además el modelo devuelve una respuesta de 300 caracteres:
tokens_salida ≈ 300 / 4 = 75
Ahora pon precios hipotéticos para ilustrar el cálculo (no son precios reales; sustitúyelos por la tarifa vigente de tu proveedor, expresada en unidades monetarias por millón de tokens):
precio_entrada = 3 por 1.000.000 de tokens
precio_salida = 15 por 1.000.000 de tokens
coste_una_llamada = (225 / 1.000.000) * 3 + (75 / 1.000.000) * 15
= 0,000675 + 0,001125
= 0,0018
Cada llamada cuesta unas 0,0018 unidades. Si haces 2.000 llamadas al mes:
coste_mensual ≈ 0,0018 * 2.000 = 3,6
Y si a cada llamada le sumas un prompt de sistema de 200 tokens (que se envía en cada petición):
tokens_entrada_totales = 225 + 200 = 425
coste_llamada = (425 / 1.000.000) * 3 + (75 / 1.000.000) * 15
= 0,001275 + 0,001125
= 0,0024
coste_mensual = 0,0024 * 2.000 = 4,8
Ese salto de 3,6 a 4,8 muestra por qué el prompt de sistema y el historial pesan tanto en la factura: se recalculan en cada turno.
Errores comunes al presupuestar y cómo evitarlos con el calculador
Checklist para revisar antes de dar un número por bueno:
- Contar solo el texto visible. El prompt de sistema, las instrucciones de formato y el historial de la conversación también son tokens de entrada. Súmalos siempre.
- Ignorar que el historial crece. En un chat de varios turnos, cada respuesta previa se reenvía. El coste no es lineal con el número de mensajes.
- Mezclar caracteres con tokens. No son intercambiables. Si mides en caracteres, aplica el divisor (≈4 en español) y trátalo como estimación, no como cifra exacta.
- Usar el mismo precio para entrada y salida. Suelen diferir; la salida casi siempre cuesta más. Separa ambas partidas en la fórmula.
- Olvidar el redondeo y los mínimos. Algunos proveedores redondean por petición o tienen cargos fijos. Añade un margen del 10–20 % como colchón.
- Extrapolar de una sola muestra. Un párrafo corto no representa correos largos o tablas. Mide varios textos reales y usa la media.
Idea de calculador mínimo (pseudocódigo):
funcion coste(texto_entrada, texto_salida, sys, historial, p_in, p_out):
t_in = (long(texto_entrada) + long(sys) + long(historial)) / 4
t_out = long(texto_salida) / 4
return (t_in/1e6)*p_in + (t_out/1e6)*p_out
# uso: multiplica por nº de llamadas y añade margen del 15 %
Valida el resultado contrastándolo con el conteo real de tokens del tokenizador del modelo cuando puedas; si tu estimación se desvía más de un 15–20 %, ajusta el divisor según tus propios textos.
Preguntas frecuentes
¿Cuántos tokens consume aproximadamente una palabra en español?
En español, una regla práctica es contar entre 1,3 y 1,7 tokens por palabra, con una media razonable de 1,5 para texto narrativo o expositivo corriente. La variación depende de la longitud de las palabras y del tokenizador (el algoritmo que divide el texto en unidades facturables, normalmente BPE o byte-pair encoding); las palabras cortas y frecuentes suelen ocupar un token, mientras que las largas o con tildes y signos raros se fragmentan en dos o tres. Para una estimación rápida, dividir el número de palabras entre 0,7 equivale a multiplicarlas por ~1,4. Conviene tratar estas cifras como aproximaciones y validarlas con el tokenizador real del modelo que vayas a usar.
¿Los tokens de entrada y de salida cuestan lo mismo?
No, casi nunca. En la mayoría de APIs de LLM el precio por token de salida (lo que genera el modelo) es varias veces superior al de entrada (lo que envías en el prompt), porque la generación requiere cómputo secuencial token a token. Por eso, al presupuestar, separa siempre ambos importes: coste = (tokens_entrada × precio_entrada) + (tokens_salida × precio_salida). No des por hecho una proporción concreta entre ambos precios: consulta la tarifa vigente del proveedor y aplícala. Si tu caso de uso genera respuestas largas, el coste de salida dominará el total aunque el prompt sea enorme.
¿Por qué mi estimación de tokens no coincide con la factura real?
Hay tres causas habituales. Primera, usaste una regla aproximada (caracteres o palabras) en lugar del tokenizador exacto del modelo. Segunda, olvidaste elementos que también se facturan como entrada: el prompt del sistema, el historial de la conversación, las definiciones de herramientas o funciones y los formatos internos que añade la API. Tercera, la salida real difiere de la que estimaste: el modelo puede responder más o menos de lo previsto, y en modo streaming o con reintentos se pueden generar tokens que igualmente se cobran. La estimación sirve para presupuestar, no para cuadrar céntimos: deja un margen del 10–20 % y mide con datos reales para calibrar.
¿Cómo influye el prompt del sistema y el historial en el coste?
Ambos se envían en cada llamada como tokens de entrada, así que se cobran una y otra vez. Un prompt de sistema de 300 tokens en una conversación de 20 turnos añade unos 6.000 tokens de entrada solo por repetirse. El historial crece de forma acumulativa: si reenvías todos los mensajes previos, el coste de entrada aumenta con cada turno (crecimiento aproximadamente cuadrático respecto al número de turnos). Para controlarlo, recorta el historial a los últimos N mensajes, resume lo antiguo o usa almacenamiento de contexto del proveedor si lo ofrece. Calcula el coste por turno incluyendo sistema + historial + mensaje nuevo, no solo el mensaje.
¿Conviene contar tokens con BPE o usar una regla de 4 caracteres por token?
La regla de ~4 caracteres por token es una heurística rápida pensada sobre todo para inglés; en español suele quedarse corta porque las palabras son más largas, y un valor más ajustado ronda 3–3,5 caracteres por token. Úsala solo para estimaciones gruesas o cuando no tengas acceso al tokenizador. Para presupuestos que deban ser fiables, cuenta con el tokenizador BPE real del modelo (muchas librerías y APIs lo exponen), que da el número exacto de tokens de entrada. Un enfoque mixto funciona bien: BPE para validar y una regla calibrada con tus propios textos para proyecciones rápidas.