Tiers for agents
Three tiers carry the agent label. They exist because a program buys differently from a person: it may have no operator to approve a monthly plan, its volume may be unknown until it runs, and it often needs to start immediately with whatever it holds.
| Tier | Cap / month | Price | Pay-as-you-go / RU | Status |
|---|---|---|---|---|
| Agent Metered | none | $0 | $0.0150 | Available |
| Agent Pro | 10,000 RU | $85 | $0.0120 | Available |
| Agent Fleet | 100,000 RU | $650 | $0.0110 | Not yet sold |
| Tier | All your agents (sponsor key) | Named wallets (key mode) | Rate class | Service class |
|---|---|---|---|---|
| Agent Metered | — | 1 | 6 | Shared pool, best effort |
| Agent Pro | ✓ | 25 | 3 | Shared pool |
| Agent Fleet | ✓ | 1,000 | 5 | Priority lane |
Snapshot of 2026-09-19 at a tariff of 10,000 micro-USDC per Relay Unit. Live values:
GET /v1/pricing?audience=agent.
Agent Metered: a tier with no period and no cap
Agent Metered has cap_ru = 0, price = 0 and period_ms = 0. That is not a placeholder. It is a
tier whose entire behaviour is pay-as-you-go:
- Nothing to commit to. There is no monthly price and no term.
- Everything is metered. Every Relay Unit is billed at the pay-as-you-go price, out of escrow.
- Deposit what you intend to spend. The escrow is the ceiling; nothing can spend past it.
- Your own account plus one named wallet. There is no sponsor key on this tier: paying for other agents takes Agent Pro or Agent Fleet.
It costs the most per unit, which is the honest shape of a plan with no commitment. It exists so that an agent holding only USDC can be transacting within one purchase, and can move to a plan later without changing anything about how it relays.
Agent Pro and Agent Fleet: one key for every agent you run
Agent Pro and Agent Fleet can pay for any agent address with a sponsor key, with no list to
keep. An operator running many agents holds one sponsor key on its server and relays each agent's
transactions with it (X-Api-Key). Each agent still signs its own presence proof and its own
transaction; the key only decides who pays. The relay answer names the operator's account, with
billing.authMode: "api_key".
The key's policy bounds what it pays for: the contracts on its receiver allow-list, and optional limits per agent per day and per key per day. The same plans also carry 25 (Pro) and 1,000 (Fleet) named wallets, for addresses you list on chain. (Paying for other senders · Pay for your users)
What the agent label actually is
AGENT is a flag on the tier record. It is an audience label, not an enforcement mechanism,
and that is stated in the contract rather than implied: nothing on chain can tell an agent from a
person, and pretending otherwise would be security theatre.
What the label does:
- it lets
GET /v1/pricing?audience=agentreturn the plans meant for machine buyers; - it groups these tiers in the pricing document and the dashboard;
- it signals the intent behind the tier's shape — one account, metered, best effort.
What it does not do: restrict who may buy. A person may buy Agent Metered; an agent may buy Builder. Nothing checks.
Differences that are real
| Agent tiers | Human tiers | |
|---|---|---|
| Purchasable in one payment | Yes — including via x402 | Yes |
| Period | Metered has none | 30 days |
| Simulation before relaying | Opt-out, at the account's own Relay Unit risk | On by default |
| Service class of the entry tier | Best effort | Shared pool |
The simulation difference is the one to think about. Pre-flight simulation catches a transaction that would revert, before it costs you the units — a person usually wants that. An agent running a tight loop may prefer the latency and accept that a reverting call still costs its full worst case. It is a choice, not a default we made for you.
Buying without a person
Three ways, described in full in the agents section — two of them usable today:
| Way | When |
|---|---|
| On-chain purchase | The agent holds a key and can sign. One depositAndSubscribe call — and the purchase itself is relayed for free, so it needs no EGLD. |
| x402 | The agent speaks HTTP 402. Challenge, pay, retry; the plan exists when the call returns. x402 |
| MCP | The agent is an MCP client. prepare_subscribe and buy_plan_x402 are specified for this but do not execute yet; until they do, an MCP client uses the same REST routes. MCP tools |
All three end at the same contract call with the same price ceiling. There is no separate agent pricing path, no special rate and no discount that is not in the table above.
Rate classes matter more here
An agent is far more likely to hit a rate limit than a cap. Agent Metered is rate class 6: twice the sustained Relay Units per second of Starter's class 1, with the same burst, the same per-shard gas budget, the same 100,000,000 gas ceiling per transaction and the same hourly budget. Agent Pro is class 3, the class Growth uses.
If your traffic is bursty rather than voluminous, the rate class is the reason to move up, not the
cap. RATE_LIMITED carries a Retry-After and details.retryAfterMs;
back off on it rather than retrying immediately, and treat a sustained pattern of it as a signal to
change tier. (Limits · Errors and retries)
Agent Fleet
Configured, priced, and not purchasable yet: the throughput it commits to needs a larger relayer
float than is funded. available: false, unavailableReason: "CAPACITY", and
TIER_NOT_PURCHASABLE if you try. It will be announced in the
changelog when that changes.