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

Hazle a GPT-5.6 una pregunta matemática de una línea y el 88% del coste de salida corresponderá a razonamiento que nunca verás: 10 tokens visibles, 81 facturados. Y GPT-5.6 es el caso moderado. Para la misma pregunta, GLM 5.2 facturó 217 tokens de completion por una respuesta de 4 tokens; Qwen3.7-max facturó 1,104 por esa misma respuesta. No es una anomalía. Los modelos de razonamiento facturan así por diseño, y esta es solo la primera de varias clases de tokens que la mayoría de los dashboards de costes no desglosan. En este artículo analizamos un objeto usage real, clase por clase y con cifras medidas.

TL;DR

• La configuración predeterminada de GPT-5.6 facturó 81 tokens por una respuesta de 10 tokens; el 88% fue razonamiento. En GLM 5.2 llegó al 98% y en Qwen3.7-max, al 99.3%.
• Claude Sonnet 5 facturó 114 tokens de pensamiento por una respuesta de 5 tokens, sin que la petición incluyera ningún parámetro de pensamiento.
• Cinco familias respondieron mal sin pensar (399, 400, 427, 466, 467); solo GPT-5.6 acertó sin razonamiento, y todas las ejecuciones con razonamiento respondieron 401.
• Una escritura de 1,181 tokens en la caché de Claude y su posterior lectura costaron $0.01246 y $0.00566, exactamente lo previsto por las tarifas publicadas.

Qué usamos para las pruebas

Todas las mediciones de este artículo proceden del mismo prompt de un solo turno, enviado a cada modelo con su configuración predeterminada salvo que la 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 (hay 333 múltiplos de 3 y 200 múltiplos de 5; al restar los 66 contados dos veces quedan 467, y al excluir los 66 múltiplos de 15 quedan 401). Elegimos este problema a propósito: la respuesta visible es mínima y ocupa 3-4 tokens con cualquier tokenizer; solo existe una respuesta correcta, así que se puede comprobar si el razonamiento sirvió de algo; y tiene la dificultad justa para que los modelos quieran pensar, que es precisamente el comportamiento que estamos auditando.

Las cinco clases de tokens de la factura

Una completion moderna puede facturar hasta cinco clases distintas de tokens, con cuatro tarifas diferentes. Un único valor agregado de «tokens usados» oculta todo este desglose.

Los nombres anteriores corresponden al formato compatible con OpenAI. Claude representa las mismas cinco clases con otros nombres: input_tokens y output_tokens, el pensamiento en output_tokens_details.thinking_tokens, facturado como salida, y las escrituras en caché desglosadas por TTL dentro de un objeto cache_creation (ephemeral_5m_input_tokens a 1.25x y ephemeral_1h_input_tokens a 2x). La estructura contable es la misma, aunque cambien las etiquetas. Más adelante volveremos al problema que esto plantea al parsear las respuestas.

Las cinco clases y sus multiplicadores de precio, con los nombres de campo compatibles con OpenAI y los de Anthropic. El 88% corresponde al porcentaje de razonamiento medido en GPT-5.6 en el ejemplo anterior.

Este es el objeto real del que sale el titular: GPT-5.6, con su configuración predeterminada, 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í está toda la aritmética de facturación, y conviene hacerla explícitamente al menos una vez. La respuesta recibida equivale a completion_tokens menos reasoning_tokens: 81 − 71 = 10 tokens, es decir, la palabra «401» y su formato. Los otros 71 tokens corresponden a la cadena de pensamiento, se facturan con la tarifa completa de salida y suponen el 88% del coste de salida. En GPT-5.6 no puedes leer ni uno solo. Todas las cifras de «respuesta visible» de este artículo se calculan igual. En otros modelos la proporción es aún mayor: GLM 5.2 respondió a la misma pregunta con 217 tokens de completion para una respuesta de 4 tokens. Un modelo de costes que interprete completion_tokens como «lo que dijo el modelo» se equivoca por un factor de 8x en el primer caso y de 54x en el segundo.

El razonamiento consume el presupuesto y se puede ajustar

Enviamos la misma pregunta de una línea con todas las configuraciones de pensamiento que admiten las tres familias ajustables. Usamos un único gateway los días 2026-07-13/14. Las filas están ordenadas de menor a mayor razonamiento dentro de cada familia; los modelos insignia predeterminados de las familias restantes aparecen en la siguiente sección:

