Reserve, proxy, settle: cómo facturamos cada llamada sin sorpresas

Una llamada LLM es el único producto cuyo medidor se detiene cuando se detiene la respuesta. El costo del input se conoce en el momento en que llega el request; el costo del output depende de cuántos tokens decida generar el modelo. Facturar eso con honestidad — sobre un balance prepago que nunca puede quedar negativo, para agentes que nadie está mirando — requiere exactamente tres movimientos: reservar el peor caso, hacer proxy de la llamada, settlear la verdad. El post de fallback chains nombró este patrón en un párrafo. Este post es el tour interno completo.

El problema suena administrativo y en realidad es arquitectónico. Un API postpago te factura a fin de mes y absorbe el riesgo de que tu agente entre en loop; la factura sorpresa es el modelo de negocio. Un API prepago tiene la restricción opuesta: debe decidir si puedes pagar una llamada antes de saber cuánto cuesta. La mayoría de las plataformas medidas lo resuelven igual que un hotel — una retención de autorización al check-in, el cargo real al check-out. La ingeniería interesante es todo lo que pasa entre esos dos momentos cuando lo que se mide es un stream de tokens atravesando un proxy.

La forma del flujo

Cada llamada facturada en el gateway — /v1/chat/completions y las tools del MCP por igual — pasa por las mismas tres fases:

client                    gateway                     provider
  |                          |                           |
  |--- POST /v1/chat ------->|                           |
  |                          | 1. RESERVE peor caso      |
  |                          |    balance -= R           |
  |                          |--- forward request ------>|
  |                          |                           |
  |<====== stream chunks ====|<====== stream chunks =====|
  |                          |    último chunk: usage    |
  |                          | 2. PROXY completo         |
  |                          |                           |
  |                          | 3. SETTLE costo real C    |
  |                          |    balance += (R - C)     |
  |<-- chunk final + usage --|                           |
  |    (log: /api/v1/transactions)                       |

Reserve, proxy, settle. Cada fase tiene un trabajo y un modo de falla, y el objetivo de diseño en las tres es el mismo: el número que tu agente ve en su balance es siempre un número en el que puede confiar.

Fase 1 — la reserva

Antes de que el request salga del gateway, se calcula el costo de peor caso y se retiene contra tu balance:

// Peor caso: se genera cada token de output solicitado
reserve = input_tokens x input_price
        + max_tokens   x output_price

Los tokens de input se estiman desde el payload del request antes de reenviarlo; el conteo exacto se ajusta en el settlement con el reporte de usage del propio provider. El output es la parte incognoscible, así que la reserva asume que el modelo usa todo lo que pediste.

Ejemplo con los mismos anchors del post de chains. Una llamada a Claude Fable 5 a $10 input / $50 output por millón de tokens, con 3,000 tokens de input y max_tokens: 4000:

// Reserva
3,000 x $10/1M  = $0.03
4,000 x $50/1M  = $0.20
                  ─────
reserve         = $0.23   // 23 centavos retenidos

// El modelo responde en 800 tokens. Settle:
3,000 x $10/1M  = $0.03
  800 x $50/1M  = $0.04
                  ─────
settled         = $0.07   // 7 centavos cobrados, 16 reembolsados

Dos consecuencias operativas salen de la fórmula. Primera, max_tokens es tu perilla de reserva. Omítelo y el gateway debe asumir el output máximo del modelo — para un modelo frontier eso puede ser decenas de miles de tokens, lo que convierte una llamada de siete centavos en una retención de varios dólares. Los agentes que fijan un max_tokens ajustado y realista obtienen más concurrencia del mismo balance. Segunda, si la reserva excede tu balance, la llamada se rechaza antes de que un solo byte llegue al provider. El error es inmediato, local y gratis — que es exactamente donde quieres que viva un chequeo de solvencia.

Para un fallback chain, la reserva se calcula una sola vez, contra el modelo más caro del array. models: [gpt-5-mini, sonnet-4.6, fable-5] reserva a precios de Fable 5 aunque el 92-97% de las llamadas settlee a precios de gpt-5-mini. Esa asimetría es deliberada: cualquier eslabón del chain podría terminar respondiendo, así que la retención cubre la posibilidad más cara y el reembolso maneja el caso común. El post de economics de flotas llamó al float resultante un ejercicio de gestión de balance y no un costo, y esta matemática es la razón — el delta siempre vuelve.

Fase 2 — el proxy

La fase de proxy tiene una restricción dura: el streaming no puede pagar un impuesto de facturación. Los chunks se reenvían al cliente a medida que llegan del provider — sin buffering, sin demora de inspección, con el time-to-first-token idéntico a llamar al provider directo.

