Una sola sesión agéntica puede costarte 99.26 dólares y consumir 78.2 millones de tokens si dejas un loop sin freno. La buena noticia: existen tres cerrojos concretos para que eso no te pase, y todos viven en la API. Hablamos de prompt caching, caps de gasto y Message Batches, las tres palancas que reducen el costo por tarea completada cuando trabajas con Fable 5 [0:00].

¿Cómo funciona el prompt caching y cuándo conviene activarlo?

El sistema guarda un prefijo de tu prompt y, en los requests siguientes, te cobra solo 0.1x por leerlo en lugar de 1x por procesarlo completo. Es la respuesta directa a la pregunta de cómo reducir el costo cuando el mismo prefijo se repite en cada llamada [0:43].

El detalle clave está en el mínimo de tokens necesarios para crear la entrada de caché. En Fable 5 bajó a 512 tokens en API directa, Vertex AI, Claude Platform on AWS y Microsoft Foundry. En Amazon Bedrock se mantiene en 1024 [1:01].

¿Qué pasa si mi prefijo no llega al mínimo? No verás un error. Simplemente cache_creation_input_tokens vuelve en cero y pagas precio completo sin saberlo [1:14].

¿Cuándo el caché se paga solo?

Más rápido de lo que crees. Con el TTL de cinco minutos, un cache write cuesta 1.25x y un read cuesta 0.1x. Dos requests totalizan 1.35x contra 2x sin caché: ganaste desde el segundo request [1:27].

Con el TTL de una hora, el write sube a 2x, así que necesitas tres requests para salir adelante. Pero recuerda algo incómodo: un cache miss en Fable 5 cuesta el doble en dólares absolutos que en Opus 4.8 [1:51].

Cualquier cambio de un solo byte antes de tu breakpoint invalida toda la caché y convierte reads en writes. Después de cada deploy que toque el prompt, verifica cache_read_input_tokens para confirmar que la caché sigue caliente [1:58].

¿Cómo estructurar el prompt para maximizar hits de caché?

El cache matching es strict prefix match: todo antes de tu breakpoint debe ser byte por byte idéntico entre requests [2:13]. La estructura óptima tiene dos capas claras.

• Contenido estable: system prompt, reglas de negocio y definiciones de herramientas con sus JSON schemas. Va al inicio y se marca con cache_control type ephemeral.
• Contenido variable: el mensaje del usuario, datos de sesión y lo que cambia por request. Va fuera del prefijo cacheado.
• Definiciones de herramientas como candidatas ideales: un schema de get_expenses luce idéntico en el request uno y en el cincuenta.

Un benchmark documentado con 75 herramientas mostró que el caching cortó los input tokens facturados en 38% sin cambio en accuracy [3:02].

¿Qué rompe mi caché sin warning? Reordenar tools, agregar una nueva antes de las existentes o modificar una flag en el system prompt. Cualquiera invalida todo lo que viene después [3:08].

¿Qué caps de gasto debo configurar para un agente sin techo?

Cuando un agente itera libremente, el caché no basta. Necesitas cuatro capas que funcionan como un edificio de seguridad [3:19].

Capas de control de gasto en trabajo agéntico

1. max_tokens: hard cap por request individual. Si el modelo lo alcanza, el output se trunca. El modelo no ve este límite. Punto de partida para trabajo agéntico: 64,000 tokens [3:33].
2. task_budget dentro de output_config: esto sí lo ve el modelo. Funciona como un countdown a lo largo de toda la sesión, como un presupuesto total para el proyecto en vez de un límite por factura. Mínimo 20,000 tokens y requiere el beta header task-budgets-2026-03-13 [3:52].
3. Effort por ruta: low para subagentes de alto volumen, high como default y xhigh para implementación crítica. El spread va de 10 a 72 centavos sobre la misma tarea [4:24].
4. Session tracking propio: tu código sumando thinking_tokens por sesión con alertas cuando el presupuesto se excede. Ningún mecanismo built-in te avisa que una sesión se está poniendo cara [4:38].

Esa instrumentación es exactamente lo que habría flaggeado la sesión de 99 dólares antes de que terminara [4:49].

¿Cuándo usar Message Batches para pagar la mitad?

La Message Batches API corta el precio de Fable 5 a la mitad: input de 5 dólares por millón, output de 25 [5:00]. Se acumula con el caché, así que el ahorro se compone.

El tradeoff es latencia: los resultados no llegan al instante. Encaja bien en clasificar miles de tickets overnight, runs de evaluación fuera de horario y búsqueda agéntica donde muchos items comparten contexto. No encaja en chat en tiempo real ni en flujos donde el paso dos depende del paso uno [5:11].

¿Por qué medir costo por tarea completada en vez de precio por token?

La métrica que une todo es costo por tarea completada: costo por intento dividido por tasa de éxito. Si Fable 5 cuesta 4.50 dólares por intento con 80% de success rate, son 5.63 por tarea. Si un modelo más barato cuesta 1.50 con 54% de éxito, da 1.85 [5:32].

Pero si cada fallo requiere supervisión humana, el gap se invierte. Mide esto sobre tu propio tráfico en un canary, no sobre benchmarks genéricos. Y si tu tasa de refusal es alta en una ruta, pinear Opus directamente puede ser más barato que pagar el round trip del intento declinado más el fallback [6:02].

¿Tienes session tracking y caps de gasto activos en tu stack hoy? Cuéntame en los comentarios cómo lo resolviste y qué métrica usas para detectar sesiones caras antes de que cierren.