Consumo de tokens en LLM: por qué una respuesta de 4 tokens factura 217

Hazle a GPT-5.6 una pregunta de matemáticas de una línea y el 88% del cargo de salida es razonamiento que nunca vas a ver: 10 tokens visibles, 81 facturados. Y GPT-5.6 es el caso suave. La misma pregunta facturó 217 tokens de completion para una respuesta de 4 tokens en GLM 5.2, y 1.104 para la respuesta idéntica en Qwen3.7-max. No es una anomalía: los modelos de razonamiento facturan así por diseño, y esa es solo la primera de varias clases de tokens que la mayoría de los dashboards de costes nunca desglosan. Este post disecciona un objeto usage real, clase por clase, con los números medidos.

TL;DR

• La configuración por defecto de GPT-5.6 facturó 81 tokens para una respuesta de 10 tokens, un 88% de razonamiento; GLM 5.2 llegó al 98% y Qwen3.7-max al 99,3%.
• Claude Sonnet 5 facturó 114 tokens de thinking en una respuesta de 5 tokens sin enviar ningún parámetro de thinking.
• Cinco familias respondieron mal sin thinking (399, 400, 427, 466, 467); solo GPT-5.6 acertó sin él, y todas las ejecuciones con razonamiento dieron 401.
• Una escritura de caché de Claude de 1.181 tokens y su posterior lectura costaron 0,01246 $ y 0,00566 $, coincidiendo exactamente con las tarifas de lista.

Con qué hicimos las pruebas

Cada medición de este post usa el mismo prompt de un solo turno, enviado a cada modelo con su configuración por defecto salvo que una fila indique lo contrario:

How many positive integers n <= 1000 are divisible by 3 or 5
but not by 15? Reply with just the number, nothing else.

La respuesta correcta es 401 (333 múltiplos de 3, más 200 múltiplos de 5, menos 66 contados dos veces, da 467; quitas los 66 múltiplos de 15 y quedan 401). La elegimos a propósito: la respuesta visible es diminuta y fija en 3-4 tokens en cualquier tokenizador, hay exactamente una respuesta correcta, así que “¿mereció la pena pensar?” se puede comprobar, y es justo lo bastante difícil como para que los modelos quieran pensar, que es precisamente el comportamiento bajo estudio.

Las cinco clases de tokens de tu factura

Una completion moderna factura hasta cinco clases distintas de tokens, a cuatro tarifas diferentes. Un único número plano de “tokens usados” oculta todo esto.

Los nombres de campo de arriba son la forma compatible con OpenAI. Claude maneja las mismas cinco clases con sus propios nombres: input_tokens y output_tokens, con el thinking reportado en output_tokens_details.thinking_tokens y facturado como output, y la escritura de caché a su vez dividida por TTL en un objeto cache_creation (ephemeral_5m_input_tokens a 1.25x, ephemeral_1h_input_tokens a 2x). Misma anatomía, etiquetas distintas: ese problema de parseo vuelve a aparecer en una sección posterior.

Las cinco clases y sus multiplicadores de precio, etiquetadas con los nombres de campo compatibles con OpenAI y con Anthropic. El 88% es la proporción de reasoning medida de GPT-5.6 en el ejemplo de arriba.

Este es el objeto real detrás del titular, GPT-5.6 en su configuración por defecto respondiendo a la pregunta de prueba:

{
  "prompt_tokens": 38,
  "completion_tokens": 81,
  "total_tokens": 119,
  "prompt_tokens_details": { "cached_tokens": 0, "cache_write_tokens": 0 },
  "completion_tokens_details": { "reasoning_tokens": 71 },
  "cost": 0.000524
}

Aquí es donde vive la aritmética de la facturación, y vale la pena hacerla una vez de forma explícita. La respuesta que recibiste es completion_tokens menos reasoning_tokens: 81 − 71 = 10 tokens, la palabra “401” y su formato. Los otros 71 tokens son chain-of-thought facturados a la tarifa completa de output, el 88% del cargo de output, y en GPT-5.6 no puedes leer ni uno solo de ellos. Toda cifra de “respuesta visible” en este post se calcula de la misma manera. La proporción solo se vuelve más pronunciada en otros casos: GLM 5.2 respondió la misma pregunta con 217 completion tokens para una respuesta de 4 tokens, así que un modelo de costes que lea completion_tokens como “lo que dijo el modelo” se equivoca por 8x aquí y por 54x allá.

