GPT-6.1 Terra Caching: cinco centavos por lectura y cuándo compensa la escritura

La tarifa de entrada en caché de GPT-6.1 Terra es de $0.05 por millón de tokens — un 95% por debajo de la tarifa estándar de entrada de $1.00, y el mayor descuento individual de toda la tarjeta. La trampa está en el otro lado del balance: escribir en la caché cuesta $1.25 por millón por una retención de 30 minutos, o $2.50 por millón por 12 horas. Una carga de trabajo que lee el mismo prefijo dos veces sale ganando. Una carga de trabajo que reconstruye su prefijo en cada llamada paga la tarifa de escritura y nunca recoge el descuento, y la tarjeta de tarifas no te dirá cuál de las dos estás ejecutando.

Este artículo hace los cálculos: el punto de equilibrio exacto, tres cargas de trabajo resueltas a diferentes escalas, la interacción con el acantilado del contexto largo de 272K y los hábitos de ingeniería de prompts que destruyen las cachés silenciosamente.

Los cuatro números

• Entrada estándar — $1.00 por millón de tokens.

• Entrada en caché — $0,05 por millón, un descuento del 95 %.

• Escritura en caché, retención de 30 minutos — $1.25 por millón.

• Escritura en caché, retención de 12 horas — $2,50 por millón.

Por encima de 272.000 tokens de entrada todo se duplica: 2,00 $ la entrada, 0,10 $ la caché, 2,50 $ la escritura en caché. Así que el precipicio del contexto largo no solo eleva la tarifa de entrada: también encarece a la vez tanto el uso de la caché como la escritura en caché.

A modo de comparación, la entrada en caché de GPT-6.1 Sol cuesta $0.10 y la de GPT-5.6 Terra cuesta $0.20. La lectura de cinco centavos de Terra es la más barata de la familia, y el descuento del 95 % es lo que hace que las llamadas repetidas con contexto largo sean siquiera económicamente posibles.

El punto de equilibrio exacto

Suponga un prefijo de P tokens reutilizado en N llamadas, e ignore la salida por un momento.

• Sin caché: N × P × $1.00.

• Con almacenamiento en caché: una escritura a $1.25 × P, luego N lecturas a $0.05 × P.

Igualándolos: 0.95N = 1.25, por lo que N ≈ 1.32. En la práctica, eso significa que la segunda llamada ya es rentable: la escritura cuesta 1.25 por millón y cada lectura ahorra 0.95, así que dos lecturas recuperan más de lo que cuesta la escritura. Con una retención de 12 horas, la escritura cuesta $2.50 y el punto de equilibrio es de 2.63 lecturas — la tercera llamada ya lo compensa.

Ese umbral es más bajo de lo que la mayoría de los equipos supone. El mito común es que el almacenamiento en caché solo compensa con una reutilización muy alta; en esta tarjeta compensa desde la segunda solicitud, siempre que el prefijo realmente coincida.

Tres cargas de trabajo

Un prompt de sistema de 50.000 tokens en 10.000 solicitudes breves. Sin caché: 10.000 × 50.000 × $1,00 por millón = $500 solo por el prefijo. Con caché: una escritura de 50.000 × $1,25 por millón = $0,0625, más 10.000 lecturas a 50.000 × $0,05 por millón = $25. Total: $25,06 — un ahorro del 95% en el prefijo, y la escritura en caché es un error de redondeo.

Un repositorio de 900.000 tokens en 20 preguntas. Sin caché, cada solicitud activa la tarifa de contexto largo: 900.000 × $2,00 por millón = $1,80 por llamada, $36 por veinte. Con caché: una escritura de 900.000 × $2,50 por millón = $2,25, luego veinte lecturas a 900.000 × $0,10 por millón = $0,09 cada una, $1,80 en total. Total: $4,05 — un ahorro del 89%, y la diferencia de dieciocho dólares es todo el margen de algunos productos.

Un documento de 20.000 tokens repartido entre tres preguntas, cada una con una personalidad y unas instrucciones diferentes. Este es el caso en el que la caché falla: si el prefijo cambia entre llamadas —distinto prompt del sistema, distinto orden de instrucciones, un ID de usuario interpolado al principio—, el modelo ve tres prefijos distintos y escribe tres cachés. Sin caché y con «caché» cuesta lo mismo, salvo que pagaste por las escrituras. La solución es estructural: coloca todo lo variable al final del prompt y mantén el documento y las instrucciones estables al principio.