El detalle está en dónde vive el usage dentro de un stream. Bajo el protocolo de streaming de OpenAI, los conteos de tokens llegan en un solo lugar: un chunk final extra, enviado después de que el contenido terminó. Según la referencia de streaming de OpenAI, cuando se envía stream_options: {"include_usage": true}, el campo usage es null en todos los chunks excepto el último, y el último chunk trae las estadísticas completas del request con un array choices vacío. Los agregadores upstream se comportan igual — OpenRouter documenta que el usage, incluido su campo inline usage.cost, llega "en el último mensaje SSE" de una respuesta en streaming.

Así que el gateway siempre pide usage al upstream, lo haya pedido tu cliente o no, y parsea ese chunk final cuando el stream se cierra. Todo lo que el settlement necesita — tokens exactos de input, tokens exactos de output, qué modelo respondió realmente — viaja en el último mensaje de la misma conexión que trajo tu respuesta. Sin segunda llamada al API, sin polling, sin estimaciones.

Esto también explica un detalle que los operadores atentos notan: dónde vive el reporte de costo depende de si hiciste streaming. Los headers HTTP se envían antes que el body. En una llamada sin streaming el gateway conoce el costo settleado antes de escribir la respuesta, así que X-Cost-Usd-Cents y X-Balance-Remaining-Cents traen los números reales. En una llamada con streaming los headers salieron del edificio antes de que el medidor se detuviera — el costo settleado aterriza en el bloque de usage del chunk final y, de forma durable, en el log de transacciones en /api/v1/transactions. Si tu tracing solo lee headers, las llamadas en streaming van a parecer gratis. No lo son; la fila está en el log.

Fase 3 — el settle

El settlement es una sola operación atómica de ledger: cobrar el costo real, liberar el resto de la retención, escribir la fila.

// Una transacción, una fila
{
  request_id:  "req_01J8Q9...",
  model_used:  "openai/gpt-5-mini",
  reserved_usd_cents:  23.0,
  settled_usd_cents:    0.4,
  refunded_usd_cents:  22.6,
  usage: { input: 3011, output: 792 }
}

La atomicidad es todo el punto. No hay ventana donde el cargo aterrizó pero el reembolso no, ni camino donde un crash entre dos escrituras deje tu balance corto. O la llamada settleó completa o la reserva se libera completa. Y como las retenciones son peligrosas si pueden filtrarse — un bug del gateway que reserve y nunca settlee iría bloqueando lentamente el balance de todos los clientes — cada reserva lleva una expiración dura. Una retención que nunca se settlea vuelve al balance por sí sola. El modo de falla de un bug de facturación en esta plataforma es un reembolso demorado, no un balance perdido.

El balance que muestra tu dashboard es available = balance - active_reserves. Durante una ráfaga de llamadas concurrentes el número disponible baja por la suma de los peores casos pendientes y se recupera a medida que cada llamada settlea. Esa caída no es gasto; mirarla respirar es la forma más rápida de construir intuición sobre lo que cuesta flotar la concurrencia de tu flota.

Lo que el patrón compra

Los fallback chains viajan gratis. Un intento fallido dentro de un chain — un 429 en el primario, un 5xx, un rechazo de moderación en Fable 5 que reenruta al siguiente eslabón — nunca se cobra. Solo settlea el modelo que produjo una respuesta usable; X-Model-Used te dice cuál fue. La reserva ya estaba dimensionada para el eslabón más caro, así que un fallback disparándose no cambia nada sobre la solvencia en pleno vuelo. Confiabilidad sin impuesto de facturación no es un eslogan; es una propiedad de reservar una vez y settlear una vez.

La cotización x402 walk-up es la reserva hecha pública. Cuando un agente sin cuenta llama al gateway, la respuesta HTTP 402 cotiza un precio — y ese precio es la misma fórmula de peor caso, denominada en USDC. El agente firma un transferWithAuthorization de EIP-3009 por el monto cotizado: un mensaje que ata from, to, value, una ventana validAfter/validBefore y un nonce aleatorio de 32 bytes que el contrato del token marca como consumido, de modo que la autorización puede settlearse exactamente una vez. Una diferencia importa: el scheme exact de x402 settlea un monto fijo on-chain, y una autorización firmada no tiene camino de reembolso de delta. Los callers walk-up deberían por eso fijar max_tokens ajustado — en modo walk-up la reserva no es una retención, es el precio. La reserva reembolsable del modo Bearer es mejor negocio para presupuestos de tokens generosos; el deep dive de x402 cubre el resto del trade.

Un solo medidor para tokens y acciones. El MCP server factura sus 67 tools a través del mismo ledger reserve-settle, así que un agente que razona en el gateway y actúa a través de las tools acumula un costo por tarea coherente — el número que el post de economics de flotas argumentó que todo operador realmente gestiona.

Los edge cases son el design review

Cualquier esquema de facturación se ve limpio en el happy path. Tres caminos infelices deciden si es honesto.

