Ventana de contexto breakpoints y prompt caching

Contenido del curso

No sé dónde empezar

Elegir modelo y modo de razonamiento correcto

Promptear GPT-5.6 según la doctrina oficial

Contexto largo caching y cálculo de costos

Decisión entre proveedores y migración segura

Disciplina epistémica riesgos y limitaciones reales

10
Verificación de datos riesgos y limitaciones reales
06:55 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:006:15

Ventana de contexto breakpoints y prompt caching

Curso de GPT-5.6

Clase 6 de 10

Clase 6 / 10

Recursos

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.

Resumen

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

¿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.

¿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?

¿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].

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?

¿Qué son los breakpoints y las cache keys?

¿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%.

¿Cuántos reads necesitas para cubrir un write?

¿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.

Comentarios (5)5 comentarios

Paty Restrrepo

Hace 2 meses

He hecho varios de los cursos de AI de Platzi. Con profes humanos. Y el curso de CEO con AI. Soy una mujer de mediana edad, queriendo aprender a usar AI para su pequeño negocio. Pero con este curso específico me estoy sintiendo como Manolito el personaje de Mafalda, cuando el profe preguntó a la clase que habían entendido..."Desde el principio, hasta ahora, Nadaaaaa" Terriblemente confuso, cero práctico para personas sin conocimientos técnicos, en spanglish. Todo mal con este curso.

Juan Ramón García Santabárbara

Company_admin

Hace 3 meses

Me parece una clase completamente confusa, no me gusta

Adrián Soto Girón

Ventajas del Caching

Ahorro masivo: Reduce el costo de lectura en un 90%, permitiendo rentabilizar contextos largos.
Eficiencia operativa: Un solo hit de caché dentro de los 30 minutos de vida útil ya compensa el costo extra de escritura.
Mitigación del "cliff": Permite ejecutar múltiples peticiones pesadas sin disparar el costo total por superar el umbral de tokens.

Reglas para Producción

Versionado estricto: Trata tus prefijos como schemas de base de datos (tenant:name:version); nunca hagas cambios accidentales.
Monitoreo proactivo: Loguea cached_tokens y cache_write_tokens desde el primer día para detectar desperdicios.
Mentalidad conservadora: Asume que el TTL no se renueva con cada lectura y presupuesta múltiples escrituras diarias.

David Cevallos

Ulqernesh Karvenae

Elegir modelo y modo de razonamiento correcto

Sol Terra Luna especificaciones y parámetros

Selección de modelo por escenario de producción

Reasoning effort max Pro Ultra y subagentes

Promptear GPT-5.6 según la doctrina oficial

Lean prompting doctrina oficial y mitos

System messages tool calling y rituales obsoletos

Contexto largo caching y cálculo de costos

Ventana de contexto breakpoints y prompt caching

Tarifas recargos y cálculo de costos reales

Decisión entre proveedores y migración segura

GPT-5.6 Sol versus Claude Fable 5 por tarea

Migración de prompts agénticos entre ecosistemas

Disciplina epistémica riesgos y limitaciones reales

Verificación de datos riesgos y limitaciones reales

Ventana de contexto breakpoints y prompt caching

Progreso del curso

Elegir modelo y modo de razonamiento correcto

Promptear GPT-5.6 según la doctrina oficial

Contexto largo caching y cálculo de costos

Decisión entre proveedores y migración segura

Disciplina epistémica riesgos y limitaciones reales

Recursos

Recursos