DR
La tarificación de entrada en caché puede reducir de forma sustancial el costo de cargas de trabajo que reenvían un prefijo de prompt grande e inalterado, pero el ahorro depende de reglas específicas del modelo para lectura desde caché, escritura en caché, almacenamiento, enrutamiento y retención. Una etiqueta general de “caching supported” no basta para estimar el costo; usa el precio vigente publicado para el modelo y la ruta exactos.
TL;DR
- GPT-5.6 Terra tiene precios explícitos de lectura y escritura de caché por parte de OpenAI, CometAPI y OpenRouter, aunque las rutas de gateway y los niveles de contexto largo pueden cambiar el importe.
- Google publica una tarifa de contexto en caché Standard de $0.15 por 1M tokens para Gemini 3.6 Flash, además de un cargo por almacenamiento; CometAPI actualmente publica los precios estándar de entrada y salida del modelo sin una línea separada para entrada en caché.
- La comparación relevante no es solo entrada estándar frente a lectura desde caché. También incluye la primera escritura en caché, cualquier cargo de almacenamiento, la vida útil de la caché, la consistencia de la ruta y el número de aciertos posteriores de caché.
Key messages
- Consulta precios a nivel de modelo y de nivel de servicio en lugar de aplicar un multiplicador a nivel de gateway.
- Mantén por separado lectura desde caché, escritura en caché, almacenamiento y caché de respuesta en los cálculos de costos.
- Verifica el uso real de la caché en los metadatos de respuesta de la API antes de pronosticar ahorros a partir de la tarifa publicada.
Una solicitud que repite un prefijo grande e inmutable —un prompt del sistema, un conjunto de esquemas de herramientas, un documento de referencia largo— no tiene por qué facturarse a la tarifa completa de entrada en cada llamada. La mayoría de los modelos de generación actual admiten alguna forma de tarificación de entrada en caché: una tarifa reducida para la parte del prompt que un proveedor reconoce como ya procesada. El mecanismo, el tamaño del descuento y lo claramente que se publica varían según el proveedor y el gateway, y esa variación vale la pena especificarla en lugar de tratar “se admite caché” como una característica uniforme.
What cached input pricing is, and isn't
La tarificación de entrada en caché descuenta los tokens de entrada en una solicitud que coinciden con un prefijo enviado previamente. No descuenta los tokens de salida y no es lo mismo que un gateway que deduplica dos solicitudes completamente idénticas y devuelve una respuesta gratis: ese es un mecanismo diferente que algunos gateways ofrecen por separado. La tarificación de entrada en caché trata específicamente de pagar menos por la parte de un prompt que un proveedor del modelo ya ha visto recientemente, no de omitir la generación por completo.
Tampoco es gratis crearla. Las notas de precios de GPT-5.6 de OpenAI indican que las escrituras en caché se facturan a 1.25 veces la tarifa de entrada sin caché, mientras que las lecturas desde caché reciben un descuento del 90%. Esa prima de primera escritura afecta el punto de equilibrio y es fácil pasarla por alto si una comparación solo muestra la tarifa de lectura con descuento. Otros proveedores pueden usar cargos basados en almacenamiento en lugar del mismo modelo de escritura, por lo que deben revisarse por separado los costos de escritura y de almacenamiento.
En la práctica, la unidad facturable de caché suele ser un prefijo de prompt reutilizable más que una colección arbitraria de oraciones repetidas. Los proveedores tokenizan y comparan el contenido en orden, así que el material reutilizable debe aparecer antes de la cola específica de la solicitud. Instrucciones estables del sistema, definiciones de herramientas, políticas y material de referencia pertenecen al principio; un mensaje de usuario cambiante, marca de tiempo, ID de solicitud o fragmento recuperado va después. Incluso un cambio semánticamente inocuo al principio puede alterar la tokenización o romper la coincidencia de todo lo que sigue.
Las reglas de elegibilidad también son específicas del modelo. Un proveedor puede exigir una longitud mínima de prompt, reconocer solo puntos de corte documentados o exponer un campo explícito de control de caché. Una entrada de caché puede caducar entre llamadas, y un gateway puede necesitar mantener solicitudes relacionadas en una ruta ascendente compatible. Eso significa que un despliegue debe tratar un acierto de caché como un resultado observado, no como una suposición basada en la similitud del prompt. Un prompt bien estructurado mejora la probabilidad de reutilización, pero los metadatos de la respuesta y la factura determinan si realmente se aplicó la tarifa con descuento.
What's actually published, by model and by gateway
La tabla siguiente es una instantánea de precios verificada el 29 de julio de 2026. Los precios están en dólares estadounidenses por 1 millón de tokens salvo que se indique otra unidad. Las filas comparan la información pública actual para GPT-5.6 Terra y Gemini 3.6 Flash entre el proveedor del modelo, CometAPI y OpenRouter; no deben considerarse una tarifa permanente.
| Model | Gateway | Standard input | Cached input (read) | Cache write | Discount disclosed? |
|---|---|---|---|---|---|
| GPT-5.6 Terra | Official OpenAI rate | $2.50 / 1M | $0.25 / 1M | $3.13 / 1M | Sí — 90% de descuento, indicado directamente |
| GPT-5.6 Terra | CometAPI | $2.00 / 1M | $0.20 / 1M | $2.50 / 1M | Sí — figura en la propia página de precios de CometAPI |
| GPT-5.6 Terra | OpenRouter | $2.50 / 1M | No aparece como una tarifa específica | No listado | No — descrito solo como "60–80% más barato" en agregado, sin cifra por modelo |
| Gemini 3.6 Flash | Official Google rate | $1.50 / 1M | $0.15 / 1M (según el propio anuncio de Google) | No divulgado | Sí, en el lanzamiento — a través de la documentación del modelo de Google |
| Gemini 3.6 Flash | CometAPI | $1.20 / 1M | No aparece como una tarifa específica | No divulgado | No — la página de CometAPI marca "Caching" como una función admitida, pero no publica una cifra con descuento para este modelo específico por ahora |
| Gemini 3.6 Flash | OpenRouter | $1.50 / 1M | No aparece como una tarifa específica | No divulgado | No — la documentación de OpenRouter describe el multiplicador de caché de Google de forma genérica (0.25x sobre la entrada de lista) en lugar de confirmar la tarifa específica de este modelo |
Lee la tabla como una instantánea específica por modelo y ruta. La página del modelo GPT-5.6 de CometAPI detalla GPT-5.6 Terra a $2.00 de entrada estándar, $0.20 de entrada en caché y $2.50 de escritura en caché por 1 millón de tokens. Su página del modelo Gemini 3.6 Flash actualmente publica $1.20 de entrada y $6.00 de salida, pero no muestra un precio separado de entrada en caché ni de almacenamiento de caché. Los precios de la Gemini Developer API de Google listan el nivel Standard a $1.50 de entrada, $0.15 de context caching y $1.00 por 1 millón de tokens por hora para almacenamiento. OpenRouter ahora expone campos de caché específicos por modelo a través de su Models API: la ruta predeterminada de GPT-5.6 Terra incluye precios promocionales más bajos y un nivel separado más alto para contexto largo, mientras que su entrada de Gemini 3.6 Flash expone valores Standard, Flex y Priority diferentes. Esto es más preciso que aplicar un multiplicador de caché genérico a todos los modelos.
Why gateway and provider prices can diverge
El precio de un gateway no es necesariamente un recargo sobre una lista ascendente inmutable. Puede reflejar capacidad negociada, una promoción temporal, un nivel de servicio diferente o un acuerdo comercial específico de la ruta. Un nombre de modelo también puede mapear a múltiples variantes ascendentes cuyos precios cambian con la longitud del contexto o las garantías de latencia. La entrada de GPT-5.6 Terra en OpenRouter, por ejemplo, publica una ruta predeterminada y una ruta alternativa de mayor precio una vez que la entrada alcanza su umbral de contexto largo. Google separa precios Standard, Batch, Flex y Priority para Gemini 3.6 Flash. Por lo tanto, una sola fila comparativa necesita fecha, ruta, nivel y suposición de contexto para seguir siendo significativa.
La inversa también es importante: si una página de gateway no publica una línea separada de lectura desde caché, esa ausencia no debe convertirse en “la caché no está disponible” ni en “el descuento directo del proveedor se aplica automáticamente”. El gateway puede trasladar una característica ascendente sin desglosarla, exponerla solo en determinadas rutas o facturar la solicitud bajo su tarifa normal de entrada. El enfoque defendible es usar la página de modelo actual del gateway para la planificación y luego confirmar la tarifa real a partir de los registros de uso o datos de facturación. La documentación del proveedor sigue siendo útil para entender el mecanismo, pero por sí sola no establece los términos comerciales de un intermediario.
Where the discount actually matters
El escenario en el que esto cambia significativamente el costo real es un prefijo grande y estático emparejado con una solicitud pequeña y variable: un prompt del sistema o un conjunto de esquemas de herramientas reenviado en cada llamada en un bucle de agente, un documento de referencia largo consultado repetidamente con diferentes preguntas, o historial de conversación reenviado en cada turno de chatbot. Para una carga de trabajo así, la diferencia entre pagar el precio completo de entrada por todo el prefijo cada vez frente a pagar la prima de escritura una vez y la tarifa de lectura con descuento después se multiplica con el volumen de llamadas. No aporta nada a cargas de trabajo que no repiten un prefijo: una solicitud única no tiene contenido en caché que descontar en primer lugar.
Un cálculo práctico de punto de equilibrio compara el costo sin caché del prefijo repetido a lo largo de todas las llamadas con el costo de escritura o almacenamiento de la caché más las lecturas con descuento en las llamadas posteriores. El resultado depende del tamaño del prefijo, el número de aciertos de caché, la caducidad de la caché y si el gateway mantiene las solicitudes en una ruta de proveedor compatible. Si esas condiciones son inestables, el descuento en el titular puede sobrestimar los ahorros realizados en producción.
A simple cost model for a repeated prefix
Sea P el número de tokens del prefijo estable y N el número de llamadas que lo reutilizan. Si U es el precio de entrada sin caché por token, el prefijo cuesta N × P × U sin caché. Una estimación simplificada con caché es P × W + (N − 1) × P × R + S, donde W es el precio de escritura en caché, R es el precio de lectura desde caché y S es cualquier cargo de almacenamiento durante el periodo. La fórmula supone que la primera llamada crea la caché y que cada llamada posterior es un acierto exitoso. Excluye la cola variable de cada solicitud, los tokens de salida, reintentos y cualquier cambio de ruta que cause un fallo.
Considera un prefijo ilustrativo de 100,000 tokens reutilizado en 20 llamadas con la tarifa oficial de GPT-5.6 Terra. A $2.50 por 1 millón de tokens de entrada sin caché, procesar repetidamente ese prefijo costaría $5.00. Usando la tarifa de escritura publicada de 1.25 veces y la tarifa de lectura con un 90% de descuento, una escritura de 100,000 tokens costaría alrededor de $0.3125 y diecinueve lecturas costarían alrededor de $0.475, para un costo combinado del prefijo de aproximadamente $0.7875. La diferencia es de unos $4.21 antes de los costos variables de entrada y salida. Esta es una ilustración, no una cotización: solo se cumple si las diecinueve llamadas posteriores aciertan la misma caché válida y no aplica ningún cargo adicional de almacenamiento o de ruta.
El punto de equilibrio se deduce directamente del mismo modelo. Una prima de escritura se justifica solo cuando se producen suficientes lecturas con descuento antes de la caducidad. Para una carga con sesiones cortas, ediciones frecuentes del prompt o baja afinidad de ruta, la caché puede recrearse más a menudo de lo esperado. Para un bucle de agente de larga duración o un análisis repetido de documentos con un prefijo estable, el número de aciertos puede ser mucho mayor. Por lo tanto, las previsiones deben usar un rango observado de tasa de aciertos en lugar de asumir una secuencia perfecta tras la primera llamada.
Implementation patterns that improve cache reuse
La construcción del prompt tiene un efecto mayor en la tasa de aciertos de lo que muchos presupuestos de precios insinúan. Coloca primero el material más estable y mantén su serialización determinista: las instrucciones del sistema, los esquemas de herramientas, el texto de políticas y el contexto de referencia compartido deben conservar el mismo orden, espacios en blanco y representación de campos a través de llamadas relacionadas. Anexa el contenido volátil después. Evita inyectar marcas de tiempo, identificadores aleatorios, contadores en continuo cambio o resultados de recuperación específicos de la solicitud en el prefijo reutilizable a menos que sean realmente necesarios allí.
Versiona el material estable de forma deliberada. Si cambia un esquema de herramienta o una política, asigna la nueva versión de forma coherente en lugar de permitir que circulen múltiples variantes casi idénticas. Para cargas conversacionales o de agentes, reutiliza un identificador de sesión estable o una clave de caché cuando la API lo admita, y evita cambiar de proveedor dentro de la misma secuencia dependiente de caché. OpenRouter documenta el enrutamiento con afinidad al proveedor para el almacenamiento en caché de prompts y expone controles como session_id y prompt_cache_key; esos controles pueden mejorar la continuidad, pero no garantizan un acierto cuando la caché ascendente está fría o caducada.
Las aplicaciones también deben degradar limpiamente ante un fallo de caché. La caché es una optimización de costo y latencia, no una dependencia de corrección. La solicitud debe seguir produciendo el mismo resultado válido cuando la caché no esté disponible, y la lógica de reintentos no debe crear ciegamente escrituras repetidas. Esa separación hace más seguro comparar rutas: los equipos pueden cambiar la política de caché o la configuración del gateway sin cambiar el comportamiento semántico de la aplicación.
How to verify cache economics in production
Empieza con telemetría por solicitud en lugar de la factura mensual. Registra el identificador exacto del modelo, la ruta del gateway o proveedor cuando se exponga, el nivel de servicio, el total de tokens de entrada, tokens leídos desde caché, tokens escritos en caché, tokens de salida, latencia y costo facturado. El objeto de uso de OpenRouter incluye cached_tokens y cache_write_tokens; otros proveedores exponen detalles equivalentes con nombres de campo diferentes. Conserva los campos de uso en bruto para que un cambio posterior de precios no borre la evidencia necesaria para reconstruir el costo.
Agrega los datos por versión de prompt y por carga de trabajo, no solo por modelo. Entre las medidas útiles se incluyen la proporción de solicitudes elegibles que aciertan caché, la proporción de tokens de entrada facturados a la tarifa de lectura, escrituras por lectura exitosa, tiempo entre la escritura y el último acierto y costo realizado por solicitud. Una alta tasa de aciertos a nivel de solicitud puede aportar poco valor si el prefijo en caché es pequeño, mientras que una tasa de aciertos menor en un prefijo muy grande puede ahorrar más. Combina esas métricas con percentiles de latencia, porque una ruta más barata que falla repetidamente o reencamina puede ser operativamente peor.
Por último, revisa las anomalías en lugar de suavizarlas. Una caída repentina en tokens en caché puede indicar un despliegue de nueva versión de prompt, serialización inestable, entradas caducadas, un límite de nivel de contexto largo o un cambio de ruta del gateway. Compara las solicitudes afectadas con la página de modelo actual y la documentación del proveedor, y luego verifica la tarifa facturada. Esto cierra la brecha entre un descuento publicado y los ahorros que la aplicación realmente obtiene.
What to check before assuming a rate applies
Confirma cinco elementos antes de usar una tarifa publicada en un presupuesto: el modelo y el nivel de servicio exactos, el prefijo mínimo reutilizable o los puntos de corte explícitos de caché, el cargo de primera escritura o de almacenamiento, la vida útil de la caché y evidencia de que las solicitudes realmente están aprovechando la caché. OpenAI afirma actualmente una vida mínima de caché de 30 minutos para GPT-5.6, pero esa no es una regla de retención universal. Google publica tarifas diferentes para los niveles Standard, Batch, Flex y Priority. Las puertas de enlace también pueden enrutar entre proveedores o niveles, por lo que la ruta seleccionada importa. La documentación de OpenRouter sobre prompt-caching recomienda revisar campos de uso de la respuesta como cached_tokens y cache_write_tokens. Para cualquier estimación de producción, compara la página de modelo actual con la facturación y los metadatos de uso reales en lugar de confiar únicamente en una etiqueta general de “caching supported”.