A single agent making its own purchasing decisions is already an unusual thing to budget for - there's no approval step, no purchase order, no person in the loop deciding whether a given call is worth it. A fleet of them multiplies the problem without multiplying the tools most teams already have for controlling spend. Seat-based budgeting doesn't apply (there are no seats), and a shared company card doesn't give you per-agent visibility. What actually works is budgeting at the level the payment system already operates: per call, per wallet, per day.
Every action an agent can take through DimeBox has a known, fixed price: $0.02 to draft, $0.01 to send, $0.03 for a priority receive, $1.00 once to claim a named inbox. That means a daily ceiling for one agent isn't a guess - it's call volume multiplied by price. An agent expected to send 50 follow-ups a day at $0.01 each has a $0.50/day send budget, full stop, independent of whatever else is happening in the task. See the itemized cost of a single email to build that per-action math for your own workload before trying to budget a whole fleet.
There's no "fleet plan" to buy. The controls that exist live on the wallet: a daily spend limit that caps total spend regardless of how many calls that takes, and auto-reload that tops up a wallet once its balance crosses a threshold so an agent mid-task doesn't stall on an empty balance. See setting daily spend limits and how auto-reload works. Together those two settings are the actual budgeting primitive for an unattended agent: a floor that keeps it running and a ceiling that keeps a bug from running up an unbounded bill while nobody's watching.
This is the real design decision, and it's a tradeoff, not a default. A wallet per agent gives you budget isolation: a daily limit on agent A's wallet can't be exceeded by anything agent B does, and if agent A starts misbehaving, its own cap is the blast radius. The cost is operational - funding and monitoring N wallets instead of one. A single shared wallet across a fleet is simpler to fund and reload, but a daily spend limit on it caps the whole fleet together; one agent calling aggressively can consume the budget that was meant to cover all of them, and there's no per-agent attribution inside a shared balance after the fact.
There isn't a universally correct answer here - it depends on whether you need to isolate one agent's failure from the rest of the fleet's budget, or whether simplicity of funding matters more than isolation. Either way, the decision should be made explicitly, not defaulted into by whichever wallet secret happened to get copied into the most agent configs.
New wallets start capped - $50 balance and $10 per day for the first few days - as an anti-fraud measure. See why new wallets start capped. If you're standing up a fleet for the first time, that cap applies to every new wallet you create, which matters for planning: a fleet that needs to spend more than $10/day per wallet on day one needs to account for a ramp period, not assume full-scale spend is available immediately.
None of this requires a wallet at all - an agent that already holds its own USDC key can sign x402 payments directly, call by call, with no daily limit imposed by DimeBox at all (the discipline has to come from the agent's own logic in that case). See a comparison of API keys, wallet secrets, and x402 signatures for which authorization model fits which kind of fleet. A wallet trades some of that flexibility for built-in spend controls; direct signing trades the controls for not needing a prefunded balance sitting idle at all. Budgeting for a fleet is ultimately a choice between those two tradeoffs, made per agent or per fleet, not a plan you buy off a pricing page.
Because every charge is tied to a specific action - a draft, a send, a receive - a wallet's own transaction history doubles as a per-agent activity log, not just a balance number ticking down. See the full lifecycle of a wallet, from checkout to ledger for where that record lives. A fleet operator checking that ledger after the fact can reconstruct exactly what each wallet paid for, which is a very different debugging experience than reconciling a flat monthly invoice against a vague sense of "usage."
One more thing worth building into any fleet budget: failed calls never count against it. A wallet's daily limit and balance only move on calls that actually succeed, so an agent stuck in a bad retry loop against a validation error isn't silently draining the fleet's budget - it's just failing, for free, until whatever's wrong with its request gets fixed.