El razonamiento es el presupuesto, y se puede controlar

La misma pregunta de una línea en cada ajuste de razonamiento que aceptan las tres familias configurables, un solo gateway, 2026-07-13/14 (las filas van de menos a más razonamiento dentro de cada familia; los valores por defecto de los buques insignia de las familias restantes están en la siguiente sección):

De esa tabla hay que leer cuatro cosas sin engañarse:

• La palanca es grande donde funciona. reasoning_effort: none respondió correctamente por $0.000062, 8.5x menos que el default de luna, y en tareas más duras hemos medido 20x en GLM 5.2. La elección de tier es parte de la misma palanca: el buque insignia de GPT-5.6 respondió esta pregunta con cero razonamiento por defecto (siguiente sección), así que un modelo más grande que no necesita pensar puede salir más barato que uno más pequeño que sí lo hace.
• Y casi inerte donde no. Cuánto gira el dial es un rasgo de cada familia: monótono con una variación de costo de 5x en Sonnet 5 (84 a 249), leve y desordenado en GPT-5.6, casi inerte en Qwen3.7-max (low igual gastó 974 tokens de razonamiento frente a los 1.096 del default), muerto en DeepSeek V4 Pro (267 frente a 269).
• Las etiquetas no son monótonas y los defaults no son deterministas. Aquí el high de GPT-5.6 gastó menos tokens que su medium; el low de GLM gastó más que su high en nuestro post anterior; Sonnet 5 pensó 114 tokens en una petición que no envió ningún parámetro de thinking; y la misma petición default de GLM gastó 213 tokens de razonamiento en una corrida y 1.312 en otra, seis veces más. Mide el efecto real del dial en tu carga de trabajo; no lo deduzcas de la etiqueta.
• Barato-y-mal es la falla que se repite. Las dos familias que respondieron sin pensar aquí respondieron mal (GLM 399, Sonnet 5 467); el recuento completo de las cinco familias está en la siguiente sección. El razonamiento es un presupuesto de corrección, y si recortarlo compensa depende de la tarea, no del modelo.

La regla práctica: trata reasoning_tokens como una línea de costo de primera clase. Se factura a la tarifa de output, suele ser mucho mayor que la respuesta visible, y responde a parámetros cuyo efecto real tienes que medir. En GPT-5.6, ten en cuenta que las reglas de precios también cambiaron; la guía de costos de GPT-5.6 cubre el sobreprecio de escritura y el requisito de cache-key.

¿Puedes leer de verdad lo que pagaste?

“Separado de la respuesta” no siempre significa oculto, y vale la pena ser precisos con esa diferencia. Revisamos los cuerpos de las respuestas, no solo el usage:

• GLM 5.2, DeepSeek, Qwen3.7-max y MiniMax devuelven el texto completo del razonamiento en un campo reasoning_content junto a la respuesta (3.987, 1.604, 2.509 y 581 caracteres en este caso). Un desarrollador puede leer cada token facturado; los usuarios finales solo lo ven si lo renderizas, y la mayoría de las aplicaciones no lo hacen.
• GPT-5.6 retiene la cadena de pensamiento en bruto; lo máximo que obtienes es un resumen. La respuesta puede incluir un reasoning.summary escrito por el modelo (359 caracteres en este caso), pero los 91 tokens facturados son el texto en bruto oculto, no el resumen. Lo más cercano a ese texto es reasoning.encrypted_content: un blob cifrado que puedes devolver para mantener continuidad entre turnos, pero que nunca puedes descifrar. Los tokens que pagaste están en tu propio cuerpo de respuesta, ilegibles.
• Con Claude depende de cómo preguntes. Nuestra llamada a Sonnet 5 con adaptive-thinking devolvió un bloque thinking con texto vacío mientras que thinking_tokens facturó 114: prueba de que pensó, pero nada que leer. Fable 5 se comportó igual en su modo always-on por defecto (59 facturados, bloque vacío). En cambio, la misma llamada a Sonnet 5 con un presupuesto de reasoning explícito devolvió el texto real del pensamiento (73 tokens facturados, con texto). Cómo preguntas decide qué puedes ver.

