Este artículo también está disponible en: 繁體中文 · English · 日本語 · 한국어 · Bahasa Indonesia · Bahasa Melayu · ไทย · Português (Brasil) · Türkçe · Tiếng Việt
Primero, la conclusión: el token no tiene una definición unificada en el sector. Es una «tabla de corte» que queda fijada cuando se entrena cada modelo; si le das el mismo texto a modelos distintos, lo cortan en cantidades distintas de tokens, e incluso los modelos de distintas generaciones de una misma empresa pueden diferir. Por eso la pregunta «¿cuántas palabras es un token?» solo tiene reglas prácticas, no una medida fija.
Lo que el sector sí ha unificado es la estructura de precios (tanto por millón de tokens, con la entrada y la salida cobradas por separado), no el token en sí. Esa diferencia se vuelve crítica en el momento en que intentas armar una hoja de cálculo de costos.
Qué es un token: su objetivo es comprimir, no entender el significado
El token es la unidad mínima de procesamiento en la que el modelo corta el texto. El método de corte viene de una familia de algoritmos llamada BPE (Byte Pair Encoding), en tres pasos:
- Se analizan estadísticamente enormes cantidades de texto y se fusionan una y otra vez las combinaciones de caracteres que aparecen juntas con más frecuencia.
- De esas fusiones sale un vocabulario, que suele tener entre cincuenta mil y doscientas mil entradas.
- A partir de ahí, toda entrada se compara con ese vocabulario y se corta según él.
La clave es que el objetivo de este algoritmo es comprimir, no entender el significado. Las cadenas frecuentes (palabras inglesas como «the» y «and», palabras chinas comunes como 的, «de», y 因為, «porque», o «function» en el código) cuentan como un solo token; las palabras poco frecuentes se trocean, y los nombres propios, los términos especializados y las erratas suelen partirse en tres a cinco tokens.
Así que un token no es una «letra» ni una «palabra»: es «la pieza mínima que este modelo reconoce». Es la premisa para entender todos los problemas de costos que vienen después.
Por qué no puede haber un estándar unificado
Al principio a mí también me pareció raro: en pleno 2026, ¿cómo puede una unidad de cobro tan básica no tener un estándar?
La respuesta es que el vocabulario forma parte de los pesos del modelo y no se puede cambiar después del entrenamiento. En esencia es una pieza del modelo, no una especificación externa, así que la estandarización no tiene ningún punto de apoyo técnico. No se puede exigir a dos empresas que usen el mismo vocabulario; sería exigirles que usen el mismo modelo.
De ahí sale una trampa en la que es todavía más fácil caer: una misma empresa también cambia de tokenizador al cambiar de generación. Claude lo cambió en la generación Opus 4.7, y el mismo texto da un número de tokens distinto al de la generación anterior. Si tu modelo de costos se armó el año pasado, después del cambio de generación esa tabla ya no es exacta, y no da ningún error: simplemente tu estimación se va desviando en silencio.
Reglas prácticas: sirven para estimar, no para presupuestar
| Tipo de contenido | Equivalencia aproximada | Observaciones |
|---|---|---|
| Inglés | 1 token ≈ 4 caracteres, unas 0,75 palabras | La estimación más citada del sector |
| Chino | 1 carácter chino ≈ 0,6 a 1,5 tokens | Un rango muy amplio; el motivo está en la sección siguiente |
| Código y JSON | Claramente más alto | La sangría, las llaves y las comillas también cuestan |
| Imágenes | Según el tamaño | Una imagen suele rondar los mil a dos mil tokens |
Esta tabla solo sirve para una cosa: decidir si algo vale la pena. Para hacerte una idea y decidir si inviertes en ello, alcanza; pero en cuanto entran en juego un presupuesto, una cotización o un compromiso con un cliente, no la uses, porque su error en el texto chino y en el código puede llegar al doble.
Por qué el chino sale perdiendo, y cuánto pierde no es fijo
En la codificación UTF-8, un carácter chino ocupa tres bytes. Si el vocabulario del modelo incluye la palabra que usas, dos o tres caracteres pueden fusionarse en un solo token; si no la incluye, el corte se degrada a algo cercano a byte por byte y un solo carácter puede consumir dos o tres tokens.
Por eso la eficiencia del chino en tokens depende por completo de cuánto texto en chino haya en los datos de ese modelo. Es una línea de costo que casi nunca se explica con claridad: el mismo pasaje en chino puede costar más del doble según el modelo del proveedor, y en la lista de precios no se ve en absoluto.
También por eso no me fío mucho de comparar precios unitarios. Un precio unitario bajo no significa barato: un modelo cuya eficiencia en tokens para el chino es un 30 % peor sigue saliendo más caro aunque su precio unitario sea un 20 % menor.
La estructura de precios: esto es lo que sí es común en el sector
| Concepto | Práctica habitual del sector |
|---|---|
| Unidad de cobro | Siempre dólares por millón de tokens |
| Entrada y salida | Se cobran por separado; la salida suele costar de cuatro a cinco veces más |
| Caché (prompt caching) | Cuando un prefijo repetido se guarda en caché, leerlo suele costar solo una décima parte de la entrada normal |
| Procesamiento por lotes | Las tareas por lotes que no necesitan respuesta inmediata suelen tener un 50 % de descuento |
| Tokens de razonamiento | Se cuentan como salida; se pagan aunque no veas su contenido |
Tomando como ejemplo la API oficial de Anthropic a mediados de 2026, Claude Opus 5 cuesta unos cinco dólares de entrada y veinticinco de salida; Sonnet 5, dos y diez dólares; Haiku 4.5, uno y cinco dólares (por millón de tokens). Los precios cambiarán; no pongo estas cifras para que cotices con ellas, sino para que veas la estructura: la salida siempre cuesta de cuatro a cinco veces la entrada.
Esa estructura cambia directamente las decisiones de diseño. Una función que genera informes largos y otra que solo clasifica y devuelve tres palabras pueden diferir en costo en un orden de magnitud aunque la entrada sea la misma. Para recortar costos, lo primero que hay que mirar es la columna de salida.
Lo que más se subestima: el costo no es lineal
Este es el punto que creo que más merece una sección propia.
El modelo en sí no tiene memoria. En cada turno de la conversación hay que reenviar todo el historial anterior para que sepa de qué estaban hablando. Así que el «ok» que escribes en el turno veinte se factura, en realidad, como si se enviara otra vez como entrada el texto completo de los diecinueve turnos anteriores.
Dicho en términos matemáticos, el costo de una conversación larga crece de forma casi cuadrática, no lineal. En la práctica, de eso salen tres conclusiones:
- El costo de una conversación larga se concentra al final, no se reparte de forma uniforme. Un turno que en el tercero te parece barato puede costar diez veces más en el trigésimo.
- El prompt de sistema es un costo fijo que se vuelve a facturar en cada turno, no algo que se paga una vez al principio. Una configuración de rol muy detallada la pagas cada vez que dices algo.
- El mecanismo de caché existe precisamente por esto. Fijar el prefijo que no cambia y volver a leer la parte repetida a cerca de una décima parte del precio es, hoy, la táctica más eficaz para las conversaciones largas.
Para tener una cifra exacta solo hay un método
Medir con el tokenizador de ese mismo modelo.
Anthropic ofrece el endpoint count_tokens, y al llamarlo hay que indicar el identificador del modelo que de verdad vas a usar, porque cada modelo da una cifra distinta. Del lado de OpenAI, el equivalente es el paquete tiktoken.
Aquí hay una fuente de error frecuente: usar tiktoken para estimar el uso de Claude lo subestima en torno a un 15 % a 20 %, y la diferencia es mayor en el texto chino y en el código. Las tablas de corte de las dos empresas son distintas, así que nunca deberían sustituirse una por otra. He visto más de una hoja de cálculo de costos hecha así, y el resultado fue una factura real un 20 % más alta que la estimación, sin que nadie encontrara la causa.
Cuatro situaciones, cuatro formas de calcular
| Situación | Método adecuado |
|---|---|
| Hacerse una idea para decidir si se hace | Reglas prácticas: en inglés, caracteres ÷ 4; en chino, caracteres × 1 |
| Cotizar o meterlo en el presupuesto | Medir con count_tokens usando el identificador del modelo que irá a producción |
| Ya en producción, controlando costos | Revisar los campos de uso que devuelve cada llamada, sobre todo la tasa de aciertos de caché |
| Comparar proveedores | Medir la misma muestra con el tokenizador de cada proveedor; no comparar solo precios unitarios |
La diferencia entre estas cuatro no es la precisión, sino qué decisión vas a tomar con esa cifra. Cuando decides si hacer algo o no, equivocarte en un 20 % no importa; cuando decides cuánto cobrarle a un cliente, ese 20 % sale de tu margen.
Volvamos a la pregunta del principio: ¿qué es un token? Es la pieza mínima que reconoce un modelo concreto, y cada modelo reconoce cosas distintas. Si aceptas eso, tu modelo de costos estará construido sobre los cimientos correctos.
Preguntas frecuentes
¿Cuántas palabras es un token?
No hay una respuesta fija. En inglés, un token equivale aproximadamente a 4 caracteres, unas 0,75 palabras; en chino, un carácter equivale aproximadamente a 0,6 a 1,5 tokens. El rango es tan amplio porque en UTF-8 un carácter chino ocupa tres bytes, y que la palabra esté o no en el vocabulario de ese modelo puede hacer que el resultado varíe más del doble. Estas cifras solo sirven para estimar si vale la pena hacer algo, no para cotizar.
¿Por qué no hay un estándar unificado para los tokens?
Porque el vocabulario forma parte de los pesos del modelo y no se puede cambiar después del entrenamiento. Es una pieza del modelo, no una especificación externa, así que la estandarización no tiene punto de apoyo técnico: pedir a dos empresas que usen el mismo vocabulario es pedirles que usen el mismo modelo. Además, una misma empresa también cambia de tokenizador entre generaciones, de modo que un modelo de costos armado el año pasado puede ya no ser exacto este año, sin dar ningún error.
¿Puedo usar tiktoken para estimar el uso de Claude?
No es recomendable. tiktoken es el tokenizador de OpenAI, y usarlo para Claude subestima el uso en torno a un 15 % a 20 %, con diferencias mayores en el texto chino y en el código. Para tener una cifra exacta solo hay un método: medir con el tokenizador del propio modelo. En el caso de Anthropic, es el endpoint count_tokens, y al llamarlo hay que indicar el identificador del modelo que de verdad vas a usar.
¿Por qué las conversaciones largas salen cada vez más caras?
Porque el modelo no tiene memoria y en cada turno hay que reenviar todo el historial. El «ok» que escribes en el turno veinte se factura como si se enviara de nuevo como entrada el texto completo de los diecinueve turnos anteriores, así que el costo crece de forma casi cuadrática y no lineal. De ahí se deduce que el prompt de sistema es un costo fijo que se factura en cada turno, no algo que se paga una vez al principio; el prompt caching existe precisamente para reducir esa parte.
¿El modelo con el precio unitario más bajo es siempre el más económico?
No necesariamente. La eficiencia en tokens del chino depende de cuánto texto en chino haya en los datos del modelo, y el mismo pasaje en chino puede dar más del doble de tokens según el proveedor, algo que la lista de precios no muestra en absoluto. Un modelo cuya eficiencia en tokens para el chino es un 30 % peor sigue saliendo más caro aunque su precio unitario sea un 20 % menor. Para comparar precios hay que medir la misma muestra con el tokenizador de cada proveedor.
Palabras clave del artículo: token, qué es un token en IA, cuántas palabras es un token, tokenizador, BPE, costo de la IA, precios de los LLM, prompt caching, count_tokens
Fuentes: Primera publicación del original chino: 2026-09-15; última actualización del original: 2026-09-15. Los precios son los de referencia de la API oficial de Anthropic a mediados de 2026 y pueden cambiar. Las reglas prácticas de conversión solo cubren texto en inglés y en chino.
Este artículo es una adaptación del original en chino tradicional de joelin.cc. El original es la versión de referencia. Artículo original en chino