La tabla permite extraer cuatro conclusiones claras:

• Cuando el control funciona, el impacto es grande. reasoning_effort: none respondió correctamente por $0.000062, 8.5x menos que la configuración predeterminada de luna. En tareas más difíciles hemos medido una diferencia de 20x en GLM 5.2. Elegir el tier también forma parte del mismo ajuste: el modelo insignia de GPT-5.6 respondió a esta pregunta sin ningún razonamiento de forma predeterminada, como veremos en la siguiente sección. Un modelo mayor que no necesita pensar puede salir más barato que uno pequeño que sí lo hace.
• En otras familias apenas tiene efecto. El margen real de ajuste depende de la familia: en Sonnet 5 es monotónico y produce una variación de coste de 5x (de 84 a 249); en GPT-5.6 es leve y no sigue un orden; en Qwen3.7-max casi no cambia nada (low siguió gastando 974 tokens de razonamiento frente a los 1,096 de la configuración predeterminada); y en DeepSeek V4 Pro no tuvo efecto (267 frente a 269).
• Las etiquetas no son monotónicas y las configuraciones predeterminadas no son deterministas. En esta prueba, high gastó menos tokens que medium en GPT-5.6; en nuestro artículo anterior, low gastó más que high en GLM; Sonnet 5 pensó durante 114 tokens en una petición que no enviaba ningún parámetro de pensamiento; y la misma petición predeterminada a GLM consumió 213 tokens de razonamiento en una ejecución y 1,312 en otra, seis veces más. Mide el efecto real del ajuste con tu carga de trabajo; no lo deduzcas de la etiqueta.
• Lo barato suele fallar por dar una respuesta incorrecta. Las dos familias que respondieron sin pensar se equivocaron (GLM dijo 399 y Sonnet 5, 467); en la siguiente sección aparece el recuento completo de las cinco familias. El razonamiento también es un presupuesto de corrección. Que compense reducirlo depende de la tarea, no del modelo.

La regla práctica es sencilla: trata reasoning_tokens como una partida de coste de primer nivel. Se factura con la tarifa de salida, suele superar ampliamente a la respuesta visible y depende de parámetros cuyo efecto real debes medir. En GPT-5.6 también cambiaron las reglas de precios; la guía de costes de GPT-5.6 explica el recargo por escritura y el requisito de la clave de caché.

¿Puedes leer realmente aquello por lo que pagaste?

Que el razonamiento esté «separado de la respuesta» no siempre significa que esté oculto. Comprobamos los cuerpos de las respuestas, no solo el objeto de uso:

• GLM 5.2, DeepSeek, Qwen3.7-max y MiniMax devuelven todo el texto del razonamiento en un campo reasoning_content junto a la respuesta (3,987, 1,604, 2,509 y 581 caracteres, respectivamente, en esta prueba). El desarrollador puede leer cada token facturado. El usuario final solo lo ve si la aplicación lo muestra, y la mayoría no lo hace.
• GPT-5.6 oculta la cadena de pensamiento sin procesar; como máximo ofrece un resumen. La respuesta puede incluir un reasoning.summary redactado por el modelo (359 caracteres en esta prueba), pero los 91 tokens facturados corresponden al texto original oculto, no al resumen. Lo más parecido a ese texto es reasoning.encrypted_content: un bloque cifrado que puedes reenviar para mantener la continuidad entre turnos, pero que nunca puedes descifrar. Los tokens por los que pagaste están en el cuerpo de tu propia respuesta, pero no puedes leerlos.
• En Claude depende de cómo hagas la petición. Nuestra llamada a Sonnet 5 con pensamiento adaptativo devolvió un bloque thinking vacío y facturó 114 thinking_tokens: consta que pensó, pero no hay nada que leer. Fable 5 hizo lo mismo con su configuración predeterminada de pensamiento siempre activo (59 facturados, bloque vacío). Sin embargo, al llamar al mismo Sonnet 5 con un presupuesto explícito de razonamiento, sí devolvió el texto real del pensamiento (73 tokens facturados y texto presente). La forma de hacer la petición determina qué puedes ver.