Así que la factura es universal, la visibilidad no: todas las familias cobran razonamiento a tarifa de output, y poder auditar el texto que compraste va desde “completo” hasta “solo resumen” o “un bloque vacío firmado”.

Cuando el texto sí regresa, puedes calificarlo de forma mecánica. Nuestra pregunta tiene cinco resultados intermedios fijos (333, 200, 66, 467, 401), y todos los textos de razonamiento devueltos los contenían: GLM 5.2, DeepSeek V4 Pro, Qwen3.7-max, Kimi K2.7 Code y MiniMax M3 entregaron cada uno una derivación completa, mientras que las variantes de bajo esfuerzo saltaron un paso cada una. Para quien necesita el proceso y no solo la respuesta, esa es la división: con reasoning_content puedes verificar lo que pagaste; con un resumen o un bloque vacío lo aceptas por fe. Invisible Tokens, Visible Bills formaliza esa brecha de rendición de cuentas, y PALACE estima el razonamiento oculto desde fuera.

La misma pregunta en el mejor modelo de cada familia

La tabla de steering usaba niveles concretos para mostrar los ajustes. Aquí está el buque insignia más reciente de cada familia con la misma pregunta y la configuración por defecto:

Tokens de salida facturados por buque insignia para la misma pregunta (naranja rayado = proporción de razonamiento; verde = la respuesta visible). El asterisco en MiniMax: su uso no incluye recuento de razonamiento, por lo que la proporción se reconstruye por sustracción, verificada contra el texto de razonamiento que devuelve. La marca de verificación en GPT-5.6 sol señala la única ejecución correcta con cero razonamiento; la cruz en Gemini 3.5 Flash señala la única respuesta incorrecta de un buque insignia (466).

Cada estilo de reporte en un solo gráfico:

• Siete de los ocho buques insignia respondieron correctamente, a precios muy dispares para el mismo 401. Qwen3.7-max gastó 1,096 tokens de reasoning, 22 segundos y $0.0084; el buque insignia de GPT-5.6 gastó cero tokens de reasoning y $0.00031. Una diferencia de 27x en coste y de 7x en latencia para una misma respuesta correcta: el presupuesto de reasoning hecho visible.
• MiniMax devuelve su texto de reasoning pero no el recuento. 260 tokens de completion para una respuesta visible de 3 tokens: la respuesta lleva la derivación completa en reasoning_content, pero completion_tokens_details no tiene línea de reasoning. Cuando falta el recuento, reconstrúyelo por resta: completion menos tokens visibles es tu recuento de salida oculta.
• Gemini 3.5 Flash es el caso atípico: el único buque insignia que respondió mal (466), con 3 tokens de completion y sin recuento de reasoning por ninguna parte. Su hermano 2.5 Flash llegó a gastar 12.5 segundos produciendo un 401 de 3 tokens sin que la factura dijera por qué, y una repetición respondió 427.
• Los niveles más pequeños y el thinking desactivado es donde viven las respuestas incorrectas. GLM con thinking apagado dijo 399; Sonnet 5 desactivado dijo 467; el qwen3-max más antiguo no pensó en absoluto (3 tokens) y dijo 400; Kimi K2.5, que no tiene canal de reasoning, razonó en voz alta durante 144 tokens visibles facturados, derivó 401 dentro de su propia prosa y luego concluyó 400. Cinco familias, cinco respuestas incorrectas distintas: 399, 400, 427, 466, 467; solo GPT-5.6 acertó sin reasoning.

Tokens de caché: dos direcciones, 12x de diferencia

