Tutoriales, comparativas y patrones de diseño para construir agentes autónomos que se autofinancian, llaman a 345+ modelos y orquestan MCP Tools.
x402 v2 pone todo el protocolo en headers, y su spec HTTP nunca menciona navegadores. En un harness local con el SDK 2.28.0 y Chrome headless, ningún middleware de servidor puso un header CORS, los defaults de cors() escondieron el precio, e incluso una configuración CORS mínima y correcta falló porque @x402/fetch agrega el header de respuesta Access-Control-Expose-Headers a su propio reintento pago (fix #3478, abierto desde el 15 de septiembre). Un HEAD sin pagar ejecutó un handler GET pago; el fix #3796 está mergeado pero ningún SDK publicó release desde el 29 de septiembre. El fetch de Node falla por encima de 16 KiB de headers y aiohttp por encima de 8.190 bytes por header. Un censo de 2.233 sellers del Bazaar: 875 permiten el origen, 635 exponen el precio, 568 se pueden pagar con un cliente de navegador correcto, 120 con el publicado; 126 responden el preflight con 402, 242 sirven HEAD sin pago y 188 superan el límite de aiohttp. Nuestro propio gateway también esconde su precio. Seis pasos para LLM4Agents.
Además de su versión, la extensión offer-receipt mergeada en x402 firma cinco campos del recibo: red, URL del recurso, pagador, hora de emisión y un hash de transacción opcional. Ni monto, ni beneficiario, ni request, ni respuesta. En un harness local con el SDK 2.28.0, el flag includeTxHash nunca llegó al recibo (issue #3824, un bug de aliasing cuyo fix de una línea sigue abierto en #3826), y dos pagos distintos hechos en el mismo segundo volvieron con recibos idénticos byte por byte, firma incluida. Una hora de USDC en Base muestra por qué importa: el 22,4% de 4.176 settlements EIP-3009 tuvo un gemelo en el mismo bloque con el mismo pagador, beneficiario y monto. En el Bazaar, 32 de 2.452 hosts firman ofertas; las 796 firmas EIP-712 verifican, pero 21 de 22 firmantes EIP-712 no publican ni una entrada did:web ni un registro DNS _controllers para su clave. Leímos las cinco propuestas abiertas que intentan corregirlo: el commitment salado al nonce del recibo v2 (recalculado y vinculado en vivo en Base Sepolia), svm-memo, delivery-receipt con Ed25519 más ML-DSA-65 y digests de stream SSE (vectores verificados, más el único directorio de claves en vivo), el Buyer Delivery Claim y el Settlement-Receipt Binding. Seis pasos para LLM4Agents.
Entre el 9 y el 16 de octubre, Chainalysis contó 138 millones de transacciones x402 en Base y vio wallets nuevas gastando 18 minutos después de ser fondeadas. Nuestro propio censo del Bazaar de x402, que ahora publica pagadores únicos por endpoint, encontró 43.338 recursos cuya mediana tiene un pagador, con un solo endpoint llevando el 38% de las llamadas. Proof puso x401 en producción, una capa de identidad por headers que deja explícitamente el pago al 402. El Shop skill de Shopify llevó los spend requests a MCP stateless sobre rieles de tarjeta. Y x402 mergeó un fix para requests HEAD que llegaban a handlers GET pagos sin pagar, que reprodujimos sobre los paquetes 2.28.0 publicados, mientras Coinbase sacó a x402 de su bug bounty.
La spec de x402 define settle como el paso que establece finalidad 'desde la perspectiva del resource server', y su SettleResponse no tiene ningún campo para decir qué tan final es un pago. Las reglas de familia de exact obligan a los métodos client-submitted a declarar un evento de finalidad, pero no a las rutas EVM y SVM, que son facilitator-submitted; solo el binding de Cardano deja que el vendedor elija una profundidad de confirmación. Leímos qué espera cada implementación, desde el FINAL de NEAR hasta el ACCEPTED_ON_L2 de Starknet. Después corrimos el wrapper de signer EVM del propio x402 sobre 100 settlements reales de USDC en el RPC público de Base: todos se resolvieron como success en una mediana de 179 ms, 94 antes de que su bloque se sellara, y los 100 se mantuvieron hasta el safe head. Un muestreo de diez minutos puso el finalized head de Base unos 18 minutos detrás de la punta y el de Polygon unos 3 segundos. En Solana, slots más rápidos reducen la ventana de blockhash documentada de 60–90 segundos a unos 25, y la migración a Alpenglow del 21 de octubre abre una ventana de solo votos donde ningún settlement de x402 puede aterrizar. Siete pasos para LLM4Agents.
Un agente que paga por llamada paga por un string de modelo, y tres cosas pueden cambiar lo que ese string significa. Anthropic fija cada ID; OpenAI fija snapshots detrás de aliases y mantiene un nombre flotante; Google define strings stable, preview y latest, y el 8 de octubre empezó a enrutar los estables gemini-3.5-flash y gemini-3.7-flash hacia 3.6 y 3.8 Flash, que ignoran temperature. OpenAI dio a GPT-4o y GPT-4.1 tres meses de aviso el 14 de octubre, y los precios de Gemini 4 Argon y 3.6/3.8 Flash se duplican el 1 de diciembre y el 1 de enero. Los catálogos de más abajo se atrasan: OpenRouter todavía cotiza gemini-3.5-flash a $1.50/$9.00, no lleva fecha de expiración en ninguna de 23 entradas de OpenAI con shutdown anunciado, y 5 de sus 19 aliases latest listan precios distintos a los de su target; LiteLLM tiene 27 de 32 fechas de OpenAI pero ningún campo para un precio con fecha. x402 ata una URL, no un modelo. Nuestro propio 402 cotiza el modelo re-enrutado a 2.4x su sucesor, sigue vendiendo dos modelos que Anthropic retiró y sigue emitiendo una cotización de un centavo para strings que no tenemos. Ocho pasos para arreglarlo, en orden.
Los refusals hoy tienen tres formas: texto que escribe el modelo, un rechazo del clasificador devuelto como HTTP 200 (el stop_reason refusal de Anthropic con categoría en stop_details) y un bloqueo del clasificador devuelto como error (el bio_policy de OpenAI, que OpenRouter expone como 403). Solo Anthropic documenta cómo cobra los refusals, y cambió dos veces en cuatro meses: desde el 24 de septiembre de 2026 un refusal antes de cualquier output se cobra en bio, frontier_llm y reasoning_extraction, es gratis en cyber, general_harms y null, y un refusal a mitad de stream siempre cobra lo que se emitió. El fallback credit devuelve la escritura de caché del reintento, unos $0.25 contra $0.02 en un turno de 40,000 tokens movido a Opus 4.8, pero el token vive cinco minutos y solo se canjea en el workspace que recibió el refusal. Cuando un refusal cruza al formato Chat Completions la categoría desaparece: LiteLLM y el AI SDK lo mapean a content_filter y la capa de compatibilidad de Anthropic deja message.refusal vacío. En Ollama 0.30.6, 204 refusals de política en 480 llamadas terminaron todos con finish_reason stop y ninguno llenó el campo refusal. Los middlewares de referencia de x402 settlean todo lo que esté bajo HTTP 400, así que un refusal es una venta salvo que el vendedor decida otra cosa. Siete pasos para un gateway que cobre un no por lo que costó.
El largo del contexto es la única variable del request que cambia a la vez si una llamada puede tener éxito y cuánto cuesta, y ambos cambios son escalones. Claude Haiku 5.5 reprecia todo el request 5x pasados 100,000 tokens de prompt; Gemini 2.5 Pro y 3.1 Pro Preview suben en 200k; las familias GPT-5.4/5.5 y GPT-6 cobran 2x de input y 1.5x de output pasados 272K. Pasada la ventana, los proveedores responden en cuatro dialectos: el 400 'prompt is too long' de Anthropic o un 200 con model_context_window_exceeded, el switch truncation de OpenAI ya deprecado, el error_type canónico de OpenRouter que su skin de Responses puede convertir en una completion 'length' exitosa, y el silencio. Ollama 0.30.6 devolvió HTTP 200 y finish_reason stop en todos los prompts fuera de ventana, conservó solo cuatro tokens del inicio, perdió el system message 5 de 5 veces y reportó el conteo truncado. LiteLLM detecta el overflow comparando strings de error y mapea model_context_window_exceeded a 'stop'. Nuestro propio 402 es lineal a través de todos los tramos: en GPT-5.5 pasa de 1.32x la lista con 272,000 tokens a 0.67x con 273,000, y sigue cotizando requests hasta 2.5x más allá de la ventana del modelo. Siete pasos para arreglarlo, en orden.
El binding de Stellar para x402 exact es el único donde el buyer nunca elige la transacción que entra: firma authorization entries de Soroban con un plazo contado en ledgers, y el facilitator arma todo a su alrededor al settlear. Corrimos pagos reales en testnet contra el facilitator de referencia 2.28.0. El cierre de ledger es constante en 5.000 segundos sobre 2,000 ledgers de pubnet, así que la aritmética es sólida, pero la altura que lee cada parte no es compartida. Verify comprueba que la authorization no viva demasiado y nunca que viva lo suficiente, así que un payload puede verificar y después no settlear — falla cerrado, cuesta disponibilidad y no fondos. Más el techo de fees con 1.50x de margen, la dirección muxed que pasa la validación y falla la verificación, por qué las smart accounts con topes no pueden pagar, un censo de la cuenta de fees en mainnet donde la mediana del fee de settlement cae a menos de 3% de nuestro número de testnet, qué significa para nuestro gateway y seis pasos.