Tarifas recargos y cálculo de costos reales

El precio de lista de un modelo de lenguaje es como el precio del boleto de avión antes de impuestos, equipaje y selección de asiento: parece claro hasta que llega la factura real. GPT-5.6 publica tres modelos con precios oficiales, pero en producción hay al menos cinco mecanismos que deforman esos números hasta llegar a un rango de 68x en costo dentro de la misma familia. Si trabajas con LLMs en producción, entender estos mecanismos es la diferencia entre pagar 65 dólares por hora o pagar 2,822.

Cuáles son los precios base de GPT-5.6 Sol, Terra y Luna

Antes de hablar de sobrecargos, conviene fijar la tabla base publicada por el proveedor [00:32].

• Sol: 5 dólares de input y 30 de output por millón de tokens.
• Terra: exactamente la mitad, 2.50 y 15.
• Luna: un quinto, 1 dólar y 6 de output.

Sol mantiene el mismo precio que GPT-5.5, así que no hubo reducción en el flagship. Calcular una petición teórica es aritmética simple: tokens enviados por precio de input más tokens recibidos por precio de output. Con Sol, 100,000 tokens de entrada y 10,000 de salida dan 80 centavos. Sencillo, pero ese es el mundo teórico.

¿Cuánto cuesta realmente una petición en GPT-5.6? Depende de cinco variables ocultas: si usas Batch API, si cruzas el umbral de 272,000 tokens, cuánto reasoning effort configuras, si activas Ultra mode y qué tan bien aprovechas el caching.

Qué mecanismos ocultos inflan el costo real en producción

Estos son los cinco puntos donde tu factura se despega del precio de lista [01:12].

Cómo funcionan el Batch API y el acantilado de 272k tokens

El Batch API te da 50% de descuento si toleras latencia: Sol baja a 2.50 y 15 [01:20]. Pero el acantilado de 272,000 tokens sigue aplicando. Si tus batch requests cruzan ese umbral, Sol batch pasa a 10 dólares de input, exactamente lo que cobra Fable 5 en batch estándar. El descuento desaparece para contexto largo.

Este recargo por contexto largo funciona así: cruzas 272k tokens por una sola petición y toda la solicitud se repreicia. El input se duplica y el output sube 50%. Es como una aerolínea que cobra sobrepeso por toda la maleta cuando superas 23 kilos por 100 gramos.

Por qué los reasoning tokens son el driver principal del costo

Cuando subes el nivel de esfuerzo, el modelo genera tokens internos de pensamiento que no ves pero se facturan como output [02:01]. No hay tope. El setting de esfuerzo, sin cambiar la tarea, es el driver principal del costo. Por eso el spread dentro de la misma familia llega a 68x.

Qué pasa con Ultra mode y los subagentes en paralelo

Ultra mode lanza hasta cuatro subagentes en paralelo, y cada uno factura como un Sol completo por separado [02:14]. No puedes asignar un modelo más barato por subagente. Los analistas modelan Ultra entre 2x y 4x el costo estándar, pero servicios de tracking reportan 6x a 12x en uso pesado, porque las sesiones reales incluyen context scanning repetido y cache writes desperdiciados por subagente.

Por qué el modelo más barato no siempre es el más rentable

Esto es contraintuitivo: el modelo más barato no siempre es más barato por tarea completada [02:44]. Terra tiene mitad de precio por token, pero en el benchmark de CodeRabbit pasó solo 40.7% de tareas consumiendo 2.65 veces más tokens. Mitad de precio multiplicado por 2.65x más tokens da un costo mayor por resultado exitoso.

Cómo calcular el costo real de un sistema RAG en producción

Tomemos un sistema RAG con 1,000 consultas por hora [03:08]. Cada query envía 6,000 tokens de system prompt fijo, 4,000 de contexto recuperado y genera 500 de output. Todo bajo el cliff.

• Sin caching: 6.5 centavos por query, 65 dólares por hora.
• Con caching del system prompt: 3.8 centavos por query, 38 dólares por hora. Ahorro de 42%.
• Cruzando el cliff a 280,000 tokens: la petición pasa de 1.41 a 2.82 dólares por query. A mil por hora: 2,822 dólares.

Solo estás 10% por encima del umbral. La recomendación operativa: configura tu compaction threshold en 265,000 tokens. Comprimir antes de cruzar te ahorra el 100% del recargo.

¿Cuándo conviene cambiar de modelo en lugar de optimizar el prompt? Casi nunca primero. Revisa tu reasoning effort (spread de 68x), luego estabiliza tu prefijo para aprovechar caching, y solo después considera cambiar de proveedor.

Cuál es el orden correcto para optimizar tus costos

Antes de saltar a otro proveedor, sigue esta secuencia [04:19].

1. Revisa tu reasoning effort primero. Si estás en Sol max y puedes bajar a high sin perder calidad medible, ahorras más que cualquier cambio de modelo.
2. Estabiliza tu prefijo. Si cambia por timestamps o UUIDs en cada request, pagas 1.25x en writes desperdiciados. Estabilizarlo te da reads al 10% del costo, un ahorro del 90% en la porción cacheada que supera el 50% de bajarte de Sol a Terra.
3. Revisa tu posición respecto al cliff. Si rutinariamente cruzas 272,000 tokens, Sol y Fable 5 están en paridad de precio. Compactar para mantenerte bajo el umbral ahorra más que cambiar de proveedor.

Y aquí viene lo que ninguna comparación publicada modela: todas las cifras en circulación son a cache frío. En un pipeline dominado por caching, el ratio real es desconocido. Tu única fuente de verdad es instrumentar tu propio pipeline y medir. Cuéntame en los comentarios qué mecanismo te sorprendió más y cuál ya estabas optimizando sin saberlo.