Claude Code Leak: Anthropic Preps for Agent Payments

I think I found the first crypto-related feature in Claude Code’s source. Bear with me.

There’s a /x402 command that generates a crypto wallet within Claude Code, stores the private key on your machine, and uses it to automatically pay for API access whenever the agent hits a paywall. The agent signs a payment authorization, attaches it to the HTTP request, and retries. Zero humans in the loop.

I spent time checking whether this was a stub or a prototype. It’s not. It’s a complete payment client with actual cryptographic signing, real spend limits, and deep integration into Claude Code’s core modules.

I’m not a crypto person. But this was genuinely interesting, because regardless of how you feel about blockchains, it’s solving a real problem: what happens when an autonomous agent needs to buy something?

We may have finally found the real use case for blockchain: agent-to-agent payments.

Quick crypto primer

Skip this if you’re already familiar with the crypto space. For everyone else like me, here’s what you need to know before the rest of this makes sense.

USDC is a stablecoin - a cryptocurrency pegged to one US dollar. Unlike Bitcoin, which can swing 10% on a Tuesday, 1 USDC always equals 1 USD. That’s what makes it useful for payments: neither side is gambling on the price.

Base is a blockchain network run by Coinbase. Think of it as a faster, cheaper layer on top of Ethereum. Sending money on Ethereum can cost a few dollars in fees alone. On Base, it’s fractions of a cent. That difference is what makes a 3-cent API payment economically viable.

A wallet is a pair of cryptographic keys: a private key (a secret number that can sign things) and a public address derived from it (like an account number). Whoever holds the private key controls the wallet.

Signing means using your private key to produce a cryptographic proof that says “I authorized this specific action.” Anyone can verify the signature came from you, but nobody can forge it without the key.

A facilitator is a Coinbase server that handles the actual blockchain orchestration. The agent never interacts with the blockchain directly. It signs a permission slip and hands it to the seller; the seller then settles the payment with the facilitator on-chain. The agent’s job is simple: make an HTTP request.

What’s HTTP 402?

You know HTTP 200 (OK), 404 (Not Found), 500 (Server Error). There’s also HTTP 402 - “Payment Required.” It’s been in the HTTP spec since the ’90s, but was marked “reserved for future use.”

Nobody used it because there was no standard way for a client to programmatically pay. Humans have browsers and credit card forms. Machines didn’t have an equivalent.

Coinbase’s x402 protocol fills that gap. The flow is straightforward:

1. Agent requests a resource from an API.
2. API returns HTTP 402 with a header specifying the price, recipient address, and currency type.
3. Agent signs a payment authorization - not the actual transfer, just an authorization - and retries the request.
4. API verifies the payment cleared and returns the data.

All of this happens in a couple of HTTP round trips. No checkout page. No signup form. No API key provisioning. It’s the machine equivalent of swiping a credit card - validated instantly, no paperwork.

What the code does

The implementation spans about 8 files across the x402 services and commands modules. Here’s the architecture:

The wallet

The /x402 setup command generates a random 32-byte private key, derives the wallet address, and stores both in the local Claude config file. File permissions are set to 600 - owner read/write only, same security model as SSH keys.

There’s also an environment variable override for CI and automation scenarios, where you’d use a secrets manager instead of a local config file.

The interceptor

This is the part that’s almost absurd. The x402 protocol doesn’t require the agent to “know” about payments at all. Payment processing is wrapped transparently around the HTTP client layer.

For the Anthropic SDK, it wraps the underlying fetch call. For the web fetch tool, it adds an Axios interceptor. Both work identically: if a response comes back as 402, the interceptor checks whether x402 is enabled, parses the payment requirements from the header, validates against spend limits, signs the authorization, and retries the request.

The agent’s code doesn’t change. It makes a normal HTTP request and gets back data. The payment happened entirely in the middleware, invisible to the agent. Presumably this is a deliberate design choice - the agent doesn’t waste tokens reasoning about payment mechanics when the middleware can handle it deterministically.

The signer

This is the most complex piece, and the strongest evidence that this isn’t a prototype. It implements the full signing protocol.

The payment authorization is a structured object that says: “I authorize transfer of X amount from my wallet to your wallet, valid between this time range, with a unique nonce so nobody can replay the same payment.” The nonce matters because everything on a blockchain is public; without it, someone could resubmit your signed payment a second time.

The authorization gets signed using a scheme that ensures the signer knows exactly what they’re approving. You’re not signing a mystery blob of bytes - you’re signing named fields with explicit types. This distinction matters in crypto, where signing opaque data has historically been a common attack vector. The signature uses the same elliptic curve cryptography that secures Ethereum and Bitcoin. The resulting payload is base64-encoded and attached as an HTTP header on the retry.

All of this still happens transparently. The agent thinks it made one HTTP request. The interceptor and signer handled everything else.

