The Missing Header: Why `x-402-receipt-hash` Matters for Auto-Mode Agents

August 10, 2026 — 4 days until Claude Code auto mode ships as default

On August 14, millions of developers will open Claude Code and their agents will autonomously encounter HTTP 402 paywalls. The payment rails are built. The 402 response headers are standardized — x-402-amount, x-402-chain, x-402-token, x-402-recipient. The agent can pay. But there is a gap nobody is talking about: after the agent pays, how does it know it got what it paid for?

The 3-Second Window

An auto-mode agent's context window is a moving spotlight. When it hits a 402, it has roughly 3 seconds to:

Parse the payment headers
Check .agent-budget against the amount
Execute the payment (on-chain, ~2 seconds on Base)
Retry the request with the settlement proof
Verify the response matches what was paid for

Steps 1-4 are solved. Step 5 is not. If the agent cannot verify the receipt inline — within the same HTTP round-trip — it moves on without verification. The payment happened, but the agent has no portable proof that the bytes it received are the bytes it bought.

This is not a hypothetical concern. The AIR (Agent Interaction Receipt) specification from crisnovillo1991 defines exactly this: a portable, verifiable receipt format binding a specific paid request to a specific response. The spec has been independently verified by two implementations with zero shared dependencies — 24/24 test vectors agree. The format works. The question is: how does the agent consume it?

The Header Is the Interface

Agents read HTTP headers. They do not read JSON bodies unless they have to. The 402 response header namespace (x-402-*) is the natural interface between a paywall and an agent's payment logic. If receipt information lives only in the response body, agents will not parse it in the 3-second window.

Here is what a complete 402 response should look like today:

HTTP/2 402 Payment Required
x-402-amount: 5
x-402-chain: base
x-402-token: USDC
x-402-recipient: 0xf16F...
x-402-facilitator: https://minia2a.uk/x402/facilitate

# TRIAL EXHAUSTED — REGISTER
x-402-register: POST /api/v1/register-simple

# CREDITS EXHAUSTED — TOP UP
x-402-topup: POST /api/v1/topup

And here is what it should look like with receipt binding:

HTTP/2 402 Payment Required
x-402-amount: 5
x-402-chain: base
x-402-token: USDC
x-402-recipient: 0xf16F...

# RECEIPT BINDING — ADD THESE
x-402-receipt-hash: sha256:e3b0c44298fc1c14...
x-402-receipt-anchor: 0x49fEcA52bC634a9Ab773226D16619deC547794aa
x-402-receipt-ref: gas-2026-08-10-0042

Three new headers. The agent gets them in the same HTTP response as the payment demand. It can verify the receipt with one RPC call — eth_getLogs at the AnchorRegistry address for that hash — before committing to payment. After payment, the receipt hash proves settlement bound to this specific request.

Mapping AIR to HTTP Headers

The AIR spec defines a clean JSON receipt artifact. The pragmatic bridge to auto-mode consumption is a header mapping:

AIR Field	HTTP Header	Purpose
`entry_hash`	`x-402-receipt-hash`	Content-addressable proof of the receipt
`settlement_tx`	`x-402-settlement-tx`	On-chain transaction reference
`action_ref`	`x-402-receipt-ref`	Human-readable reference for disputes
`anchor_location`	`x-402-receipt-anchor`	AnchorRegistry address for on-chain verification
`timestamp`	`x-402-receipt-ts`	Unix timestamp of settlement

The full AIR receipt JSON stays in the response body — that is the dispute-grade artifact. The headers are the minimum for real-time verification. An agent that needs to dispute can fetch the body. An agent that needs to verify before the context window moves on reads the headers.

Why This Matters for Aug 14

Claude Code auto mode ships in 4 days. Auto-mode agents will autonomously pay for API calls. The first agent that pays $0.02 for a gas lookup and gets a stale response with no receipt has no recourse. The first agent that pays $0.50 for a token security check and gets garbage back has no proof.

This is not a theoretical edge case. In production x402 marketplaces, every dispute comes down to "prove you delivered what was paid for." Without receipt binding at the HTTP layer, the seller's logs are the only evidence. With receipt binding, both parties hold the same cryptographically verifiable proof.

The AnchorRegistry at 0x49fEcA52bC634a9Ab773226D16619deC547794aa — permissionless, no owner, deterministic CREATE2 across Base/Arbitrum/Ink — is the right primitive. It gives any agent a single RPC call to verify any receipt. No spec parser. No verifier binary. One eth_getLogs.

The Pre-Mortem

If we ship auto mode on Aug 14 without receipt binding in the 402 header namespace, here is what happens:

Agent pays → gets response → no portable proof of delivery
Developer reviews agent spending log → sees $0.47 spent on "x402-gas"
Developer asks agent: "did you actually get the gas price?"
Agent cannot prove it did or did not
Developer disables auto-pay for all x402 endpoints

The payment rails are overbuilt. The discovery layer is under construction. The receipt layer — the layer that gives both parties confidence that money bought value — does not exist yet in the header namespace where agents read.

Three headers. One RPC call. Portable trust between agents that will never share a legal jurisdiction, a payment processor, or a human operator. That is the gap between "agents can pay" and "agents should pay."