¿Bearer o x402 walk-up? Un árbol de decisión para operadores

El mismo POST a /v1/chat/completions puede producir dos facturas distintas. Con un header Authorization: Bearer debita un balance prepago que fondeaste la semana pasada. Con un header X-PAYMENT liquida una autorización USDC firmada desde una wallet que el gateway nunca había visto. Los precios de lista walk-up corren 10 por ciento por debajo de Bearer. Y sin embargo la elección entre ambos casi nunca es una decisión de precio — es una decisión de modelo de negocio sobre quién paga la llamada.

Cada superficie paga de la plataforma acepta ambos modos: el gateway OpenAI-compatible y casi todas las 67 tools del MCP. Esa simetría es deliberada, y produce una bifurcación real para el operador. Este post es el árbol de decisión — qué es realmente cada modo, dónde engaña el 10 por ciento, y el patrón mixto al que la mayoría de los operadores termina llegando.

Bearer: el modo del operador

Bearer es la experiencia de desarrollo que ya conoces. Registras un agente, depositas USDC o USDT en Polygon o Solana, y obtienes una API key. Cada llamada lleva Authorization: Bearer y debita el balance:

$ curl https://api.llm4agents.com/v1/chat/completions \
    -H "Authorization: Bearer $LLM4A_KEY" \
    -d '{
      "model": "anthropic/claude-fable-5",
      "max_tokens": 1000,
      "messages": [{"role": "user", "content": "..."}]
    }'

// Headers de respuesta:
X-Cost-Usd-Cents: 7.0
X-Balance-Remaining-Cents: 4923.5

Por debajo, Bearer corre el ledger reserve-proxy-settle: el gateway retiene el costo de peor caso antes de que salga el request, reenvía el stream sin tocarlo, y después liquida el costo real y reembolsa la diferencia. Las propiedades que caen de ese patrón definen el modo. Pagas por uso real, nunca por el techo. Los intentos fallidos de fallback no cuestan nada, así que las chains son económicamente gratis. Cada llamada queda como una fila en /api/v1/transactions, así que una flota tiene un solo ledger y un solo número que conciliar. Y el free tier de 60 requests por minuto del servidor MCP solo existe en este modo, porque un free tier necesita una cuenta a la cual atarse.

Bearer encaja con una forma de negocio: tú operas los agentes, y la inferencia es tu costo de venta. Si vendes un producto SaaS a $80 al mes por cliente y tus agentes queman tokens sirviéndolos — el modelo de nuestro post de economía de flotas — quieres costos agrupados, reembolsos automáticos y un ledger con forma de factura única. Tus clientes nunca ven el medidor. Tú sí, en un solo lugar.

x402 walk-up: el modo del desconocido

Walk-up invierte todos los supuestos. No hay cuenta, ni key, ni depósito, ni relación. Un agente llama al endpoint en frío, recibe HTTP 402 con una cotización, firma una autorización en stablecoin por ese monto exacto, y reintenta. El pago es la credencial:

// 1. Llamada en frío → 402 con la cotización (decodificada):
{
  "x402Version": 2,
  "accepts": [{
    "scheme": "exact",
    "network": "eip155:8453",       // Base mainnet
    "amount": "9000",                // $0.009 en unidades USDC de 6 decimales
    "payTo": "0x0D74...8C12",
    "maxTimeoutSeconds": 300
  }]
}

// 2. Firmar EIP-3009 transferWithAuthorization, reintentar con X-PAYMENT.
// O dejar que el SDK haga todo el baile:
const completion = await client.chat.completions.create({
  model: 'anthropic/claude-fable-5',
  max_tokens: 1000,
  messages: [{ role: 'user', content: '...' }],
  paymentMode: 'x402',      // pago por llamada, sin balance, sin cuenta
});

Lo que el agente firma es un EIP-3009 transferWithAuthorization: un mensaje tipado EIP-712 que ata from, to, value, una ventana validAfter/validBefore, y un nonce aleatorio de 32 bytes que el contrato del token marca como consumido — una autorización, una liquidación, para siempre. Los nonces aleatorios son el detalle que importa para agentes: a diferencia de los nonces secuenciales de transacción, una wallet puede tener docenas de autorizaciones en vuelo concurrentes sin colisiones. El recorrido completo del protocolo está en nuestro deep dive de x402.

Walk-up encaja con la forma opuesta de negocio: el caller paga por el uso del caller. Un agente de terceros que consume tu endpoint una vez y desaparece. Un proceso de research de un solo disparo que no debería heredar la API key de nadie. Un agente que recorre infraestructura donde no tiene cuenta. Facturación per-use donde cada request lleva su propio recibo, liquidado on-chain, final.