Qué rompe una caché/p> p>El almacenamiento en caché de prompts de OpenAI funciona sobre el prefijo sin cambios de una solicitud. Cualquier cosa que cambie al principio del prompt invalida todo lo que viene después. Los sospechosos habituales:/p> p>• Una marca de tiempo o un ID de solicitud en el prompt del sistema. Es la causa más común de una tasa de aciertos de caché del 0%./p> p>• Personalización por usuario insertada al principio en lugar del final./p> p>• Definiciones de herramientas reordenadas o una lista de herramientas que cambia entre llamadas./p> p>• Un paso de recuperación que concatena documentos en un orden diferente cada vez./p> p>• Cambios de espacios en blanco de los motores de plantillas; basta con reformatear un bloque JSON./p> p>• Cambiar entre Chat Completions y Responses a mitad del flujo de trabajo, lo que cambia el prefijo serializado./p> p>El diagnóstico es sencillo: registra los primeros 2.000 tokens de cada solicitud y calcula su hash. Si el hash cambia entre llamadas que deberían ser idénticas, la caché está muerta y ningún ajuste la revivirá./p> h2>La caché y el acantilado de 272K

Ambos interactúan de un modo fácil de pasar por alto. Un prefijo en caché de 250.000 tokens cuesta $0,05 por millón para lectura y $1,25 para escritura. Auméntalo a 300.000 tokens y cada cifra se duplica: $0,10 de lectura, $2,50 de escritura, y la parte no cacheada se factura a $2,00. Una canalización que cruza el umbral paga el salto de precio tanto en el lado de la caché como en el de lo no cacheado.

Esto crea un incentivo de diseño que no es obvio: si una carga de trabajo se sitúa justo por encima de 272K, reducir el prefijo a 270K puede reducir la factura a la mitad sin cambiar la tarea. Recortar una sección de texto repetitivo, eliminar un bloque de recuperación innecesario o sacar un ejemplo del prompt del sistema vale más en el límite de lo que vale en cualquier otro punto de la tarjeta.

El almacenamiento en caché frente a las alternativas

• Almacenamiento en caché — ideal cuando el mismo prefijo largo se reutiliza muchas veces dentro de la ventana de retención y el prefijo es realmente estable.

• Fragmentación (chunking) — es mejor cuando el documento es grande pero cada pregunta solo toca una pequeña parte; la recuperación es más económica que enviar 900K tokens incluso a la tarifa de caché.

• Batch/Flex: 50 % de descuento sobre el estándar, pero la latencia por lotes se mide en horas; se acumula con el almacenamiento en caché, no con productos en tiempo real.

• Un modelo más barato — GPT-6 Luna a $0.10/$0.50 puede superar la tarifa en caché de Terra para tareas simples, porque la entrada no cacheada de Luna es solo el doble de la entrada en caché de Terra.

La última comparación es la que los equipos olvidan. El almacenamiento en caché es un descuento en Terra, no una garantía de que Terra sea la forma más barata de responder a una pregunta. Para clasificación con un prompt de 50.000 tokens, Luna en caché a $0.01 por millón de lecturas sigue siendo la opción más barata si la tarea es lo bastante simple.

Lo que puedes ejecutar hoy

GPT-6.1 Terra no está en el catálogo de OrcaRouter en el momento de redactar este texto, por lo que su comportamiento de caché debe medirse directamente contra OpenAI. Los modelos que están activos —GPT-6.1 Sol a $2/$10 con una tarifa de caché de $0.10, GPT-5.6 Terra a $2/$12 con $0.20, GPT-6 Luna a $0.10/$0.50— pueden probarse todos con una sola clave a un 0% de margen sobre el precio de lista del proveedor.

La medición que hay que construir no es «¿funciona el almacenamiento en caché?» —funciona—, sino «qué fracción de mi tráfico tiene un prefijo estable». Esa fracción es el único número que decide si la lectura de cinco centavos de Terra importa para tu factura, y es una propiedad de tus prompts, no del modelo.