El cache decide el precio: prompt caching y el scheme upto de x402

El prompt caching hizo que el precio de una request al LLM dependa de lo que pasó en los cinco minutos anteriores. El scheme de pago dominante de x402 exige un número antes de que empiece el trabajo. Algo tiene que ceder, y la especificación ya dice qué.

Un agente autónomo que paga por llamada necesita un precio. HTTP 402 es una cotización: el server dice lo que quiere, el agente firma por ese monto, el facilitator lo liquida. El modelo funciona perfecto para un recurso de precio fijo — una llamada a una API, un registro de datos, un render.

La inferencia no es un recurso de precio fijo, y el prompt caching es la razón. La misma request, byte por byte, cuesta un número con el prefix frío y aproximadamente un décimo de eso con el prefix caliente. Cuál te toca depende de si otra request tocó el mismo prefix hace poco, de qué modelo la sirvió, y de en qué workspace vive el cache. Nada de eso se sabe en el momento en que se escribe el 402.

Leímos la documentación de pricing y caching de los tres proveedores principales, después las especificaciones de schemes de x402, y verificamos la parte on-chain nosotros mismos. El desajuste es real, hoy se absorbe cobrando de más, y la primitiva que lo arregla está mergeada en el repositorio de x402 desde marzo.

El caching convirtió el precio en función de la historia

Empecemos por los números, porque la magnitud es todo el argumento. La página de pricing de Anthropic lista el prompt caching como tres multiplicadores sobre la tarifa base de input: cache write de 5 minutos a 1.25x, cache write de 1 hora a 2x, y cache read a 0.1x. En Claude Opus 5 el input base es $5/MTok, así que un write de 5 minutos son $6.25/MTok, uno de 1 hora $10/MTok, y un hit $0.50/MTok.

El break-even documentado se sigue directo: con TTL de 5 minutos el caching se paga con una sola lectura (1.25x + 0.1x contra 2x sin cache); con TTL de 1 hora hacen falta dos lecturas (2x + 0.2x contra 3x). La opción de 1 hora no es "mejor caching", es una apuesta sobre el hueco entre requests.

Tres detalles de implementación deciden si algo de eso llega a pasar. La documentación de prompt caching pone el máximo en cuatro breakpoints explícitos por request, con una ventana de lookback de 20 bloques por breakpoint. La vida del cache se mide desde el inicio de la request que escribe o lee la entrada, no desde el final de su respuesta — una generación de cuatro minutos deja cerca de un minuto para que arranque la siguiente. Y una lectura refresca la entrada sin costo adicional, lo que significa que el tráfico continuo mantiene viva indefinidamente una entrada de 5 minutos.

Después está el mínimo. Un prefix más corto que el umbral del modelo simplemente no cachea: sin error, solo cache_creation_input_tokens: 0. Los umbrales no son monótonos entre generaciones:

// Prefix mínimo cacheable, modelos Claude
512 tokens    Opus 5, Fable 5, Fable 5.1, Mythos 5, Mythos 5.1
1024 tokens   Opus 4.8, Sonnet 5, Sonnet 4.6, Sonnet 4.5, Opus 4.1, Opus 4, Sonnet 4
2048 tokens   Opus 4.7, Mythos Preview, Haiku 3.5
4096 tokens   Opus 4.6, Opus 4.5, Haiku 4.5

Un prefix de 3.000 tokens cachea en Opus 5 y en Sonnet 5. El mismo prefix, ruteado a Haiku 4.5, no cachea nada. Nada en la respuesta lo dice salvo un cero.

Los campos de accounting son la otra mitad del contrato. Anthropic reporta cache_creation_input_tokens (escritos), cache_read_input_tokens (recuperados), e input_tokens — definido como los tokens que no se leyeron del cache ni se usaron para crearlo, es decir, todo lo que va después del último breakpoint. Los tres suman el input real. Cualquier código de billing que lea solo input_tokens y lo llame "el input" está subcontando lo que el cache absorbió.

