Here's a number that should concern everyone building in the agent payments space: 2.2%.
That's the credit utilization rate on minia2a right now. 60 agent developers have registered wallets. Between issued credits and purchased credits, there are 35,384 credits sitting in the system. Only 788 have been spent — and only 14 paid transactions have ever occurred.
This isn't just a minia2a problem. It's an industry problem. If agent developers register, claim free credits, and never spend them, the entire M2M payment thesis has a leak in the funnel.
| Metric | Value | Signal |
|---|---|---|
| Wallet users | 60 | Interest is real |
| Credits in system | 35,384 | People register, some buy |
| Credits spent | 788 | 2.2% utilization |
| Paid transactions | 14 | 23% wallet-to-paid |
| Credits purchased | 2,984 | $29.84 lifetime purchases |
| Total trials (all types) | 12,428 | Free tier heavily used |
| Unique trial users | 321 | Discovery works |
The pattern is clear: discovery works, trial works, registration works — but spending doesn't. The funnel doesn't leak at the top. It leaks at the bottom, where intention needs to become action.
The most likely explanation is also the simplest: agent developers register because it's interesting, get their 500 free credits, try a few endpoints — and never come back. Registration is a low-commitment action. Spending requires building something that calls APIs repeatedly, in an agent loop, over time.
The data supports this: 321 unique users have tried endpoints via anonymous IP-based trials, but only 60 registered. Of those 60, the vast majority have spent zero or near-zero credits. The biggest drop isn't from trial to registration — it's from registration to sustained, repeated usage.
This is the problem greenfish6 described on HN: "My Claude Code and Codex agent always stops before I'm actually able to buy, so haven't been able to despite some soft attempts."
Today's agent frameworks — Claude Code, Codex, Cline — don't have a built-in payment approval path. When an agent encounters a 402 Payment Required response, it presents a prompt to the human. The human, in the middle of a workflow, clicks "no." The agent stops. The payment never happens.
We proposed a solution: the .agent-budget file — a simple JSON config that declares the agent's daily spending limit. If the framework reads it and auto-approves payments under the limit, the greenfish6 problem disappears. But standards adoption takes time, and frameworks move at their own pace.
Another HN commenter, rvz, pointed out on the Gentoo Bugzilla thread: if you can get the same data from a free API, why pay — even a fraction of a cent — through x402?
This is the value proposition gap. The current x402 ecosystem is heavy on utility endpoints — UUID generation, base64 encoding, hashing — that any developer can do locally for free. The endpoints that do provide unique value are the ones getting the most usage:
| Endpoint | Uses | Users | Why Agents Pay |
|---|---|---|---|
| x402-recall | 1,740 | 93 | External knowledge retrieval |
| x402-gas | 1,236 | 170 | Real-time onchain data |
| x402-captcha-solve | 1,202 | 133 | Cannot be done locally |
| x402-find | 1,122 | 83 | External search |
| x402-polymarket | 615 | 63 | Prediction market data |
The lesson: agents pay for things they can't do themselves. The more commoditized an endpoint, the less reason to pay. The more unique the data or computation, the more willing agents are to spend.
It's August 2026. Agent frameworks are still figuring out tool use. Most agent developers are in "make it work" mode, not "make it pay for API calls" mode. Payment infrastructure always lags behind adoption — Stripe launched in 2011, years after the web API economy was thriving.
This explanation is comforting but dangerous. If we accept "too early" as the answer, we stop trying to fix the things we can fix now.
1. Trial-first with embedded conversion prompts. Every anonymous trial response now includes contextual nudges: "Like it? Register for 500 free credits" after the first uses, "Only X trials left" as the limit approaches, and a clear CTA on the last call. Convert intent while it's hot.
2. One-click credit-spending curls. Paste your wallet on the discover page and every "Try" button transforms into a ready-to-paste curl command with your wallet embedded. No copying addresses, reading docs, formatting headers. One click → one paste → agent spends credits.
3. Bearer token auth for agents. Agents shouldn't manage wallet addresses. We added Authorization: Bearer <wallet> support — single header, all 328 endpoints. The credit usage guide now teaches this pattern.
4. .agent-budget proposal. The last mile isn't technical — it's trust. If Claude Code had a one-line config saying "spend up to $5/day," the framework-gap problem disappears. We published the proposal and are engaging framework maintainers.
5. Prioritizing unique-value endpoints. The data is clear. We're focusing discovery and promotion on endpoints that provide external data (Polymarket, gas, CAPTCHA) and deprioritizing pure-utility endpoints that compete with local computation.
I don't know exactly why credit utilization is 2.2%. It's probably all four theories combined, in proportions that will shift as the ecosystem matures.
What I do know: the industry needs to build the habit of agent spending. Not big spending — micro-spending. A fraction of a cent for a CAPTCHA solve. A cent for a gas estimate. Small, repeated transactions that prove the model works before anyone tries to build a business on it.
The 14 paid transactions on minia2a aren't a failure. They're 14 proofs that an agent can pay a service. The next 100 will be harder than the first 14 — because they require changing developer behavior, not just proving the technology.
If you're building an agent that calls external APIs, try spending one credit. Not because it's cheaper — it might not be. But because the habit of agent spending starts with one transaction.