Tokens en español: por qué cuestan un 26 % más que en inglés
DominicodeHace unas semanas revisé el consumo de API de un agente de soporte. Sonnet, 25.000 conversaciones al mes, prompts cortos, nada exótico. El equipo había estimado el coste a mano antes de lanzar y la factura llegó cerca de un 26 % por encima.
Estuvimos media hora buscando la llamada duplicada. No había llamada duplicada.
El problema eran los tokens en español. No porque un token en español cueste más —el precio por token es idéntico—, sino porque necesitas más tokens para decir exactamente lo mismo.
Y la parte incómoda es por qué necesitas más. La respuesta cómoda es "el español es más largo". Esa respuesta no llega a explicar ni la mitad de lo que pasa.
Lo medí.
La respuesta corta: el español consume un 26,0 % más de tokens que el inglés para transmitir el mismo mensaje, medido sobre cinco pares de textos paralelos con o200k_base (GPT-4o / GPT-5). Unos 10 puntos vienen de que el español usa más palabras; el resto, de que el tokenizador parte cada palabra española en más trozos. El precio por token es idéntico en los dos idiomas: lo que cambia es cuántos necesitas.
Medí los tokens en español de cinco textos reales
Cogí cinco textos del tipo que de verdad mandas a un modelo en producción y escribí la versión española y la inglesa de cada uno, con el mismo significado y el mismo registro. Nada de traducciones infladas: pares paralelos.
Luego los pasé en local por o200k_base, el tokenizador de la familia GPT-4o / GPT-5.
Tabla 1 — Sobrecoste de tokens del español frente al inglés en cinco pares de textos paralelos, medidos con o200k_base. Medición propia de Dominicode, julio de 2026.
| Tipo de texto | Tokens EN | Tokens ES | Sobrecoste ES vs EN |
|---|---|---|---|
| System prompt de agente | 74 | 86 | +16,2 % |
| Documentación técnica | 62 | 85 | +37,1 % |
| Mensaje de un usuario (soporte) | 65 | 73 | +12,3 % |
| Fragmento de base de conocimiento (RAG) | 67 | 93 | +38,8 % |
| Prompt de tarea de desarrollo | 55 | 70 | +27,3 % |
| Total | 323 | 407 | +26,0 % |
El español consume un 26,0 % más de tokens que el inglés para decir exactamente lo mismo. No es una anécdota: es un multiplicador que se aplica a cada llamada de tu aplicación, todos los días.
Y fíjate en la dispersión, porque ahí está la parte accionable: el mensaje de un usuario se hincha un 12,3 %; un fragmento de base de conocimiento, un 38,8 %. Tres veces más de castigo según el tipo de texto.
No es que hables más. Es que te parten peor.
Descompongo ese +26 % en sus dos factores:
- Palabras: 290 en inglés → 319 en español = +10,0 %
- Tokens por palabra: 1,114 en inglés → 1,276 en español = +14,5 %. O sin decimales, por si se lee mejor: 111 tokens por cada 100 palabras inglesas frente a 128 por cada 100 españolas.
Y los dos factores se multiplican, no se suman: 1,10 × 1,145 = 1,26. Ahí está el +26 % completo.
Traducido: de los 26 puntos de sobrecoste, solo unos 10 vienen de que el español use más palabras. El resto viene de que cada palabra española se rompe en más trozos.
Esto no es una queja sobre el idioma, es ingeniería. El vocabulario de un tokenizador BPE se construye por estadística sobre un corpus mayoritariamente inglés, así que las secuencias frecuentes en inglés se quedan con las plazas buenas: una palabra inglesa común entra entera en un token y su equivalente española entra a trozos. Súmale que el español conjuga y deriva mucho más, y cada variante es una cadena distinta que el tokenizador no tiene memorizada.
Eso explica también la dispersión de la tabla. Los dos que menos se inflan son el mensaje de usuario (+12,3 %) y el system prompt (+16,2 %): frases cortas, vocabulario común y terminología técnica que el tokenizador reconoce igual en los dos idiomas. Los que más se inflan son la documentación (+37,1 %) y los fragmentos de RAG (+38,8 %), que llevan prosa española de verdad, con subordinadas y nominalizaciones largas de las de "-ción" y "-miento". La regla práctica: cuanta más prosa explicativa, más sobrecoste.
El sobrecoste del español baja de +44 % a +26 %
Pasé los mismos cinco pares por cl100k_base, el tokenizador antiguo de GPT-3.5 y GPT-4: 323 tokens en inglés y 465 en español. Un +44,0 %.
De +44 % a +26 % en una generación de tokenizador. El vocabulario de o200k_base es más grande y menos anglocéntrico. Pero son dos medidas, no una ley: bajó una vez, no des por hecho que baje siempre. Lo que sí puedes dar por hecho es que si en 2023 tomaste una decisión de arquitectura basada en lo que costaba el español, ese número está caduco.
Metodología y límites de la medición
Medición hecha por Bezael Pérez (Dominicode) en julio de 2026: cinco pares de textos paralelos español/inglés —system prompt de agente, documentación técnica, mensaje de soporte, fragmento de RAG y prompt de tarea de desarrollo—, tokenizados en local con o200k_base y cl100k_base. Totales: 323 tokens en inglés frente a 407 en español con o200k_base, y 465 con cl100k_base.
Cada proveedor usa su propio tokenizador. Anthropic no publica el suyo: la única fuente fiable para contar tokens de Claude es su endpoint count_tokens — y Anthropic la llama estimación, no medida exacta.
Así que los porcentajes de arriba son de la familia OpenAI (o200k_base), no de Claude. La dirección del efecto es la misma en todos los modelos comerciales, pero el número exacto varía según proveedor y tipo de texto. Anthropic lo admite en su propia página de precios: un token son "aproximadamente 4 caracteres o 0,75 palabras en inglés", y el recuento exacto "varía según el idioma".
Con Claude hay además un detalle que cambia los números absolutos, avisado en esa misma página: los modelos de la generación 4.7 en adelante —Opus 5 y Sonnet 5 incluidos— usan un tokenizador nuevo que produce alrededor de un 30 % más de tokens que los anteriores para el mismo texto. Se nota en sus estimaciones: el millón de tokens de Opus 5 son ~555.000 palabras en inglés, y en Opus 4.6 eran ~750.000.
Así que no copies la cifra de este post. Mídela. Es gratis y te cuento cómo abajo.
Dónde se paga el sobrecoste de tokens en español: factura, contexto y latencia
1. La factura: cuánto cuesta el sobrecoste al mes
Tabla 2 — Precios oficiales de la API de Anthropic por millón de tokens, en USD (consultados el 30 de julio de 2026).
| Modelo | Entrada ($/M tokens) | Salida ($/M tokens) |
|---|---|---|
| Claude Opus 5 | $5 | $25 |
| Claude Sonnet 5 | $3 | $15 |
| Claude Haiku 4.5 | $1 | $5 |
Ojo a la fecha con Sonnet 5: los $3 / $15 son la tarifa estándar que entra el 1 de septiembre de 2026; hasta el 31 de agosto rige el lanzamiento de $2 / $10, un tercio más barato. Calculo con la estándar porque es la que pagarás cuando esto lleve unos meses en producción.
Vuelvo al agente del principio: Sonnet 5 a tarifa estándar, 25.000 conversaciones al mes, 1.500 tokens de entrada y 300 de salida por conversación. El modelo responde en el idioma en el que le escriben, así que cuando el usuario escribe en español la salida también se hincha un 26 %.
- En inglés: entrada 37,5 M × $3 = $112,50 · salida 7,5 M × $15 = $112,50 → $225/mes
- En español (+26 % en entrada y en salida): entrada 47,25 M × $3 = $141,75 · salida 9,45 M × $15 = $141,75 → $283,50/mes
Diferencia: $58,50 al mes. $702 al año. Por escribir en el idioma de tus usuarios. El +26 % va aquí como aproximación, por lo que ya expliqué: el tokenizador de Claude no es público.
A esta escala es asumible. Multiplícalo por diez y ya es una decisión de producto.
2. La ventana de contexto
Opus 5 y Sonnet 5 tienen 1 millón de tokens de ventana de contexto. Y ojo con la cuenta, porque aquí el 26 % se da la vuelta: si cada texto te cuesta un 26 % más de tokens, en ese millón te cabe un 21 % menos de contenido (1 ÷ 1,26 = 0,79). Con fragmentos de base de conocimiento, que se hinchan un 38,8 %, la pérdida sube al 28 %.
En un RAG eso no es una curiosidad académica: es recall —y si todavía estás decidiendo entre RAG y fine-tuning, el idioma entra en la ecuación de coste. Con el mismo presupuesto de contexto inyectas menos fragmentos por consulta.
Menos evidencia recuperada para la misma pregunta es exactamente la situación en la que un modelo empieza a rellenar huecos, que es el mecanismo que expliqué en por qué la IA se inventa cosas.
Y antes de que la solución sea "pues meto más": llenar la ventana tampoco es gratis en calidad. Va de eso la regla del 60 % en gestión de contexto.
3. La latencia
Un modelo emite los tokens de salida de uno en uno, a un ritmo más o menos fijo. Si tu respuesta en español necesita un 26 % más de tokens, tarda un 26 % más en terminar.
Ojo con dónde lo notas, porque es fácil confundirse: si haces streaming, el primer token llega igual de rápido —eso lo manda el prefill de la entrada, no la longitud de la salida—, y lo que se alarga es la respuesta completa. Sin streaming, el usuario se come el 26 % entero mirando el cursor parpadear. Y si detrás hay un agente que encadena cinco llamadas, ese 26 % se acumula en cada paso.
Qué hacer con esto (sin escribir peor español)
Mide, no estimes. El endpoint count_tokens de Anthropic es gratis. Solo lo limitan las peticiones por minuto de tu tier: 2.000 en Start, 4.000 en Build, 8.000 en Scale.
import Anthropic from "@anthropic-ai/sdk"
const client = new Anthropic()
const systemEs = "Eres un agente de soporte…" // tu system prompt real
const systemEn = "You are a support agent…" // el mismo, en inglés
async function contar(system: string) {
const res = await client.messages.countTokens({
model: "claude-opus-5",
system,
messages: [{ role: "user", content: "ping" }],
})
return res.input_tokens
}
console.log(await contar(systemEs), await contar(systemEn))
El "ping" está ahí porque messages es obligatorio; al ser idéntico en las dos llamadas, la diferencia sale limpia. Quince minutos y dejas de discutir con estimaciones.
El system prompt en inglés, el contenido del usuario en español. El system prompt se repite en cada llamada y tu usuario nunca lo lee. Traducirlo al inglés te quita tokens de encima en todas.
Pero pon el número antes de comprar la idea. Mi system prompt de prueba baja de 86 a 74 tokens: por 25.000 conversaciones al mes son $0,90 con Sonnet 5. Con un system prompt realista de 2.000 tokens, unos $21 al mes. Con caché, una décima parte de eso. Es una optimización real, pero es de un dígito o dos de dólares — no la vendas como el arreglo.
Y no es gratis. Si lo traduces, fija el idioma de salida de forma explícita —"Always respond in Spanish, regardless of the language of these instructions"— en vez de dejar que el modelo lo infiera del mensaje. Si dentro tienes few-shots, cuidado: los ejemplos arrastran el idioma de salida tanto como la instrucción. Y deja en español cualquier texto que el modelo tenga que devolver literal —mensajes fijos, disclaimers, nombres de producto—, o te lo traducirá a su manera. Después de tocar el system prompt, vuelve a pasar tus evals.
Prompt caching. Esta es la palanca de verdad. Si el system prompt y el contexto fijo se repiten entre llamadas, cachéalos: una lectura de caché cuesta 0,1× el precio de entrada, un 90 % menos. Ataca justo la parte repetida, la que paga el 26 % una y otra vez sin cambiar una coma, y por eso rinde un orden de magnitud más que traducir nada. Lo desarrollé entero en prompt caching con la API de Claude. Orden de prioridades: primero cachea, después piensa en el idioma.
Vigila lo que inyectas en cada consulta. Los fragmentos de base de conocimiento son lo que más se hincha (+38,8 %) y van en cada petición; la documentación técnica le sigue (+37,1 %). Si trabajas con specs, esto te toca de lleno: una spec es documentación técnica que entra en el contexto en cada iteración. Una razón más para escribirlas cortas y estructuradas, como insisto en el libro de Spec-Driven Development.
Lo que NO debes hacer: escribir peor español para ahorrar tokens. Nada de abreviar, quitar tildes o telegrafiar los prompts como un SMS de 2004. El ahorro es de céntimos, y transliterar o mutilar el texto es justo lo contrario de lo que recomiendan los propios proveedores, que piden enviarlo en su escritura nativa. Si necesitas gastar menos: cachea, elige un modelo más pequeño para la tarea, reduce el número de llamadas o mueve la carga a un modelo local, donde el sobrecoste del español deja de facturarse por token y pasa a ser tiempo de GPU.
Cómo medir tus tokens en español hoy mismo
Abre tu system prompt de producción. El real, el que ya está desplegado.
- Copia tu system prompt tal cual está desplegado.
- Pásalo por
count_tokensy anotainput_tokens. - Traduce ese mismo prompt al inglés sin recortar contenido.
- Pásalo otra vez y anota el segundo número.
- Resta, divide por el valor en inglés y multiplica por tus llamadas mensuales y por el precio de entrada de tu modelo.
En quince minutos tienes tu número, no el mío.
La mayoría descubre que su problema no era el idioma: era que no estaban cacheando nada. Ese diagnóstico solo aparece cuando mides.
Si quieres el flujo completo para llevar una idea a producto con Claude Code —y salir con instrumentación, no con intuiciones—, es lo que trabajo en Construye con IA: de la idea al producto con Claude Code. Y si prefieres verlo sobre proyectos reales, con gente peleándose con las mismas facturas, eso pasa cada semana en Dominicode Labs.
Preguntas frecuentes sobre los tokens en español
¿Cuánto más cuesta escribir prompts en español que en inglés?
En mi medición con o200k_base sobre cinco pares de textos paralelos, un 26,0 % más de tokens para decir lo mismo: 323 en inglés frente a 407 en español.
El rango va de +12,3 % (mensaje de un usuario) a +38,8 % (fragmento de RAG): el tipo de texto importa tanto como el idioma.
¿Es porque el español es más largo?
Solo en parte, y los dos factores se multiplican, no se suman: un +10,0 % de palabras (290 → 319) por un +14,5 % de tokens por palabra (1,114 → 1,276) sale 1,10 × 1,145 = 1,26. El factor grande es el segundo.
La causa es el tokenizador, no la verborrea: su vocabulario se entrenó sobre un corpus mayoritariamente inglés, y lo que no está bien representado ahí se fragmenta.
¿Cuántos tokens es una palabra en español?
1,276 tokens por palabra de media en mi medición con o200k_base, frente a 1,114 en inglés. O sin decimales: unos 128 tokens por cada 100 palabras españolas y 111 por cada 100 inglesas.
Es una media sobre texto real de producción: sube en prosa explicativa y baja en textos cargados de terminología inglesa, que el tokenizador ya conoce.
¿Qué tipo de texto se encarece más al escribirlo en español?
Los fragmentos de base de conocimiento para RAG (+38,8 %) y la documentación técnica (+37,1 %). El que menos, los mensajes que escriben los propios usuarios (+12,3 %).
La diferencia está en la densidad de jerga inglesa: cuanto más técnico es el texto, más tokens comparte el español con el inglés y menos se infla.
¿Cómo cuento los tokens en español que consume Claude?
Con el endpoint count_tokens de la API de Anthropic, disponible en el SDK oficial como client.messages.countTokens(). Es gratis y solo lo limitan las peticiones por minuto de tu tier: 2.000 en Start, 4.000 en Build, 8.000 en Scale.
Es además la única fuente oficial, porque Anthropic no publica su tokenizador. Ni siquiera ella es exacta: Anthropic advierte de que el conteo es una estimación y puede desviarse ligeramente del consumo real. Cualquier cifra calculada con o200k_base o cl100k_base es una aproximación de otro proveedor.
¿Debo escribir mis prompts en inglés para ahorrar dinero?
El system prompt puedes traducirlo: se repite en cada llamada, nadie lo lee y los modelos responden en español perfectamente aunque las instrucciones estén en inglés. Pero mide el ahorro antes de moverlo, porque suele ser de un dígito o dos de dólares al mes, y desaparece casi entero si ya estás cacheando.
El contenido del usuario, no lo toques. Y no traduzcas tu base de conocimiento al inglés solo por coste sin medir antes qué le pasa a la calidad de las respuestas. Antes de eso activa prompt caching: ahorra un 90 % en la parte repetida y no cambia nada de tu producto.
¿Este sobrecoste va a desaparecer?
Se está reduciendo: los mismos cinco pares dan +44,0 % con cl100k_base (GPT-3.5 / GPT-4) y +26,0 % con o200k_base (GPT-4o / GPT-5), porque los vocabularios nuevos son más grandes y menos anglocéntricos.
Pero no lo tomes como una tendencia garantizada. Son dos medidas, no una ley, y hay contraejemplos: los modelos Claude de la generación 4.7 en adelante usan un tokenizador nuevo que produce alrededor de un 30 % más de tokens que los anteriores para el mismo texto. Vuelve a medir cada vez que cambies de modelo.
¿Afecta el idioma a la ventana de contexto?
Sí, y es el coste que menos se vigila. Cuidado con la cuenta, porque el porcentaje se invierte: en 1 millón de tokens —el que traen Opus 5 y Sonnet 5— cabe un 21 % menos de contenido si está en español, porque un +26 % de tokens por texto equivale a 1 ÷ 1,26 de contenido por ventana. Con fragmentos de RAG (+38,8 %) la pérdida es del 28 %.
En un RAG eso significa menos fragmentos recuperados por consulta con el mismo presupuesto de contexto.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.