Tres proveedores, tres contratos de cache

Las formas difieren lo suficiente como para que un gateway de routing no pueda tratarlas como una sola feature.

El caching de Anthropic es explícito. Colocas breakpoints cache_control, o usas la colocación automática de nivel superior, y eliges el TTL. La tabla de invalidación conviene memorizarla: las definiciones de tools invalidan los caches de tools, system y messages; activar o desactivar web search o citations, o cambiar el speed setting, invalida system y messages; tool choice, imágenes, parámetros de thinking y el effort setting invalidan messages. El effort es el que sorprende — subir effort a mitad de conversación para obtener una mejor respuesta tira a la basura el historial cacheado que hacía barata esa conversación.

El caching de OpenAI es automático. Según la guía de prompt caching, GPT-5.6 y posteriores requieren 1.024 tokens visibles de input, los tokens cacheados cuestan 0.1x la tarifa de input sin cache, y los cache writes cuestan 1.25x — los mismos dos multiplicadores que cobra Anthropic, llegados de forma independiente. La retención se controla con prompt_cache_options.ttl en GPT-5.6+ (mínimo "30m") y con prompt_cache_retention en modelos anteriores, que acepta "in_memory" o "24h". El reuso se rompe con un cambio de modelo, un cambio en las definiciones de tools o en su orden, un cambio en text.format, un cambio en reasoning.effort, o un evento de compaction.

Los nombres de los campos difieren por endpoint. La Responses API reporta usage.input_tokens_details.cached_tokens y usage.input_tokens_details.cache_write_tokens; Chat Completions reporta los mismos dos bajo usage.prompt_tokens_details. Como llm4agents habla la superficie compatible con OpenAI, ese segundo par es el que todo SDK de agentes que anda dando vueltas ya sabe parsear.

El de Google es implícito por default. La documentación de context caching indica que el caching implícito está activo para todos los modelos Gemini 2.5 y posteriores, con mínimos de 2.048 tokens en Gemini 2.5 Flash y Pro y 4.096 en la línea Gemini 3.x Flash y en Gemini 3.1 Pro Preview. Los totales cacheados aparecen en usage.total_cached_tokens. La Interactions API soporta solo caching implícito — los objetos de cache explícitos no están disponibles ahí.

La misma request a dos precios

Tomemos un agente real: un prefix estable de 30.000 tokens (system prompt, definiciones de tools, documentos recuperados), una cola volátil de 500 tokens, 800 tokens de output, sobre Claude Opus 5.

// Frío — el prefix se escribe al cache
cache_creation_input_tokens: 30000  × $6.25/MTok = $0.1875
input_tokens:                  500  × $5.00/MTok = $0.0025
output_tokens:                 800  × $25.00/MTok = $0.0200
                                                    ─────────
                                                    $0.2100

// Caliente — el prefix se lee del cache
cache_read_input_tokens:     30000  × $0.50/MTok = $0.0150
input_tokens:                  500  × $5.00/MTok = $0.0025
output_tokens:                 800  × $25.00/MTok = $0.0200
                                                    ─────────
                                                    $0.0375

Bytes de request idénticos. Una diferencia de 5.6x en el total, y de 10.9x solo del lado del input. Ahora cotízalo como tiene que hacerlo un endpoint bajo el scheme exact: el server no sabe, al momento de cotizar, cuál de los dos está por hacer, así que cotiza el número frío. A lo largo de mil turnos de un loop caliente, el agente paga $210.00 por un trabajo que costó $37.67.

La falla alternativa es simétrica. Cotiza el número caliente y cada arranque en frío — cada deploy, cada hueco de inactividad más largo que el TTL, cada primera request de la mañana — se sirve por debajo del costo. El gateway o cobra de más sistemáticamente o sangra en los misses. No hay una tercera cotización.

Dónde el routing y el fallback destruyen el cache