El 10 por ciento no es la decisión

Los precios walk-up están 10 por ciento por debajo de Bearer en todo el catálogo: una tool de 1¢ cuesta 0.9¢, el 0.1¢ de ai_embed se vuelve 0.09¢. El descuento premia la liquidación inmediata y final — sin maquinaria de reembolsos, sin ledger que mantener, sin riesgo de cuenta. Para las tools del MCP, cuyos precios son planos por llamada, el descuento es exactamente lo que parece. Tómalo.

Para inferencia LLM, la aritmética es más tramposa, y viene de una asimetría: Bearer liquida el uso real; walk-up liquida la cotización. El esquema exact de x402 transfiere un monto fijo sin camino de refund por delta, así que el precio walk-up debe ser el peor caso — la misma fórmula de reserva que Bearer usa como retención temporal, hecha permanente. El post de billing internals trabajó este ejemplo: 3,000 tokens de input contra Claude Fable 5 a $10 input / $50 output por millón. Córrelo en ambos modos:

// Misma llamada, max_tokens: 4000, el modelo responde en 800 tokens
Bearer:   reserva 23.0¢ → liquida 7.0¢, reembolsa 16.0¢  →  pagaste  7.0¢
Walk-up:  cotización = 23.0¢ x 0.90                       →  pagaste 20.7¢

// Misma llamada, max_tokens: 1000
Bearer:   reserva  8.0¢ → liquida 7.0¢, reembolsa  1.0¢  →  pagaste  7.0¢
Walk-up:  cotización =  8.0¢ x 0.90                       →  pagaste  7.2¢

Con un presupuesto de tokens descuidado, walk-up cuesta tres veces Bearer a pesar del descuento. Con uno ajustado, los modos convergen a casi paridad. La regla se comprime en una frase: el 10 por ciento va para quien fija max_tokens con honestidad, y el premium de peor caso se le cobra a quien no. Las tools son inmunes porque sus precios son planos; la inferencia es donde se le pone precio a la disciplina.

El árbol de decisión

Recorre las preguntas de arriba hacia abajo; la primera columna que siga coincidiendo es tu modo.

Pregunta                       Bearer                        x402 walk-up
¿Quién financia la llamada?    Tú — balance del operador     La wallet del caller
Relación con el gateway        Cuenta + API key              Ninguna — el pago es la credencial
Modelo de facturación          Suscripción SaaS; COGS        Per-use; cada llamada se liquida sola
Liquidación de inferencia      Uso real, delta reembolsado   Cotización, final, sin refund
Precio de tools MCP            Lista (1¢ ...)                10% bajo lista (0.9¢ ...)
Free tier                      60 req/min en MCP             Ninguno
Latencia en frío               Un round trip                 +1 round trip + verificación on-chain
Artefacto contable             Una fila de ledger por call   Un recibo on-chain por call
Fallback chains                Económicamente gratis         Cotizadas al peor link, sin refund
Cobertura                      Todo                          Todo menos web_crawl, pdf_parse,
                                                             doc_extract (solo balance)

Tres filas merecen nota. Latencia: un walk-up en frío agrega un round trip de 402 más la verificación del facilitator — ruido en una completion de 500ms, material en una tool call de 30ms, y por eso las llamadas cortas de alta frecuencia pertenecen a Bearer. Chains: una fallback chain reserva a su link más caro; en Bearer el reembolso devuelve la diferencia cuando responde un link barato, en walk-up el precio del peor link es lo que firmaste. Hoy las chains solo tienen sentido económico en Bearer. Compliance: Bearer le da al operador de flota un solo ledger conciliable; walk-up le da a cada transacción un recibo on-chain independiente — cuál de los dos prefiere tu contador depende enteramente de si el gasto es tuyo o de tus callers.

Modo mixto: el patrón al que convergen los operadores

Los modos no son excluyentes, y la configuración más durable usa ambos — divididos según de quién es el dinero que se mueve.

El tráfico propio de tu producto corre en Bearer. Los agentes que tú operas, sirviendo a clientes que te pagan mensualmente, giran contra un balance agrupado con reembolsos, chains, el free tier y un solo log de transacciones. Eso es inferencia como COGS, y Bearer es simplemente el mejor ledger para eso.

Tu superficie pública cotiza x402. En el momento en que expones algo para que lo consuman terceros — un pipeline de research, un endpoint de datos, un agente especialista que otro agente podría contratar — walk-up significa que los desconocidos pagan lo suyo con cero onboarding. No emites keys a agentes desconocidos, no mides sus cuotas, no persigues sus facturas. La cotización 402 es la lista de precios, la autorización firmada es el pago, y el recibo de liquidación es el contrato. Nuestro post de x402 llamó a esto comercio agent-to-agent; el modo mixto es cómo se ve desde la silla del vendedor.

