Shift From API Keys to Per-Request Payments: Solving Agent Loop Spending

Agent loops are an infrastructure problem, not a code problem

Most teams building agent systems know all the usual advice: add step limits, set token caps, monitor for repeated outputs. These are good best practices, but they're not enough to prevent an agent loop problem.

Step limits don't survive composition. Agent A calls Agent B, which calls Agent C. Step limits are local to each agent. If each agent is allowed 50 steps, the system can easily execute 150 total steps, and costs compound quickly.

Token caps are estimates, not enforcement. Most LLM APIs let you set max_tokens on a response. This limits output length, not spending. An agent that sends 50 requests with modest outputs can still accumulate serious spend.

Monitoring is reactive. Observability dashboards tell you what happened, but by the time you see a cost spike, the money has already been spent. Application-level budget checks can be bypassed: if your code checks a counter before each API call, that counter lives in the same trust domain as the agent.

You need a control layer that is external to the agent, that can't be circumvented by application bugs, and that enforces hard economic boundaries on every single request.

The solution: make every LLM call a payment

The budget problems described above share a root cause: payment and execution are decoupled. The x402 protocol addresses this by redefining how agents access LLM inference. Instead of authenticating with an API key and settling costs later via an invoice, each request is a discrete payment transaction.

With API keys, spending authority is granted once (when the key is issued) and revoked manually (when someone notices a problem). With x402, spending authority is exercised and verified on every single request. If the payment doesn't go through, the inference doesn't happen.

But pay-per-request alone doesn't prevent runaway spending. An agent stuck in a loop will keep paying as long as it has funds.

Introducing ampersend: the wallet that enforces your budget

ampersend is agentic payment infrastructure that gives autonomous agents programmable wallets with built-in spending controls and real-time observability. With ampersend enabled, when an agent requests a payment signature:

• If the agent's daily spend is under the limit, the wallet signs the transaction and the request proceeds
• If the daily spend has reached the limit, the wallet refuses to sign: the request fails and the agent is economically dead

This is the critical distinction: with ampersend, the spending limit is not in the application code. It lives in the wallet policy. The agent's code cannot override it, bypass it, or accidentally skip it. Even if the agent is stuck in an infinite loop, prompt-injected, or broken by orchestration bugs, the wallet remains the final authority.

Does ampersend really stop runaway payments?

We built a load test that deliberately simulates a disaster scenario, firing requests in an infinite loop as fast as possible. With a traditional API key, nothing stops it. With ampersend, the first N requests succeed, then when the daily limit is reached the treasurer refuses to sign the next payment. The total spend is exactly the daily limit you configured, not a dollar more.

The loop may continue because logically the code still wants to send requests, but financially, it's dead. The wallet, not the code, is the circuit breaker.

Why this matters for agent builders

If you're building systems where AI agents call LLM APIs, the loop spending problem will eventually find you. The structural vulnerability is the same: unbounded financial authority granted via API keys, with no infrastructure-level enforcement. The shift we're advocating is simple:

• Replace API keys with per-request payments: x402 makes every LLM call an explicit economic transaction
• Enforce budgets at the wallet layer, not the application layer
• Make costs onchain and auditable

Governance belongs at the platform layer, not the application layer. Kubernetes doesn't trust your containers to self-limit CPU usage. Your agent infrastructure shouldn't trust your agents to self-budget.