The tracker

Every payment is logged in memory for the session: timestamp, resource URL, amount in both token units and USD, recipient address, network, and signature. The tracker produces a formatted cost summary that integrates with Claude Code’s main session cost display, so x402 payments show up right alongside your API token costs when you run /stats or /usage.

5 layers of spend control

Anthropic is rightfully building guardrails here. They know that bad actors - including via prompt injection - would try to drain wallets. Here are the safety layers.

Layer 1: Off by default. Payments are disabled until you explicitly set up a wallet. No wallet, no risk.

Layer 2: Per-request cap. Default is 10 cents. Every individual payment is validated against this threshold before signing. A malicious API demanding $100 in a single request simply gets rejected.

Layer 3: Per-session cap. Default is $5. Cumulative tracking across all payments in a session. Even if every request is under the per-request limit, the running total is capped. An agent looping thousands of requests at 5 cents each hits the wall at request 100.

Layer 4: Network and token lockdown. The agent only pays on the network it’s configured for - Base, Ethereum, or their test networks. A 402 response asking for payment on Ethereum when the wallet is set to Base gets rejected. A response requesting a non-USDC token gets rejected. No surprise chain switches, no exotic tokens.

Layer 5: Full audit trail. Every payment decision - approval or rejection - is logged with the reason. Session totals are available via /x402 status. You can see exactly where every cent went.

Both limits are configurable via /x402 set-limit and /x402 set-session. There’s also a testnet mode (/x402 network base-sepolia) so you can experiment with fake money first.

Bigger than crypto

This is a sign that companies are actively preparing for fully autonomous agents that do more than get handheld through tasks. Agents will probably have budget allocations the way today’s employees do, and guardrails, the way today’s employees do.

Anthropic clearly believes that blocking agents from transacting is artificially capping their productivity. That’s why this feature exists. They expect people will eventually be comfortable letting AI agents make spending decisions within defined limits.

People are already making these calls - and far more consequential ones. When a software engineer pushes to production after vibe coding without proper review, they’ve already made a spending decision; it just isn’t denominated in dollars. The cost shows up later as incidents, rollbacks, and lost engineering hours. Whether AI tooling is improving the quality of that work is a separate argument, but the financial impact is real at many of these organizations.

This will probably accelerate the emergence of agent-driven economies. We’ll see tools built primarily for agent consumption, and APIs designed for machines rather than humans. The key enabler is that Claude has set this up on Base, where gas fees are fractions of a cent - similar in spirit to India’s UPI or tap-to-pay systems. Micropayments that make no sense with credit card processing suddenly become viable. A $0.001 API call isn’t worth a credit card transaction, but a USDC transfer on Base costs nearly nothing.

Not just Anthropic

The x402 protocol is a real ecosystem. Coinbase launched it in May 2025, and by December it had processed over 75 million transactions. Cloudflare co-launched the x402 Foundation. Stripe started using it for AI agent payments in February 2026. Anthropic is a publicly listed ecosystem participant alongside Google Cloud and AWS.

The facilitator URLs in the source point to real, operational endpoints. The USDC contract addresses match actual mainnet and testnet deployments. This isn’t speculative code.

The /x402 command supports multiple networks: Base mainnet, Base Sepolia (testnet), Ethereum mainnet, and Ethereum Sepolia. Supporting multiple networks including testnets is standard practice for production-grade blockchain integrations - it means developers can experiment with fake money before switching to real funds.

Is this real?

How do we know this code is genuine and not something injected into the leaked repo?

The x402 code is deeply wired into four core modules that have nothing to do with payments: the command registry, the main API client, the web fetch utility layer, and the session cost tracker. It’s not sitting in an isolated folder - it’s integrated into the plumbing.

The coding patterns are internally consistent with the rest of the codebase: same documentation conventions, same logging utilities, same config access patterns, same error handling style. Injecting this would mean modifying four unrelated core modules in a way that perfectly matches the existing codebase style. Combined with Anthropic being publicly listed as an x402 ecosystem participant, this is almost certainly real.

That said, features in source don’t necessarily ship to every user. This could be feature-flagged, experimental, or reserved for specific use cases. Treat this as “what the source reveals” rather than “what every Claude Code user has access to today.”

What this means for agents

Imagine Claude Code placing orders on Amazon. Or an agent swarm collaborating on open-ended work, where each member independently decides when it’s worth paying for premium data to do its job better. Instead of agents writing code for us, they might start operating more like autonomous workers - collaborating, making judgment calls, building their own tools when they find it efficient.

Micropayments are a necessary precondition for all of this. Game-theoretic incentives around value exchange require that agents can actually transact. Without that, you can’t have agents optimizing their own time and token spend.

AI agents are about to get wallets. And cryptocurrency adoption among AI agents might outpace what it managed in over a decade of trying to get humans on board.