Ventana de contexto breakpoints y prompt caching

Un millón de tokens de ventana suena impresionante en un slide de marketing, pero la realidad de GPT-5.6 es distinta: dos tercios de esa ventana te cobran el doble y, encima, la calidad de lectura se degrada conforme avanzas. Aquí desglosamos por qué esa ventana no es un recurso uniforme y cómo usar prompt caching para no quemar presupuesto.

¿Por qué la ventana de GPT-5.6 no es un recurso uniforme?

La ventana funciona como un terreno con zonas de confort, zonas caras y zonas donde el modelo directamente lee peor que su predecesor. Entender ese mapa es lo que separa un despliegue rentable de una factura sorpresa.

¿Dónde está la zona óptima de lectura?

Entre 256.000 y 512.000 tokens, Sol alcanza 91,5% de accuracy en retrieval multi-needle [00:25]. Esa es la franja donde el modelo rinde como promete el marketing.

Arriba de 512.000 tokens la historia cambia. El accuracy cae a 74%, exactamente el mismo score que GPT-5.5 [00:40]. Traducido: en el tercio superior de la ventana no hay mejora generacional, estás pagando premium por un rango donde el modelo no lee mejor que el anterior.

¿Qué tan buena es la lectura de GPT-5.6 en contextos largos? Excelente entre 256K y 512K tokens (91,5% de accuracy). Arriba de 512K cae a 74%, el mismo nivel que GPT-5.5.

¿Qué basura silenciosa acumulan las sesiones largas?

Este es el segundo problema, más sutil. Las sesiones largas acumulan tool descriptions repetidas, system prompts copiados entre turnos y respuestas de subagentes pegadas al contexto [00:57]. Una sesión que arranca cómoda en 150.000 tokens puede derivar hacia la zona degradada sin que nadie se dé cuenta.

¿Cómo funciona el pricing cliff de 272.000 tokens?

Aquí viene el acantilado. Cuando un request supera los 272.000 tokens de input, toda la petición se reprecia. No los tokens extra. Toda [01:17].

Piensa en un estacionamiento que cobra tarifa nocturna completa en el instante en que cruzas medianoche, incluyendo retroactivamente las horas que ya estuviste ahí. Para Sol, pasas de 5 a 10 dólares por millón de input, y de 30 a 45 de output [01:37].

Esa supuesta ventaja de precio de Sol frente a Claude Sonnet 5, que cobra 10 fijos sin cliff, desaparece por encima del umbral. La paridad es casi total.

¿Qué pasa si mi request supera 272K tokens en GPT-5.6? Toda la petición se cobra al doble, no solo los tokens extra. Es un cambio retroactivo de tarifa sobre el input completo.

¿Cómo sobrevives económicamente con contexto largo?

La respuesta es prompt caching con breakpoints explícitos. Marcas un punto en tu prompt donde todo lo anterior es estable y reutilizable, y las siguientes requests que compartan ese prefijo pagan solo el costo de lectura de caché.

¿Qué son los breakpoints y las cache keys?

El marker se llama prompt_cache_breakpoint [02:21]. Necesitas también una prompt_cache_key obligatoria, un string que actúa como etiqueta de estantería en una biblioteca. Si dos requests usan la misma key y el mismo contenido antes del breakpoint, la copia guardada se reutiliza.

El patrón recomendado para la key es tenant:nombre:versión [02:40]. Así aíslas por cliente, por versión del prompt y hasta por brazo de un A/B test. Límite práctico: cada key soporta unas 15 requests por minuto; si necesitas más, particionas por routing.

¿Modo implícito o explícito?

Hay dos modos disponibles:

• Implícito (default): coloca automáticamente un breakpoint en el último mensaje y te deja agregar hasta 3 más.
• Explícito: desactiva el automático y solo aplican los breakpoints que tú definas.

OpenAI recomienda empezar en implícito y migrar solo cuando tus logs muestren que el placement automático desperdicia writes.

¿Cuánto cuesta realmente el caching en Sol?

Los costos tienen tres niveles bien diferenciados:

• Input normal: 5 dólares por millón.
• Cache write: 6,25 dólares por millón, o sea 1,25x.
• Cache read: 0,50 dólares por millón, un descuento del 90%.

El TTL garantizado es de 30 minutos [03:36]. Antes de 5.6 las escrituras eran gratis; ahora cada prefijo inestable te cobra 1,25x por la reescritura. La inestabilidad del prefijo dejó de ser un problema estético y se convirtió en un bug de facturación.

¿Cuántos reads necesitas para cubrir un write?

La matemática es casi absurda: 0,25 dividido 0,90 da 0,28. Un solo hit dentro de 30 minutos ya te pone en ganancia [04:05]. Si cacheas un millón de tokens, el write extra cuesta 1,25 dólares y un solo read te ahorra 4,50 dólares. El caching solo pierde dinero si escribes un prefijo y literalmente nunca lo vuelves a usar.

¿Cuándo conviene activar prompt caching en GPT-5.6? Casi siempre. Con un solo cache hit en 30 minutos ya recuperas el costo del write. Solo pierdes si el prefijo nunca se reutiliza.

¿Qué pasa cuando combinas caching con el cliff?

Aquí las dos mecánicas se cruzan de forma poderosa. Imagina un sistema de revisión legal: 400.000 tokens de prefijo y 10 requests en 30 minutos.

• Sin cache: cada request paga tarifa premium porque estás encima del cliff. Total: 40 dólares de input.
• Con cache: el write cuesta 5 dólares y los 9 reads cuestan 3,60. Total: 8,60 dólares.

El ahorro supera el 78% solo por mover el mismo trabajo a través del sistema de caché.

¿Qué incertidumbres siguen sin respuesta oficial?

Hay preguntas que nadie ha resuelto públicamente y que conviene asumir en el peor escenario:

• ¿El TTL se renueva con cada read o corre fijo desde el write? Sin documentación.
• ¿La compaction invalida el caché? Probablemente sí, porque cambia la secuencia.
• ¿Los tokens cacheados cuentan hacia el umbral de 272K? Sin respuesta oficial.

La regla para producción es simple: asume el caso conservador. Da por hecho que el TTL no se renueva, presupuesta múltiples writes por día y loggea cached_tokens y cache_write_tokens desde el día cero. Mantén el prefijo estable como un schema de base de datos: cambios deliberados y versionados, nunca accidentales. Si la realidad resulta mejor, es upside gratuito.

Toda la math de caching que calculaste para GPT-5.5 quedó obsoleta. Recalcula desde cero. Cuéntanos en los comentarios cómo estás midiendo tus cache hits y qué patrones de key te están funcionando en producción.