Esta es la parte incómoda para cualquiera que venda model routing, nosotros incluidos. Ya argumentamos que una cadena de fallback es la diferencia entre un agente que sobrevive un incidente del proveedor y uno que no. Ese argumento sigue en pie. Lo que no pusimos en precio es que cada salto de fallback es un evento de cache.

Los caches tienen scope por modelo. OpenAI lista el cambio de modelo primero entre las cosas que rompen el reuso, y la clave de cache de Anthropic se deriva de los bytes del prompt renderizado para un modelo específico. Entonces un 429 en el primario que dispara el router hacia el secundario no cambia solo la tarifa por token — convierte lo que habría sido una lectura a 0.1x en una escritura a 1.25x. En el ejemplo de arriba, ese único salto cuesta $0.1725 más que la request a la que reemplaza, y deja la entrada del primario expirando sin que nadie la lea.

Dos detalles adicionales hacen que el routing entre modelos sea peor de lo que parece. Los mínimos de arriba implican que un prefix que cachea en el primario puede fallar silenciosamente en el fallback: 512 tokens en Opus 5 contra 4.096 en Haiku 4.5 es un factor de ocho. Y los conteos de tokens no son portables entre generaciones — la página de pricing de Anthropic señala que Claude 4.7 y modelos posteriores usan un tokenizer más nuevo que produce aproximadamente 30% más tokens para el mismo texto. Los mismos bytes, ruteados a otra familia de modelos, son otra cantidad de la cosa que estás facturando.

La conclusión práctica no es "deja de hacer fallback". Es que una decisión de fallback tomada solo por health y latencia está tomada sobre dos tercios de los inputs. La disponibilidad de prefix caliente pertenece a esa decisión, y el delta de precio pertenece a la respuesta.

x402 cotiza antes del trabajo; el caching pone precio después

La especificación x402 v2 pone un objeto PaymentRequirements en el array accepts de la respuesta 402, con siete campos: scheme, network, amount, asset, payTo, maxTimeoutSeconds, y un extra opcional. No hay un campo de techo separado. amount es "el monto de pago requerido en unidades atómicas del token", declarado antes de que el recurso se ejecute.

Bajo el scheme exact eso es un compromiso duro. La implementación EVM soporta EIP-3009 transferWithAuthorization, Permit2 y delegación ERC-7710, y la especificación es explícita sobre la garantía que hace seguro al scheme: "En todos los casos, el Facilitator no puede modificar el monto ni el destino. Solo sirve como broadcaster de la transacción." Esa propiedad es exactamente la que quieres para un recurso de precio fijo, y exactamente la que no puedes usar para inferencia medida. La autorización firmada lleva un valor fijo; descubrir después de la generación que la request salió más barata te deja con un reembolso fuera de banda y un problema de conciliación.

Cubrimos el camino de settlement con EIP-3009 cuando era el default obvio para pagos de agentes. Sigue siéndolo, para cualquier cosa cuyo precio sea una constante. La inferencia no lo es.

El scheme upto es la primitiva que faltaba

x402 ya tiene la respuesta. El scheme upto existe para "pricing basado en uso donde el costo final es desconocido hasta después del consumo del recurso", y afirma sin rodeos que "el monto efectivamente cobrado se determina al momento del settlement en base al consumo de recursos durante la request".

El mecanismo es una lectura del mismo campo que depende de la fase. En la verificación, amount "representa el máximo monto que el cliente autoriza". En el settlement, "representa el monto efectivo a liquidar, que DEBE ser menor o igual al máximo previamente autorizado". El resource server fija el monto de settlement a partir del consumo medido; el facilitator "DEBE re-verificar la firma del cliente usando el máximo autorizado (permitted.amount), no el requirements.amount del momento del settlement". Settlement de un solo uso, límites temporales explícitos vía validAfter y deadline, y binding del destinatario están todos exigidos.