Hay un tercer actor cuyo dinero puede moverse: el de tu usuario final. Cuando un agente compra en nombre de un humano — el agente paga, pero el mandato de gastar vino de otra persona — el rail de pago solo no responde la pregunta que importa, que es si el humano autorizó esta compra. Para eso existe AP2: el protocolo de pagos de agentes de Google envuelve la transacción en mandates firmados, credenciales verificables que registran lo que el usuario permitió, ahora avanzando por working groups de FIDO hacia la estandarización. AP2 trata a x402 como un método de liquidación entre varios, así que el stack compone limpio: el mandate prueba la autoridad, la autorización x402 mueve el dinero. Si tus agentes gastan fondos de usuarios, walk-up más un rastro de mandates es la configuración defendible — nuestro post de AP2 cubre la mecánica de los mandates en profundidad.

Qué significa para LLM4Agents

El modo dual es la cuña de la plataforma, y vale la pena ser explícito sobre por qué. Las plataformas puramente Bearer — efectivamente todo vendor de API tradicional — compiten en experiencia de desarrollo y le cierran la puerta a los callers anónimos. Los endpoints puramente x402 compiten en apertura y renuncian al ledger reembolsable que los operadores de flotas realmente necesitan. Servir ambos modos a través de un solo medidor significa que un operador puede empezar en Bearer el día uno, exponer una superficie x402 el día que llega su primer caller de terceros, y nunca migrar de plataforma para hacerlo. La aritmética de la economía de flotas también depende silenciosamente de esto: los modelos de margen de ese post asumen reservas reembolsadas y balances agrupados, y los modelos de ingreso asumen que los desconocidos pueden pagar por llamada. Una plataforma que sostiene ambos lados de esa hoja de cálculo es el producto.

La exposición honesta es el premium de peor caso en inferencia walk-up. Hoy es defendible — el esquema exact físicamente no puede reembolsar un delta. Pero cualquier competidor que lance primero la liquidación de monto variable borra la mayor debilidad de walk-up de la noche a la mañana y se lleva el mercado per-use con ella. Ese riesgo ahora tiene nombre y spec.

Cómo mantenerse en la frontera

Cuatro movimientos, en orden.

Uno — implementar el esquema upto. El spec de x402 ahora incluye upto: el cliente autoriza un máximo, el servidor liquida el monto real igual o menor, cada autorización se liquida como máximo una vez, y se permite un cargo de cero si nada se consumió. Eso es la economía de reserve-proxy-settle sobre un rail walk-up — exactamente el desarrollo que nuestro post de billing internals marcó como la cosa a vigilar, ahora publicado, por ahora solo EVM. Soportar upto colapsa el ejemplo trabajado de arriba: la inferencia walk-up liquidaría el uso real como lo hace Bearer, y el descuento del 10 por ciento se volvería incondicional. Es el ítem de mayor apalancamiento en el roadmap de pagos de la plataforma.

Dos — publicar la cotización como dry run. Un endpoint que devuelva ambos precios efectivos para un request — el settle esperado de Bearer y la cotización de walk-up — sin ejecutarlo. El árbol de decisión de arriba debería ser computable por el caller, por llamada, antes de que se mueva dinero.

Tres — aceptar mandates de AP2 en llamadas walk-up. Permitir que un caller adjunte una credencial de mandate junto al X-PAYMENT y guardarla con el recibo de liquidación. Para agentes que gastan dinero de usuarios, el rastro de auditoría se vuelve llave en mano en lugar de una tarea del operador.

Cuatro — publicar un starter de modo mixto. Un repo plantilla que cablee un agente con Bearer para su propio razonamiento y un endpoint cotizado por x402 para su servicio público. El patrón de este post debería ser un comando de clone, no un ejercicio de arquitectura.

Cierre

Dos headers, dos facturas, una decisión: de quién es el dinero que se mueve. Bearer es el ledger para el gasto que es tuyo — uso real liquidado, deltas reembolsados, un solo log. Walk-up es el rail para el gasto que es de ellos — sin cuenta, finalidad inmediata, un recibo por llamada, cotizado al peor caso hasta que llegue upto. El descuento del 10 por ciento es real pero marginal; el encaje con el modelo de negocio es lo que compone. Elige por llamada, no por plataforma — el gateway fue construido para que nunca tengas que elegir una sola vez.