El stream caído. Tu cliente se desconecta a mitad de generación — un timeout, un proceso crasheado, un usuario cerrando una pestaña. El provider puede seguir generando; el chunk de usage puede no llegarle a nadie si la conexión en la que viaja ya no existe. La respuesta del gateway es que la conexión upstream es suya, no de tu cliente. Cuando el lado del cliente se cae, el gateway sigue leyendo upstream hasta que llega el chunk de usage, y settlea normalmente. Pagas por lo que el provider generó, no por lo que alcanzaste a recibir — y el log de transacciones muestra la fila aunque tu cliente no haya visto nada. Si la pata upstream misma muere antes de que llegue el usage, el gateway settlea de forma conservadora con los tokens que observó y reconcilia después contra la contabilidad por request del propio provider; los agregadores upstream exponen exactamente ese tipo de registro durable de generación para este propósito.

El upstream con rate limit. Un 429 que llega después de la reserva es el camino infeliz más común en producción. Modelo único: la reserva se libera completa, el error se devuelve, costo cero. Chain: el proxy avanza al siguiente eslabón bajo la misma reserva, y el settle eventual cobra solo al eslabón que respondió. En ambos casos la vida de la reserva está acotada por la vida de la llamada — no existe escenario donde una falla del provider retenga tu dinero.

El reroute de moderación a mitad de chain. El caso más sutil: el eslabón primario empieza una respuesta y el provider la mata a mitad de camino por un clasificador de política. Hubo una generación parcial; alguien incurrió en costo. La regla sigue siendo la regla — solo settlea una respuesta usable. El intento matado no se cobra, el chain avanza, y la plataforma absorbe el costo de la generación parcial como el precio de vender confiabilidad. Que las llamadas de inferencia fallidas se acrediten de vuelta es el comportamiento documentado; este es el mecanismo detrás.

Qué significa para LLM4Agents

Reserve-proxy-settle es el muro de carga de la plataforma. Las features que diferencian al gateway de llamar a los providers directo — fallback chains, x402 walk-up, un solo medidor entre tokens y tools, un balance que un agente autónomo puede leer sin un humano revisando facturas — están todas aguas abajo del mismo ledger de tres fases. Una plataforma que facturara postpago no podría servir agentes sin supervisión; una plataforma que estimara en vez de settlear no podría publicar X-Cost-Usd-Cents y decirlo en serio.

El costo honesto del patrón es el float. Reservar el peor caso significa que una flota de alta concurrencia debe estacionar más balance del que va a gastar, y la brecha crece con una disciplina floja de max_tokens y con eslabones terminales caros en los chains. Ese es el punto de presión que un competidor podría atacar con reservas basadas en riesgo — reteniendo menos que el peor caso y absorbiendo sobrecostos ocasionales. Creemos que confiar-en-el-número le gana a minimizar-el-float para agentes autónomos, pero es un trade real y merece ser nombrado.

Cómo mantenerse en la frontera

Cinco movidas, en orden.

Uno — publicar la matemática de la reserva como endpoint. Un modo dry-run que devuelva la reserva de un request sin ejecutarlo. Los agentes que presupuestan una tarea, y los callers walk-up decidiendo si firmar, no deberían tener que reimplementar la fórmula.

Dos — costo inline en el chunk final. OpenRouter entrega usage.cost en el último mensaje SSE; el gateway debería igualarlo, para que los clientes en streaming reciban el precio settleado in-band sin leer el log de transacciones.

Tres — seguir los schemes x402 de monto variable. El settlement fijo del scheme exact es la razón por la que walk-up no tiene reembolso de delta. Si el estándar x402 adopta un scheme que autorice un techo y settlee un monto real, walk-up hereda la economía del modo Bearer de un día para otro. Ser los primeros en soportarlo es barato y diferenciador.

Cuatro — presupuestos de reserva por agente. Un tope de reservas pendientes por agente convierte un loop descontrolado de incidente que drena el balance en uno throttleado. El anti-patrón de loops de tool-calls gana un respaldo a nivel de plataforma.

Cinco — reconciliación continua. Un diff automatizado entre nuestras filas settleadas y los registros de generación upstream, publicado como métrica de exactitud. Las afirmaciones de facturación deberían ser auditables como lo son las de uptime.

Cierre

Facturar después de la respuesta es más difícil de lo que parece porque la respuesta es el precio. Reservar el peor caso para que la respuesta sea siempre pagable; hacer proxy del stream para que la honestidad no cueste latencia; settlear la verdad para que el número del balance sea real. Todo lo demás en esta plataforma — los chains, el modo walk-up, la contabilidad de costo de un solo medidor — se apoya en esos tres movimientos. Si llegaste desde el post de migración preguntándote qué estabas comprando realmente más allá de un cambio de endpoint: es esto.