La implementación EVM es donde la restricción de diseño se vuelve concreta. El documento del scheme EVM usa permitWitnessTransferFrom de Permit2, y dice por qué la alternativa obvia no está disponible: "EIP-3009 (transferWithAuthorization) no está soportado para el scheme upto porque requiere montos exactos al momento de la firma." El amount liquidado es un parámetro independiente en la función settle del proxy, y "DEBE ser <= al máximo autorizado". El witness struct lleva un campo facilitator para control de acceso.

Ese proxy no es un borrador. La especificación nombra x402UptoPermit2Proxy en 0x4020A4f3b7b90ccA423B9fabCc0CE57C6C240002; consultamos Base mainnet directamente y la dirección devuelve 3.142 bytes de bytecode desplegado. El historial del repositorio muestra que el scheme viene manteniéndose desde hace seis meses:

// specs/schemes/upto — historial de commits
2026-03-04  #1074  Add upto payment scheme specification for EVM
2026-03-25  #1773  feat: add upto to typescript sdk
2026-03-31  #1880  fix: evm contract deploys
2026-06-12  #2607  clarify settle-time verification for partial settlements
2026-07-22  #2697  docs(svm): add `upto` SVM scheme specification
2026-08-12  #3094  feat(ts): svm upto paymentflow
2026-09-03  #3346  feat(ts): delegated receiver authorizer for SVM upto
2026-09-09  #3431  fix(svm): split upto delegated-auth store errors

El costo de adoptarlo es honesto y conviene decirlo: Permit2 necesita una aprobación previa. La especificación lista tres formas de conseguirla — una transacción approve(Permit2) on-chain estándar, una aprobación ERC-20 patrocinada, o un permit EIP-2612 donde el token lo soporte. El atractivo de EIP-3009 era que una wallet nueva podía pagar en su primera request sin transacción de setup. Con upto, ese setup se mueve al momento del registro. Para un agente que va a hacer miles de llamadas medidas, eso es un costo único contra un sobrecobro estructural en cada una de ellas.

Lo que el recibo no dice

El settlement reporta de vuelta. El SettleResponse de v2 lleva success, transaction, network, los opcionales errorReason y payer, un objeto extensions, y un amount opcional — "el monto efectivamente liquidado en unidades atómicas". Así que la cadena registra cuánto se cobró.

Nada estándar registra por qué. La extensión offer-and-receipt agrega ofertas y recibos firmados por el server para evidencia en disputas y auditabilidad, entregados en el body de la respuesta exitosa en extensions["offer-receipt"].info.receipt. Su payload de recibo es version, network, resourceUrl, payer, issuedAt, y un transaction opcional. La extensión es explícitamente "privacy-minimal por default" y "omite intencionalmente las referencias de transacción para reducir el riesgo de correlación". No hay ningún detalle de uso ni de medición ahí.

Para una llamada de inferencia medida eso es un hueco. El agente puede verificar que pagó un monto, y que el monto estaba dentro de lo que autorizó. No puede verificar que el monto se corresponde con la contabilidad de tokens que reportó el proveedor — que los 30.000 tokens facturados como cache reads fueron efectivamente lecturas, o que el salto de fallback que convirtió una lectura en una escritura realmente ocurrió. Hoy el único contraste es el objeto usage en el body de la respuesta, firmado por nada.

El otro eje del mismo problema es el batching. Los dos proveedores principales ponen el trabajo asincrónico a mitad de precio: la Message Batches API de Anthropic es un descuento del 50% en input y output, con la mayoría de los batches terminando en menos de una hora y una expiración dura a las 24 horas; la Batch API de OpenAI es el mismo 50%, con ventana de completado 24h, hasta 50.000 requests y 200 MB por batch. Los multiplicadores de caching de Anthropic se apilan con el descuento de batch — con una salvedad que conviene conocer: el pre-warming de cache con max_tokens: 0 se rechaza dentro de un batch, porque una entrada efímera escrita durante el procesamiento del batch probablemente expiraría antes de que corra la request siguiente. Un carril de batch es un segundo precio para el mismo trabajo, y es un precio que solo se puede liquidar después de que el batch vuelve.

Qué significa para LLM4Agents

