<!-- Canonical URL: https://ask.atlascloud.ai/es/when-prompt-caching-reduces-coding-agent-costs -->

# ¿Cuándo reduce realmente el prompt caching el coste de un agente de programación?

> El prompt caching reduce costes cuando muchas solicitudes reutilizan un prefijo grande y estable a nivel de bytes, y el ahorro de las lecturas de caché supera la complejidad y los fallos. Mide la entrada almacenada en registros reales en vez de asumir que toda instrucción repetida obtiene descuento.

El prompt caching resulta valioso cuando el agente envía repetidamente el mismo comienzo grande, no solo cuando los prompts parecen similares. Una marca de tiempo, una lista de herramientas reordenada, un resumen variable o un ID generado cerca del inicio puede eliminar la reutilización de todo lo posterior.

Antes de rediseñar prompts, inspecciona los metadatos de uso reales. Determina cuántos tokens son elegibles, cuántos se notifican como lecturas, con qué frecuencia cambia el prefijo y si el modelo y protocolo ofrecen un beneficio.

## Modela la base sin caché

Empieza por el coste de entrada, ya que la caché no reduce la salida ni la ejecución de herramientas.

```text
uncached_input_cost = requests * input_tokens_per_request * input_rate
```

Mantén las tarifas en unidades coherentes, normalmente por millón de tokens. No uses un descuento recordado: consulta el precio actual y los campos de uso del modelo exacto.

| Componente | ¿Estable entre solicitudes? | Posición probable |
|---|---|---|
| Política de sistema | Normalmente | Primero |
| Esquemas de herramientas | Normalmente | Al principio |
| Convenciones del repositorio | A menudo | Al principio |
| Punto de control | A veces | En medio |
| Solicitud del usuario | Rara vez | Al final |
| Salida de herramientas | No | Última |

## Calcula el equilibrio con símbolos

Sea `P` el número de tokens del prefijo, `R` las solicitudes, `W` la tarifa de escritura, `H` la de lectura y `U` la tarifa ordinaria:

```text
uncached = R * P * U
cached = P * W + (R - 1) * P * H
savings = uncached - cached
```

Este caso ideal supone que todas las solicitudes posteriores aciertan. Para una fracción medida `h`, sustituye el término posterior por una mezcla ponderada de `H` y `U`. Añade los tokens fuera del prefijo a tarifa ordinaria en ambos lados.

La caché solo resulta rentable si el ahorro sigue siendo positivo después de fallos y trabajo de ingeniería.

## Coloca primero el contenido estable

Construye de lo estable a lo volátil:

* Instrucciones de sistema y seguridad.
* Definiciones de herramientas en orden determinista.
* Convenciones y referencias duraderas.
* Punto de control compacto.
* Solicitud actual.
* Última salida de herramientas.

Serializa los esquemas de forma determinista. Evita orden aleatorio, cambios de espacios, fechas y comentarios específicos de la solicitud. Versiona los bloques estables para que un cambio real produzca un fallo explicable.

## Mantén el prefijo útil, no solo grande

Un prefijo inflado puede aumentar las lecturas y a la vez elevar tokens y distraer al modelo. Elimina herramientas obsoletas, políticas duplicadas y referencias irrelevantes.

Mide el coste por resultado aceptado, no solo el porcentaje de aciertos. Un prompt corto sin caché que resuelve la tarea en menos turnos puede superar a otro grande y ruidoso.

## Instrumenta solicitudes y resultados

Registra modelo, protocolo, versión del prefijo, tokens totales, tokens almacenados cuando estén disponibles, salida, latencia, llamadas, reintentos y resultado. Marca los campos ausentes como no disponibles, no como cero.

| Métrica | Motivo |
|---|---|
| Porcentaje almacenado | Confirma la reutilización real |
| Motivo del fallo | Detecta cambios accidentales |
| Solicitudes por tarea | Revela bucles que eliminan el ahorro |
| Coste por cambio aceptado | Vincula tokens con trabajo útil |
| Tasa de reintentos | Muestra costes de fiabilidad externos |

Una semana de tareas representativas aporta más que repetir cien veces un prompt sintético.

## Vigila rutas y límites de sesión

La caché puede depender del modelo, proveedor, región, ventana de retención y enrutamiento. Un gateway o fallback puede enviar la solicitud a una ruta sin el mismo prefijo caliente. Trata su rendimiento como una propiedad observada de la ruta elegida.

Atlas Cloud ofrece varios formatos LLM mediante una API, pero su guía pública no promete un descuento universal. Comprueba el modelo y la consola antes de afirmar ahorros. Usa [protocolos LLM](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs) para elegir el formato y el [catálogo](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=when-prompt-caching-reduces-coding-agent-costs) para consultar modelos actuales.

## Evita falsos ahorros

Una entrada más barata puede ocultar turnos adicionales, herramientas fallidas o reconstrucciones repetidas. Distingue también una lectura de caché del almacenamiento o recuperación de la aplicación: resuelven problemas distintos.

No incluyas secretos porque el contenido pueda almacenarse. Cumple los controles de datos y retención; la arquitectura de caché no sustituye el control de acceso.

## Utiliza una puerta de adopción práctica

Adopta esta técnica cuando:

* El prefijo estable es útil y se reutiliza con frecuencia.
* El uso real notifica lecturas de caché.
* El ahorro sobrevive a la tasa de fallos observada.
* El versionado es sencillo y determinista.
* La calidad y los turnos no empeoran.

De lo contrario, reduce primero el prompt, recupera solo archivos relevantes y acorta el bucle.

## Conclusión

El prompt caching reduce costes cuando un prefijo grande, útil y estable se reutiliza suficientes veces en una ruta que cobra menos por la entrada almacenada. Coloca lo estable primero, calcula el equilibrio con tarifas actuales, instrumenta tareas reales y mide el coste por cambio aceptado. Una tasa alta no sirve si el prompt es innecesariamente grande o exige más turnos.

## FAQ

### ¿Qué contenido es más adecuado para el prompt caching?

Las instrucciones de sistema estables, esquemas de herramientas, convenciones del repositorio y referencias que cambian poco son mejores que logs en vivo o el mensaje más reciente.

### ¿Por qué debe ir el contenido variable después del prefijo estable?

Las cachés de prefijo suelen depender de un inicio idéntico. Una marca de tiempo, un ID o contexto cambiante al principio puede convertir todo lo posterior en un fallo.

### ¿El prompt caching siempre reduce la latencia?

No. Depende de la implementación, estado de caché, ruta, modelo, tamaño y carga. Mide la latencia por separado del coste.

### ¿Cómo calculo el punto de equilibrio?

Compara el coste de entrada normal con el de escritura y lectura de caché para la reutilización prevista, incluyendo el coste de ingeniería y la tasa de fallos.

### ¿Se pueden almacenar en caché las definiciones de herramientas?

Pueden formar parte de un prefijo repetido si el proveedor y el protocolo las incluyen. Comprueba los metadatos de uso en vez de asumirlo.

### ¿Debo almacenar toda la conversación de programación?

Normalmente no. Cambia en cada turno. Coloca primero instrucciones y esquemas estables y añade después un punto de control compacto y la solicitud actual.