El prompt caching divide el input en dos clases más, y la brecha de precio entre ellas es justo el motivo de la división: las escrituras se facturan a 1.25x la tarifa de input en Claude (2x con el TTL de 1 hora), y las lecturas a 0.1x. Un par de llamadas medidas a Opus 4.8, con un system prompt cacheado de 1.181 tokens, costaron $0.01246 (escritura) y luego $0.00566 (lectura); ambas cuadran con los precios de lista hasta el sexto decimal, y el cargo del lado del input baja unas 11x de una llamada a la siguiente. Lo que importa aquí es la contabilidad: si metes cache_creation_input_tokens y cache_read_input_tokens en el mismo saco de “input tokens”, no puedes verificar el descuento ni darte cuenta cuando deja de aplicarse sin avisar. Y deja de aplicarse más a menudo de lo que sugiere la documentación: nuestras mediciones de caching encontraron umbrales efectivos entre 1.4 y 2.4x por encima de los mínimos documentados, y la guía de prompt caching cubre a fondo la mecánica de cada proveedor.

Por qué tu estimación local nunca cuadra con la factura

Un patrón habitual es estimar el coste en el cliente con una librería de tokenización y reconciliar después. Los números no cuadran por tres razones:

• Cada proveedor usa un tokenizador distinto. Contar texto destinado a Claude con un tokenizador de OpenAI es medir con la regla equivocada; la misma cadena se tokeniza distinto en cada familia.
• Facturas más que tu propio mensaje. Los system prompts y los esquemas de tools son input tokens en cada request que los lleva, y es fácil dejarlos fuera de una estimación local.
• El reasoning es impredecible hasta la respuesta. Ningún conteo del lado del cliente puede predecir cuántos thinking tokens gastará un modelo; solo lo sabes por el usage que devuelve.

El objeto usage que devuelve la respuesta es el propio registro de facturación del upstream, así que el contador más barato y preciso es dejar de estimar y leerlo. El problema es que cada proveedor le da otra forma: los tokens cacheados aparecen como cached_tokens, prompt_cache_hit_tokens, total_cached_tokens o cache_read_input_tokens según la familia.

Los objetos de detalle tampoco tienen un esquema fijo. La referencia de OpenAI documenta cuatro campos del lado del completion: reasoning_tokens, audio_tokens y el par de Predicted Outputs accepted_prediction_tokens / rejected_prediction_tokens; los rejected prediction tokens nunca aparecen en el output pero se facturan igual como completion tokens. Del lado del prompt, la misma estructura añade text_tokens, audio_tokens e image_tokens junto a cached_tokens; GPT-5.6 añade cache_write_tokens, y hemos visto video_tokens en producción. Los proveedores lo extienden a su antojo: Kimi K2.7 devolvió un completion_tokens_details.text_tokens no documentado, y Gemini cuenta los tokens de thinking y de uso de tools por separado bajo sus propios nombres. Parsea a la defensiva: da por hecho que habrá campos de detalle desconocidos, y nunca asumas que un campo ausente significa cero.

Aquí es donde un gateway justifica su lugar: Synthorai normaliza todo esto en un solo objeto, con reasoning_tokens y las dos direcciones de caché rellenas en OpenAI, Anthropic, Gemini y las familias open-weight, de modo que un único parser cubre todos los modelos a los que enrutas.

De ver a detener

Leer el registro es la mitad del trabajo; la otra mitad es hacer que los sobrecostos sean imposibles, no solo visibles. Los dashboards de fin de mes reportan la sorpresa cuando el dinero ya se gastó, y un agente atrapado en un bucle de reintentos no lee dashboards. En el gateway, cada key lleva una quota con used_quota registrado y un tope de RPM, aplicados en el momento de la petición: una key que agota su presupuesto recibe un error explícito en la siguiente petición, no una factura más grande tres semanas después. La atribución por petición (qué key, qué modelo, BYOK o facturación de plataforma) vuelve en el mismo envelope de respuesta, así que el costo por feature es un group-by, no un proyecto de reconstrucción.

El orden de operaciones que se deriva de las mediciones: lee reasoning_tokens y los campos de cache antes de optimizar nada, ajusta el nivel de reasoning por tarea y pon una quota estricta a toda key cuyo modo de fallo sea un bucle. Para ver cuánto cuesta una mezcla concreta de modelos y clases de tokens a tu volumen, el cost optimizer lo calcula con las mismas tarifas por token usadas arriba.

← Volver al blog