La facturación es uniforme, pero la visibilidad no. Todas las familias cobran el razonamiento con la tarifa de salida. La posibilidad de auditar el texto adquirido va desde verlo completo hasta recibir solo un resumen o un bloque vacío firmado.

Cuando el texto se devuelve, puedes evaluarlo de forma automática. Nuestra pregunta tiene cinco resultados intermedios fijos (333, 200, 66, 467, 401), y todos los razonamientos devueltos los contenían: GLM 5.2, DeepSeek V4 Pro, Qwen3.7-max, Kimi K2.7 Code y MiniMax M3 proporcionaron una derivación completa, mientras que las variantes de bajo esfuerzo omitieron un paso cada una. Para quien necesite el proceso y no solo la respuesta, la diferencia es esta: con reasoning_content puedes verificar aquello por lo que pagaste; con un resumen o un bloque vacío tienes que confiar en el modelo. Tokens invisibles, facturas visibles formaliza esta falta de trazabilidad, y PALACE estima externamente el razonamiento oculto.

La misma pregunta al mejor modelo de cada familia

La tabla anterior usaba tiers concretos para mostrar los controles disponibles. Esta es la respuesta del modelo insignia más reciente de cada familia a la misma pregunta, con la configuración predeterminada:

Tokens de salida facturados por cada modelo insignia para la misma pregunta (naranja rayado = porcentaje de razonamiento; verde = respuesta visible). El asterisco de MiniMax indica que el objeto de uso no incluye el recuento de razonamiento, por lo que el porcentaje se reconstruyó por sustracción y se verificó con el texto de razonamiento devuelto. La marca de GPT-5.6 sol señala la única ejecución correcta sin razonamiento; la cruz de Gemini 3.5 Flash, la única respuesta incorrecta entre los modelos insignia (466).

El gráfico reúne todos los formatos de reporte:

• Siete de los ocho modelos insignia respondieron correctamente, con costes muy distintos por devolver el mismo 401. Qwen3.7-max consumió 1,096 tokens de razonamiento, tardó 22 segundos y costó $0.0084; el modelo insignia de GPT-5.6 no usó ningún token de razonamiento y costó $0.00031. La diferencia es de 27x en coste y 7x en latencia para una respuesta correcta idéntica. Es el presupuesto de razonamiento hecho visible.
• MiniMax devuelve el texto del razonamiento, pero no su recuento. Facturó 260 tokens de completion por una respuesta visible de 3 tokens. La respuesta incluye toda la derivación en reasoning_content, pero completion_tokens_details no contiene una partida de razonamiento. Si falta el recuento, se puede reconstruir por sustracción: tokens de completion menos tokens visibles equivale al recuento de salida oculta.
• Gemini 3.5 Flash es el caso atípico: fue el único modelo insignia que respondió mal (466), con 3 tokens de completion y sin recuento de razonamiento en ningún campo. Su modelo hermano 2.5 Flash tardó una vez 12.5 segundos en producir un 401 de 3 tokens sin indicar en la factura el motivo de la demora; al repetir la ejecución respondió 427.
• Las respuestas incorrectas se concentran en los tiers pequeños y en las configuraciones con el pensamiento desactivado. GLM sin pensamiento respondió 399; Sonnet 5 con el pensamiento desactivado, 467; el antiguo qwen3-max no pensó en absoluto (3 tokens) y respondió 400; Kimi K2.5, que no tiene canal de razonamiento, razonó en voz alta durante 144 tokens visibles facturados, obtuvo 401 en su propio desarrollo y terminó concluyendo 400. Cinco familias y cinco respuestas incorrectas distintas: 399, 400, 427, 466 y 467. Solo GPT-5.6 acertó sin razonamiento.

Tokens de caché: dos direcciones con una diferencia de 12x

La caché de prompts divide la entrada en otras dos clases. La diferencia de precio entre ambas explica por qué se desglosan: en Claude, las escrituras se facturan a 1.25x la tarifa de entrada (2x con un TTL de 1 hora) y las lecturas, a 0.1x. Medimos dos llamadas a Opus 4.8 con un prompt de sistema de 1,181 tokens almacenado en caché. Costaron $0.01246 por la escritura y $0.00566 por la lectura. Ambas cifras coinciden con las tarifas publicadas hasta el sexto decimal, y el coste de entrada cayó unas 11x entre una llamada y otra. Lo relevante aquí es la contabilidad: si agrupas cache_creation_input_tokens y cache_read_input_tokens como «tokens de entrada», no podrás verificar el descuento ni detectar cuándo deja de aplicarse sin avisar. Esto ocurre más a menudo de lo que sugiere la documentación: nuestras mediciones de caché detectaron umbrales efectivos entre 1.4 y 2.4x superiores a los mínimos documentados, y la guía de caché de prompts explica en detalle el funcionamiento de cada proveedor.

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

