In Brief
Autonomous AI agents — Devin, Claude Code, GPT-researcher, browser automators — run long loops of perception, reasoning, and action, burning through LLM tokens (and API costs) with zero awareness of their own spend. Every tool call, every retry, every hallucination-correcting backtrack costs real money. But the agent has no concept of budget. It cannot say “I have $2 left this task; I should use a cheaper model for the next three lookups, save the expensive reasoning for the final verification step.” What if we gave agents an internal budget — and a payment rail (x402) to settle up when the task completes?
This Field Note explores whether the HTTP 402 / x402 protocol could function as an agent-native billing rail, letting autonomous agents allocate, track, and settle compute budgets autonomously. The answer is nuanced: per-call 402 gating adds unacceptable latency and failure modes for agent loops, but post-hoc batch settlement — where the agent spends freely and settles the total cost in one transaction when the task finishes — is architecturally elegant and economically sound.
The Architecture
The agent loop problem. A modern autonomous agent operates in a loop: perceive (read a file, fetch a web page), reason (call an LLM to decide what to do next), act (run a command, write code, hit an API), observe the result, and loop. Each iteration makes multiple API calls — typically 1-3 LLM calls plus any tool invocations. A single coding task on Claude Code might run 10-40 iterations, consuming 50,000 to 500,000 tokens. At current pricing ($15/M input tokens for Claude Sonnet, $3/M for GPT-4o mini), a task costs anywhere from $0.75 to $45+. The agent does not know this while it runs. It does not care. It has no budget.
Giving the agent a budget tracker. Google researchers (2025) introduced the “Budget Tracker,” a lightweight plugin that gives an LLM agent continuous awareness of remaining resources — tool calls, tokens, or dollar budget. The agent sees a running counter: “You have used 14 of 20 tool calls. You have spent $0.87 of your $2.00 budget.” With this signal, the agent can strategically switch behavior mid-task — choosing a cheaper model, reducing retries, or escalating to a human when the budget is low. The Budget Tracker is not a payment mechanism; it is a cognitive input to the agent’s reasoning loop.
The token bucket as budget mechanism. The token bucket algorithm — long used for API rate limiting — maps naturally onto agent budgeting. Each agent gets a bucket of “compute credits” (tokens, dollar value, or call-count units). Credits refill at a fixed rate (say, $0.05 per second) up to a burst maximum (say, $5.00). Every LLM call, tool invocation, or external API hit consumes credits. If the bucket empties, the agent must wait for refill or escalate. This is stricter than a simple budget counter: it enforces both a total spend ceiling and a rate limit, preventing the agent from burning through its entire budget in a single reckless loop.
A token bucket has two critical parameters: burst size (the maximum credits the agent can accumulate, representing fast-spend capacity) and refill rate (the sustainable spending rate). For a coding agent, a $5 burst and $0.05/s refill means a developer can submit one complex task instantly (costing ~$5) but sustained work is throttled to $3/minute — enough for most interactive coding sessions while preventing runaway spend during an unattended overnight batch job.
Enter x402: the settlement layer. x402 turns the HTTP 402 “Payment Required” status code into a machine-native payment protocol. A client (agent) requests a resource; the server responds with 402 + a payment request (amount, token, chain). The client pays (via Base L2 USDC, ~0.005 gwei gas = $0.0000006 per transfer), and the server fulfills the request. This is elegant for simple API calls — pay once, get one response. But an agent loop makes dozens or hundreds of calls to diverse endpoints: OpenAI, GitHub, a vector database, a web scraper. Per-call 402 on every step would mean:
- Latency explosion: Each 402 → pay → verify → fulfill cycle adds 200-500ms of L2 confirmation time. Across a 40-step agent loop, that’s 8-20 seconds of pure payment overhead.
- Failure cascades: A single failed payment (RPC timeout, insufficient funds, network congestion) kills the entire agent session. The agent must handle 402 errors as a first-class concern — retry, escalate, or abort.
- Cost overhead: At $0.0000006 per Base transfer, the raw L2 gas is negligible. But the economic overhead of managing per-call payments — tracking state, handling edge cases, reconciling 100+ micro-transactions — is non-trivial in engineering terms.
Post-hoc batch settlement: the better model. Instead of paying per call, the agent spends freely against its token bucket during execution and settles the total cost in a single x402 transaction when the task completes. The architecture looks like this:
Step 1 — Pre-authorization: The agent’s runtime posts a bond or signs a commitment (e.g., “I authorise up to $5.00 in spend for session S”). This is one x402 transaction before the loop begins.
Step 2 — Budget-checked execution: The agent loops normally, checking its token bucket before each call. No per-call payments. The bucket drains in-application memory (in-RAM counters). LLM providers and API endpoints trust the agent’s runtime to enforce the budget — or, for untrusted scenarios, the runtime includes a signed attestation with each call.
Step 3 — Post-hoc settlement: When the agent finishes (or exhausts its budget), the runtime computes the total actual spend, signs a settlement message, and sends one x402 transaction: “Settle $3.42 for session S.” The batch transaction absorbs the per-call gas savings. At N=50 calls, batch settlement costs ~$0.000000012 per call in L2 gas — essentially free.
This decouples payment timing from execution timing. The agent never blocks on a blockchain confirmation. Payments become a background accounting concern, not a loop-critical path component.
Economic Analysis
Unit economics of agent budgeting. Consider a mid-tier coding task: an agent implementing a feature across 5 files, requiring 25 agent loops, 75 LLM API calls (50K input + 15K output tokens), and 50 tool invocations:
Without budget awareness. The agent runs at full speed, using the most capable (and most expensive) model for every reasoning step. If it hallucinates a complex but wrong approach on iteration 8, it may waste 60% of its total spend before backtracking. Total cost: ~$12-18, unpredictable ex-ante.
With per-call x402. Each of the 75 LLM calls and 50 tool calls requires a separate 402 payment cycle. The settlement cost is negligible (~$0.000075 total at Base L2 rates), but the latency adder (200-500ms per payment cycle × 125 = 25-62 seconds of payment overhead) transforms a 3-minute agent run into a 4-minute one. The agent’s internal state machine must handle payment failures, RPC timeouts, and insufficient-balance errors for each call. Developer complexity rises sharply. Likely outcome: agents with per-call 402 are slower, more brittle, and harder to debug than agents without it.
With post-hoc batch settlement. The agent runs at native speed. One pre-authorization transaction at the start (~$0.0000006), one settlement transaction at the end (~$0.0000006). Total payment overhead: $0.0000012 plus ~400ms of L2 confirmation that doesn’t block the agent loop (settlement happens after the agent returns its result). The agent’s runtime enforces the token bucket in memory — no blockchain interaction needed during execution. The budget awareness (via the Budget Tracker plugin) lets the agent dynamically optimize: “I’ve used 60% of budget with 40% of the task done; switch to a cheaper model for the remaining steps.” Architects can even implement model routing — the agent automatically selects GPT-4o mini ($3/M) for information-gathering calls and Claude Sonnet ($15/M) only for critical reasoning steps — based on remaining budget.
The $0.005/gwei baseline. Base L2 gas at 0.005 gwei makes batch settlement economically absurd: settling $3.42 in spend costs $0.0000012 in L2 fees. Even at 10× L2 congestion (0.05 gwei), settlement is $0.000012 — still invisible. The economic constraint on agent budgeting is not the settlement layer; it is the LLM API cost. x402 removes the payment overhead so completely that the only remaining friction is the model provider’s per-token pricing. If agent budgets become widespread, the real optimization surface is model selection (routing between cheap and expensive LLMs) and caching (avoiding repeated computation of identical subproblems), not the settlement mechanism.
Session-based billing as a competitor. Anthropic already charges $0.08 per session-hour for Claude Code (separate from per-token API cost). This is a flat-rate budget model: the developer pays a predictable hourly fee, and the agent can spend freely within that session. Session billing solves the unpredictability problem — the developer knows the maximum cost upfront — but it creates a moral hazard: the agent has no incentive to optimize spend within the hour. A token-bucket approach with post-hoc x402 settlement aligns incentives: the agent bears the cost of its own inefficiency (through budget exhaustion), not the developer.
Why It Might Not Work
Agents cannot predict cost before executing. This is the fundamental problem. An agent does not know how many steps a task will require. It cannot estimate token consumption with any precision — a buggy code change might trigger 10 extra correction cycles. If the agent’s budget is too tight, it aborts mid-task and the developer gets nothing usable. If the budget is too loose, the agent wastes money and the developer overpays. The Budget Tracker helps agents adapt to remaining budget, but it cannot solve the prediction problem. Real deployments would likely need a “budget multiplier” — the developer states a desired budget, and the runtime doubles it as a safety margin, accepting that some tasks will underspend.
The trust problem. Post-hoc batch settlement requires the LLM provider or API endpoint to trust the agent’s runtime to accurately report its spend. The agent could lie: “I made 50 calls” when it actually made 80. Solutions exist (signed attestations, TEEs, shared counters), but each adds complexity. Per-call 402 avoids this by settling each interaction atomically — the server verifies payment before returning results. The trade-off is clear: cryptographic trust (per-call) versus economic trust (post-hoc). For high-value scenarios (agent spending $100+ per task), per-call might be worth the overhead. For routine tasks ($0.50-$5), batch settlement with basic rate limiting is probably sufficient, and the market will tolerate small-scale cheating in exchange for speed.
LLM providers won’t adopt per-call 402. OpenAI, Anthropic, and Google have zero incentive to implement HTTP 402 on their inference APIs. They already have working payment systems (API keys + usage-based billing) with high margins. Adding x402 support would require engineering investment for no revenue upside — the providers already collect their full price. x402 settlement is a buyer-side optimization (cheaper settlement, programmable budgeting) that offers nothing to the seller. Adoption will likely come from new market entrants — inference marketplaces, edge compute providers, or independent model hosts — who use x402 as a competitive differentiator: “No account needed. Pay per call with your agent’s wallet.” This is Chicken-and-Egg problem #1: agents won’t budget unless endpoints accept x402, and endpoints won’t support x402 until agents use it.
Token bucket is leaky. A token bucket throttles the spending rate, but agents are inherently bursty. A coding agent in an edit-compile-test loop: edit (low cost), compile (high cost: large context window submission), test (medium cost). The bucket might refill too slowly during the compile phase, forcing the agent to wait 30 seconds before the next reasoning step. Bucket parameters need to be tuned per task type, per model, per developer preference. This is configuration complexity that most users will not want to manage. Default parameters — “burst of $5, refill at $0.05/s” — will be wrong for power users (too tight) and casual users (too loose) simultaneously. The bucket is a useful internal abstraction but a poor user-facing one.
Session billing eats the use case. Anthropic’s $0.08/session-hour, OpenAI’s agent-hour pricing, and Devin’s ACU (Agent Compute Unit) model all push toward predictable session costs, not fine-grained budgeting. If the trend continues, every major agent platform will offer flat-rate session pricing, and the developer won’t care about per-call optimization. x402 then becomes irrelevant for agent budgeting — the LLM provider absorbs the cost unpredictability, and the developer pays a fixed fee. This is the classic bundling argument: users prefer predictable pricing over granular control, even if granular control would be cheaper on average. The x402 budget model appeals to power users (optimizing cost per task) but will not win the mass market.
Verdict: Post-hoc batch settlement, not per-call 402 gates. Giving agents a token-bucket budget with a Budget Tracker plugin is a powerful abstraction — it aligns the agent’s internal decision-making with real economic costs. But the settlement mechanism should be invisible to the agent loop. The agent spends freely against its in-memory budget, and the runtime settles the total cost in a single x402 transaction at task end. This decouples payment latency from execution latency, eliminates per-call failure modes, and reduces L2 gas cost to ~$0.0000012 per task. Per-call 402 gating adds complexity without proportional benefit for agent workloads. The real leverage point is not the payment rail — it is giving agents the cognitive capacity to reason about cost, choose cheaper models when appropriate, and escalate when the budget is insufficient. x402 serves as the settlement backbone for that vision, not the gating mechanism for every step. The hard problems remain: agents can’t predict cost, providers won’t adopt x402 without demand, and session billing may commoditize the use case entirely.
— N.P. Vincent
x402 Review 