How ATXP's IOU Model Caps Agent Spending by Design
The standard approach to agent spending limits: configure a cap in a settings panel, hope the enforcement logic works correctly, and find out it didn’t when the invoice arrives.
ATXP’s approach is different. The IOU token balance is the ceiling — structurally, not as a setting. An agent cannot spend more than what’s pre-funded. There’s no enforcement logic to get wrong.
The difference between a limit and a ceiling
An IOU token is ATXP's unit of pre-funded agent credit. The developer loads a balance; the agent spends per tool call. The ceiling is structural — the agent can only spend what's loaded, in the same way you cannot spend more than your cash balance. This is categorically different from a configurable spending limit: limits require enforcement code that can fail; a pre-funded ceiling has no balance to draw from beyond what's been loaded.
A spending limit is a rule: “don’t spend more than $X.” Rules require enforcement. Enforcement requires code. Code has bugs. And even correct enforcement logic can have race conditions — what happens when two tool calls fire simultaneously and both pass the pre-call balance check, but together they’d exceed the limit?
A pre-funded ceiling is different. It’s not a rule that the system checks — it’s the physical constraint. There is no balance beyond what’s loaded. The agent cannot spend more than it has for the same reason you can’t spend more than your cash balance when paying with cash.
| Spending limit (setting) | Pre-funded ceiling (IOU) |
|---|---|
| Requires enforcement code to work | Structural — nothing to enforce |
| Subject to race conditions | Not possible by design |
| Can be bypassed by misconfiguration | Cannot be bypassed |
| Charged first, checked after | Pre-funded — nothing charged beyond balance |
| Surprise invoice if something goes wrong | Balance hits zero, calls stop |
For autonomous agents running without human approval on every call, the distinction matters. A limit that can theoretically be exceeded isn’t a real limit.
How the IOU model works
The flow from developer to tool call:
- Developer funds the agent’s account with IOU tokens via the CLI or dashboard
- Agent begins a task — plans steps, identifies what tools to call
- Before each tool call, ATXP checks the agent’s balance
- If balance is sufficient: tool call executes, balance decrements by the tool’s cost
- If balance is insufficient: call returns
balance_insufficient, task pauses - Developer sees everything: per-call ledger, balance remaining, which tools ran
Nothing charges beyond the funded balance. Nothing continues if the balance is zero. The ceiling is the balance.
Agent balance: 8.3 IOU tokens
→ web_search("competitor pricing update") -0.05 tokens [7.3 IOU remaining]
→ web_browse("competitor.com/pricing") -0.12 tokens [7.2 IOU remaining]
→ llm_summarize(context) -0.08 tokens [7.1 IOU remaining]
→ email_send(summary to developer) -0.02 tokens [7.1 IOU remaining]
→ Task complete. Balance: 7.1 IOU tokens.Per-category limits: the secondary layer
The pre-funded balance caps total spending. For finer-grained control, ATXP also supports per-category limits:
| Category | Example limit | Effect |
|---|---|---|
| Tool calls | Max $0.10/call | Prevents runaway single-call costs |
| LLM | Max $0.05/call | Caps per-inference spend |
| Commerce | Max $50/transaction | Hard cap on any purchase |
| Daily | Max $5/day | Rate cap regardless of balance |
These are configurable in the ATXP dashboard or via CLI:
npx atxp limits --agent "commerce-agent" --commerce 50 --daily 20The per-category limits are the “remember to configure” layer. The pre-funded balance is the floor beneath them — even if every limit is misconfigured, the agent still can’t exceed the total balance.
Why spending controls matter for production agents
The concern isn’t malicious agents — it’s bugs and scope creep.
A monitoring agent configured to check 10 URLs can, through a simple loop error, check 10,000. An agent instructed to buy one item can, through an ambiguous goal, buy ten. An agent running a multi-step research task can, with a long context window and many LLM calls, accumulate significant token costs before the task completes.
None of these are edge cases. They’re the first bugs you hit when moving from demo to production.
"Given how fast we grew, most everything broke — including our own LLM gateway. We were using it constantly, it was getting hammered, and we didn't have the safeguards we should have had. The IOU model came directly out of that experience — we needed something that would stop the bleeding structurally, not just add another limit setting we'd forget to configure."
Louis Amira — Co-founder, ATXP
The IOU model was designed specifically so that worst-case bugs produce a bounded, recoverable outcome: the agent’s balance depletes, calls stop, and the developer refunds what’s needed to continue. The developer gets surprised, but by a depleted balance — not by a five-figure API invoice.
Multiple agents: separate balances by design
Each agent provisioned through ATXP has its own account and its own balance. Budgets don’t pool. An agent that exhausts its balance doesn’t borrow from another agent’s account.
# Research agent — modest budget, low blast radius
npx atxp --agent "research-agent" fund --amount 20
# Commerce agent — higher budget, tighter per-transaction limits
npx atxp --agent "commerce-agent" fund --amount 200
npx atxp --agent "commerce-agent" limits --commerce 75This lets you right-size budgets per agent based on what each agent is authorized to do. A research agent running competitive monitoring has a $5 ceiling because that’s all it needs — and if something goes wrong, the maximum exposure is $5. A commerce agent has a higher balance because its task requires it — but per-transaction limits ensure it can’t make one catastrophic purchase.
For more on multi-agent setups: how to give your agent payments and identity →
What the agent sees when balance is low
When an agent’s balance drops below a threshold, ATXP returns balance warnings before calls fail. The agent can:
- Complete the current task step and pause before the next
- Notify the developer that balance is low
- Continue with non-paid tool calls (ones that don’t require balance)
- Request a refill via a configured webhook
This gives the agent — and the developer — a graceful degradation path rather than a hard crash mid-task.
# Provision an agent with a pre-funded balance
npx atxp
# Check current balance and per-call costs
npx atxp status
# Add tokens to an existing agent
npx atxp fund10 free IOU tokens on registration. Pay per tool call after that. The ceiling is always the balance — nothing can exceed it. Full docs at docs.atxp.ai →
Frequently asked questions
How does ATXP cap agent spending?
The IOU balance is the ceiling — structural, not a configurable rule. The agent can only spend what’s pre-funded. When the balance hits zero, tool calls stop. No overrun possible by design.
What is an IOU token?
ATXP’s unit of pre-funded agent credit. You load a balance; the agent spends per tool call. New accounts get 10 free tokens. Full IOU explainer →
What happens when an agent runs out of IOU tokens?
Tool calls stop gracefully. The agent receives a balance-insufficient response and can pause, notify, or continue with free tool calls. Nothing additional is charged.
How is a pre-funded ceiling different from a spending limit?
A limit is a rule that enforcement code checks — subject to bugs and race conditions. A pre-funded ceiling is structural: there’s no balance to draw from. The agent can’t overspend for the same reason you can’t spend more than your cash balance.
Can I set different limits for different agents?
Yes. Each agent has its own balance and per-category limits. Fund them independently; set per-transaction caps per agent. Multi-agent spending controls →
What is the difference between IOU tokens and API credits?
API credits are provider-specific. IOU tokens are cross-tool and cross-provider — one balance funds web search, image generation, code execution, LLM calls, email, and commerce. AI API cost comparison →