Es habitual estimar el coste en el cliente con una biblioteca de tokenización y conciliarlo después. Hay tres motivos por los que las cifras no coinciden:

• Cada proveedor usa tokenizers distintos. Contar texto destinado a Claude con un tokenizer de OpenAI es medir con la regla equivocada. La misma cadena se tokeniza de forma distinta en cada familia.
• Se factura más que tu mensaje. Los prompts de sistema y los esquemas de herramientas cuentan como tokens de entrada en todas las peticiones que los incluyen, y es fácil omitirlos de una estimación local.
• El razonamiento es impredecible hasta recibir la respuesta. Ningún recuento en el cliente puede anticipar cuántos tokens de pensamiento gastará el modelo. Solo se conoce al recibir el objeto usage.

El objeto usage devuelto es el registro de facturación del propio proveedor. Por tanto, el contador preciso más barato consiste en dejar de estimar y leerlo directamente. El problema es que cada proveedor usa un formato distinto: según la familia, los tokens almacenados en caché aparecen como cached_tokens, prompt_cache_hit_tokens, total_cached_tokens o cache_read_input_tokens.

Los objetos de detalle tampoco tienen un esquema fijo. La referencia de OpenAI documenta cuatro campos del lado de la completion: reasoning_tokens, audio_tokens y el par de Predicted Outputs accepted_prediction_tokens / rejected_prediction_tokens. Los tokens de predicción rechazados nunca aparecen en la salida, pero se siguen facturando como tokens de completion. En la entrada, el mismo formato añade text_tokens, audio_tokens e image_tokens junto a cached_tokens; GPT-5.6 añade cache_write_tokens, y también hemos visto video_tokens en respuestas reales. Los proveedores amplían el esquema con libertad: Kimi K2.7 devolvió un completion_tokens_details.text_tokens no documentado, y Gemini contabiliza por separado los tokens de pensamiento y de uso de herramientas con sus propios nombres. El parser debe ser defensivo: espera campos de detalle desconocidos y nunca interpretes un campo ausente como cero. Los campos de audio tienen su propia estructura de costes: medimos por separado el coste del reconocimiento de voz por minuto de audio facturado en siete modelos ASR especializados.

Aquí es donde un gateway aporta valor: Synthorai normaliza todos estos formatos en un único objeto, con reasoning_tokens y las dos direcciones de caché rellenas para OpenAI, Anthropic, Gemini y las familias open-weight. Así, un único parser cubre todos los modelos a los que enrutes tráfico.

De observar el gasto a impedirlo

Leer el registro es solo la mitad del trabajo. La otra mitad consiste en impedir que se supere el presupuesto, no limitarse a detectarlo. Los dashboards de fin de mes informan de la sorpresa cuando el dinero ya se ha gastado, y un agente atrapado en un bucle de reintentos no consulta dashboards. En el gateway, cada clave tiene una quota, un used_quota acumulado y un límite de RPM, todos aplicados en el momento de la petición. Cuando una clave agota su presupuesto, la siguiente petición devuelve un error explícito, no una factura mayor tres semanas después. La atribución por petición, qué clave, qué modelo y si usa BYOK o facturación de la plataforma, se devuelve en el mismo contenedor de respuesta. Así, calcular el coste por funcionalidad se reduce a un group-by, no exige reconstruir los datos.

Las mediciones indican un orden claro: antes de optimizar, lee reasoning_tokens y los campos de caché; ajusta el nivel de razonamiento por tarea; y configura una cuota estricta en cualquier clave cuyo modo de fallo pueda generar un bucle. Para calcular cuánto costará un conjunto concreto de modelos y clases de tokens con tu volumen, el optimizador de costes usa las mismas tarifas por token empleadas en este artículo.

← Volver al blog