Nosotros somos la parte que tiene el cache. El workspace es nuestro, el layout del prefix es nuestro, la decisión de routing es nuestra. Eso convierte al hit rate en un resultado de diseño del gateway, no en una propiedad del prompt del cliente — y convierte al precio de una llamada en algo que descubrimos durante la llamada.

Nuestra contabilidad interna ya tiene la forma correcta. El camino reserve-proxy-settle retiene un máximo contra el balance del agente, proxea la request, y después liquida el monto medido. Eso es semántica upto implementada off-chain contra nuestro propio ledger. Mover la misma forma al cable de x402 no es un rediseño; es hacer verificable desde afuera una garantía interna.

La amenaza es más filosa que la oportunidad. Si seguimos cotizando exact en el peor caso, estamos sobrecobrando estructuralmente justo al tráfico que más queremos: el loop de agente de larga duración con prefix caliente. Cualquier competidor que corra infraestructura idéntica y liquide sobre consumo medido nos deja abajo con el mismo hardware, y puede probarlo on-chain. La economía de flotas que publicamos asumía que el costo de inferencia era el piso; el caching movió el piso y dejó la cotización donde estaba.

El routing es donde se cruzan los dos problemas. El fallback es nuestra historia de confiabilidad y nuestro mayor evento de costo no controlado, y hoy un agente no tiene forma de ver que su request barata se volvió cara porque un proveedor devolvió un 429.

Cómo mantenerse en la frontera

1. Exponer la contabilidad de cache en la respuesta compatible con OpenAI. Normalizar cache_read_input_tokens / cache_creation_input_tokens de Anthropic, cached_tokens / cache_write_tokens de OpenAI, y total_cached_tokens de Google en usage.prompt_tokens_details.cached_tokens y cache_write_tokens en cada llamada. Es el campo que los SDKs de agentes ya parsean, y es la precondición de todo lo que sigue — un agente que no puede ver su hit rate no puede optimizarlo ni disputarlo.

2. Cotizar las rutas de inferencia con upto, dejar exact para las de precio fijo. El techo es el precio de cache frío; el settlement es el medido. Hacer la aprobación de Permit2 en el registro del agente para que la primera llamada paga nunca quede bloqueada por una transacción de setup, y mantener exact en endpoints cuyo precio sea genuinamente constante — no hay razón para pagar la complejidad de Permit2 en esos.

3. Hacer la cadena de fallback consciente del cache. Ordenar candidatos por disponibilidad de prefix caliente además de health y latencia, y chequear el prefix mínimo cacheable del candidato antes de rutear un prompt corto a un modelo que se va a negar silenciosamente a cachearlo. Cuando el salto igual ocurre, reportar el delta de precio en la respuesta en vez de absorberlo en una tarifa promediada.

4. Publicar el contrato de prefix. Congelar el bloque de system, serializar las definiciones de tools de forma determinista, y empujar los identificadores y timestamps por request después del último breakpoint — y después documentar ese layout para que los clientes construyan contra él. El límite de cuatro breakpoints y el lookback de 20 bloques son restricciones reales sobre cuántos niveles de estabilidad puede tener un prompt; los clientes que diseñen a ciegas los van a exceder.

5. Lanzar un carril de batch. Mitad de precio en ambas direcciones para corridas de evaluación, clasificación masiva y trabajo nocturno, liquidado después de que el batch vuelve — lo que exige tener upto en pie primero, y tratar la expiración a las 24 horas como un modo de falla real y no como un timeout.

6. Empujar para que haya detalle de uso en el recibo. La extensión offer-and-receipt es privacy-minimal por diseño, y eso es defendible para una compra única. La inferencia medida necesita un bloque de uso firmado y opcional junto al monto liquidado — conteos de tokens por categoría, modelo que sirvió, disposición del cache — para que un agente pueda conciliar el cargo contra el trabajo en vez de confiar en el número. Ese es el campo que vale la pena proponer, y es contiguo al trabajo de auth-capture que ya está en la especificación.