Un mismo texto, pasándoselo a dos modelos, uno lo divide en 766 tokens y otro en 1170.
Quién lanza estos números es Tibo, responsable de OpenAI Codex.
Sus palabras exactas fueron: Un token de OpenAI no equivale a un token de otro modelo. Un precio más bajo por token individual no significa necesariamente una factura más baja.
Todos comparan precios usando "dólares por millón de tokens", como si el token fuera una unidad estándar como el gramo o el kilovatio-hora, pero no lo es.
Para que sea más fácil de entender, también contó una historia sobre pizza.
Dos pizzas idénticas.
La primera la corta en 8 porciones, cada una a 2 dólares. La segunda la corta en 16 porciones, cada una a 1.25 dólares. El segundo establecimiento anuncia un precio más bajo en su cartel, pero comer la pizza entera cuesta 20 dólares, mientras que la primera solo 16 dólares.
Añadió: A tu estómago no le importa cuántas porciones acabas de comer.
Cada porción es más barata, pero la pizza entera resulta más cara. Con métodos de corte diferentes, el precio unitario pierde su comparabilidad.
El token es la unidad mínima de facturación del modelo. Se puede entender como la "técnica de corte" que el modelo aplica al texto.
Para un mismo párrafo, con técnicas de corte diferentes, el número de piezas resultante será diferente. Se cobra por la cantidad de piezas. Cuantas más piezas, más cara será la factura.
Esta comparativa abarca inglés, textos técnicos, contenido multilingüe y numérico.
El tokenizador de GPT-5.6 Sol utilizó 766 tokens, mientras que la estimación para Claude Opus 5 fue de 1170.
Para el mismo texto, la "técnica de corte" de GPT-5.6 Sol produjo un 34.5% menos de piezas.
Y el precio de entrada de ambos modelos es de 5 dólares por millón de tokens.
El precio unitario es exactamente el mismo, el número de piezas es un tercio menor, y el coste de entrada también se reduce en un tercio.
El problema está precisamente aquí.
Si ni siquiera se puede alinear algo tan básico como "qué tamaño tiene un token" entre dos proveedores, ¿hasta qué punto sigue siendo válida esa tabla comparativa de precios de APIs que todos comparten a diario?
¿Por qué dos números para un mismo texto?
Esto se debe a que la unidad "token" simplemente no tiene una medida unificada.
Cada proveedor entrena su propio tokenizador y decide en qué tamaño fragmentar el texto.
Para palabras comunes, el tokenizador las consume enteras; para palabras raras, una sola palabra puede dividirse en tres o cuatro piezas.
El inglés es el ejemplo más claro. Palabras como "the", "and", "is" aparecen constantemente, el tokenizador les asigna un código único a cada una, una palabra es un token.
Con una palabra larga como "unbelievable", hay que dividirla en "un", "believ", "able", por lo que una palabra ocupa tres tokens.
La lógica es simple: el tokenizador se basa en estadísticas del corpus de entrenamiento. Las combinaciones que aparecen con frecuencia obtienen su propia posición. El resto se tiene que ensamblar con fragmentos.
Por lo tanto, "cuántos tokens tiene un párrafo" esencialmente pregunta "¿con qué frecuencia aparecen las cosas en este párrafo dentro del corpus de este proveedor?".
Y la prosa en inglés es, precisamente, el tipo de contenido con menor variación. Para código, JSON, cadenas largas de números, la diferencia entre lo que cortan dos proveedores será aún mayor.
Ni siquiera los modelos antiguos y nuevos de un mismo proveedor tienen cuentas compatibles
Esto no es un problema exclusivo de un solo proveedor.
La propia documentación de Anthropic es clara: el conteo de tokens es una estimación, la cantidad real de tokens de entrada utilizados al crear un mensaje puede tener pequeñas discrepancias.
Incluso da un número concreto.
Los modelos Claude 4.7 y posteriores utilizan un nuevo tokenizador. Para el mismo texto de entrada, producen aproximadamente un 30% más de tokens que los modelos iniciales, y el aumento específico depende del contenido y del tipo de carga de trabajo.
Documentación oficial de Anthropic: Los modelos Claude 4.7 y posteriores usan un nuevo tokenizador. El mismo texto produce aproximadamente un tercio más de tokens; no reutilicen los recuentos medidos en modelos antiguos.
La misma compañía, el mismo texto, y después de una generación hay un tercio más.
Por eso su recomendación oficial es: si quieres saber cuánta diferencia hay en tu carga de trabajo, procesa la misma petición con ambos modelos y compara los `input_tokens` devueltos.
No uses los números medidos en modelos antiguos para estimar costes.
Ni siquiera los recuentos entre dos generaciones de modelos de la misma casa se pueden reutilizar. Comparar directamente el "precio por millón de tokens" entre proveedores está aún más lejos de ser estandarizado.
Ambos a 5 dólares, la factura difiere en cuatro aspectos
Mismo precio unitario, misma entrada, ¿dónde está exactamente la diferencia en la factura?
Primero, la eficiencia del tokenizador, ya mencionada. El mismo texto genera un número diferente de tokens. Multiplicado por el mismo precio unitario, el dinero pagado naturalmente será diferente.
Segundo, la caché.
El precio de entrada con caché de GPT-5.6 Sol es de 0.50 dólares por millón de tokens, solo una décima parte del precio de entrada estándar. Para cargas de trabajo con muchos prefijos repetidos, este ítem puede cambiar por completo la estructura de la factura.
Tercero, la salida.
La salida de GPT-5.6 Sol es de 30 dólares por millón de tokens; la de Claude Opus 5 empieza en 25 dólares.
Y en flujos de trabajo reales de agentes inteligentes, el peso de los tokens de salida suele ser aún mayor que el de la entrada.
Es decir, ese 34.5% ahorrado al principio puede recuperarse aquí con creces.
Cuarto, el más fácil de pasar por alto, está escrito en la propia página del modelo de OpenAI. Cuando la entrada de GPT-5.6 Sol supera los 272K tokens, toda la petición se factura al doble para la entrada y al 1.5 veces para la salida.
Página oficial del modelo GPT-5.6 Sol: Entrada 5$, Entrada en caché 0.50$, Salida 30$. Esa línea pequeña de abajo especifica las reglas de recargo por superar los 272K.
No es solo la parte que excede la que se recarga, es toda la petición la que se somete a la tarifa superior.
El mismo fragmento de código, si lo consultas en un contexto de 270 mil tokens o en uno de 280 mil tokens, el precio unitario cambia de nivel.
Esta limitación proviene de la propia página de precios oficial. A mayor longitud de contexto, más rápidamente aumentan los costes de atención y memoria gráfica; las ventanas largas nunca han sido gratuitas.
La ventana de un millón está abierta, el dinero se va gastando poco a poco
Después, Tibo publicó un segundo mensaje, enseñando cómo configurar manualmente la ventana de contexto al máximo en Codex.
Abre ~/.codex/config.toml y añade tres líneas antes de cualquier título de sección:
model = "gpt-5.6-sol"
model_context_window = 1000000
model_auto_compact_token_limit = 900000
La primera línea selecciona el modelo, la segunda establece el presupuesto de contexto en 1 millón de tokens, la tercera activa la compresión automática alrededor de los 900 mil tokens, dejando un margen.
Guarda, reinicia el cliente y abre una nueva sesión para que la configuración surta efecto.
Si no quieres cambiar los valores por defecto, también puedes anularlos temporalmente solo para una sesión CLI:
codex -m gpt-5.6-sol
-c model_context_window=1000000
-c model_auto_compact_token_limit=900000
Estas dos claves se pueden consultar en la referencia de configuración oficial de Codex y su función coincide con lo que él escribió.
`model_context_window`, el número de tokens de la ventana de contexto disponible para el modelo actual.
`model_auto_compact_token_limit`, el umbral para activar la compresión automática del historial.
Pero la documentación solo define el significado de las claves, no lista "1 millón / 900 mil" como valores recomendados universales.
El propio Tibo añadió al final de su publicación: Los valores por defecto están cuidadosamente ajustados.
Entonces, ¿por qué tanta gente quiere cambiarlos manualmente?
Un informe de pruebas de usuario en GitHub explica la razón.
Este informe de pruebas en el repositorio openai/codex: El directorio de Codex limita la ventana a 372K, efectivos 353.4K, mientras que las especificaciones del modelo indican 1.05M
En una versión específica del cliente Codex y con una cuenta ChatGPT Pro, el directorio de modelos mostraba para gpt-5.6-sol una ventana de 372K, aplicando un 95%, quedaban 353.4K utilizables. Pero la página oficial del modelo indica 1.05M.
Compraste una ventana de un millón, pero al usarla solo te queda un tercio.
Este informe tiene limitaciones claras de versión y tipo de cuenta, no puede tomarse como la situación actual de todos los usuarios. Además, la publicación de configuración de Tibo es más reciente.
Hay que aclarar algo: configurar a 1 millón no genera inmediatamente un coste por 1 millón de tokens. Lo que se factura siempre es el volumen de procesamiento real.
Sin embargo, llevar el umbral de compresión hasta los 900 mil significa que una sesión larga arrastrará un historial cada vez más extenso, y cada nueva petición tendrá que procesar de nuevo ese historial.
Cuanto mayor sea la ventana y más tarde se comprima, más probable es que la petición alcance ese umbral de 272K mencionado antes.
En conversaciones cortas, las diferencias del tokenizador son minúsculas. Cuando una sesión se extiende a cientos de miles de tokens, arrastrando y reprocesando el historial repetidamente, multiplicado además por una tarifa superior, los decimales de la diferencia se convierten en números enteros.
El dinero no se gasta de golpe, sino que aumenta ronda tras ronda.
La próxima unidad es "por resultado exitoso"
En la publicación de Tibo había otra frase que pasó desapercibida entre los números: Lo que realmente importa es el coste por resultado exitoso (price per successful outcome).
Y también dio el método. Los benchmarks pueden ser un punto de partida, pero para saber realmente si es caro, hay que ejecutar tu propio trabajo.
Esta frase cambia el punto de referencia de la comparación de precios. De "cuánto cuesta un millón de tokens" a "cuánto cuesta en total completar la misma tarea".
Para saber cuál de los dos proveedores es realmente más barato para ti, pruébalo tú mismo.
Toma el mismo texto original, la misma proporción de idiomas, las mismas definiciones de herramientas; llama a las interfaces oficiales de conteo de cada proveedor para obtener el número real de tokens; luego incluye aciertos de caché, longitud de salida, longitud de inferencia y recargos por contexto largo; finalmente, compara cuál completa el trabajo con un coste menor.
La eficiencia del tokenizador es solo el primer eslabón de esta cadena. Un modelo que ahorra en tokenización, si es verboso en el razonamiento o requiere muchos reintentos, puede perfectamente revertir la factura y superar al otro.
En el futuro, la pregunta no debería ser cuánto cuesta un millón de tokens, sino cuánto cuesta arreglar este bug.
Referencias:
https://x.com/thsottiaux/status/2089082893804896524?s=20
https://x.com/thsottiaux/status/2088866513008873560?s=20 https://github.com/openai/codex/issues/31860
Este artículo proviene del WeChat Official Account "新智元", autor: ASI启示录
