The sticker price of giving an agent an email identity is small and mostly optional: free for a random slug, $1.00 one time if you want to pick the name yourself. That number answers the wrong question. The real cost of an agent having an email address isn't the cost of creating the address - it's the cost of everything that address then does.
POST /api/inboxes hands back a random adjective-noun-number slug for free, throttled to three per IP per day so the free tier isn't a way to mint unlimited identities. POST /api/inboxes/claim lets you pick the exact name for $1.00, paid once. See provisioning an inbox in one call and how claiming a custom name works for the mechanics. Either way, the inbox itself doesn't carry a recurring cost - there's no monthly fee for the mailbox existing, no storage tier, nothing that accrues just because an identity is sitting there unused.
That's a deliberate design choice, not an accident: an identity that cost money to merely hold would push toward hoarding fewer, shared identities across agents, which undercuts the whole point of giving each agent its own address. An agent inbox isn't trying to be a full mailbox - it's closer to a disposable, purpose-built identity than a Gmail account, and disposable identities need to be cheap to create.
Every dollar an agent's email identity actually costs comes from use, not existence:
/api/emails/generate, or is folded into a $0.01 send call if the inbox has AI drafting enabled and the request includes a purpose instead of raw text./api/inboxes/{slug}/send, regardless of how the body was produced.GET /api/inboxes/{slug}/messages - is free, gated only by the read token, not by payment.See a full itemized breakdown of what one email actually costs end to end for the arithmetic on a single message. The point here is structural: the identity is the free part, and the correspondence is the priced part. That's the inverse of a human email seat, where the account itself is the thing you pay a license for and sending as many messages as you want is included.
This also changes who bears the cost of an agent that misbehaves. A seat-licensed human mailbox costs the same whether the person sends five emails a day or five hundred; the operator eats that variance inside a flat fee. An agent's inbox under pay-per-call pricing bills exactly for what it does - a loop that sends too often is visible immediately as a cost spike, not absorbed silently into a subscription nobody's watching closely enough to notice.
Because the fixed cost of an identity is close to zero, the question worth asking before deploying a fleet of agents isn't "can we afford N inboxes" - you almost certainly can, at $0 or $1 each. It's "can we afford what each of those inboxes will actually send and receive once it's doing real work." Ten thousand idle inboxes cost roughly nothing. One inbox sending and receiving constantly runs up a real, visible bill at $0.01-$0.03 per action. See budgeting for a fleet of agents that pay their own way for how to think about that at scale, and how the wallet lets you fund that ongoing activity without signing a payment on every single call.
Strip away the per-action prices and what you're paying for, structurally, is three things: a working address an agent can send and receive at, a credential (the read token, shown once) that controls who can read it, and - if you want it - a name you chose instead of a random one. None of that includes a correspondence quota. An agent that provisions an inbox and never uses it has paid at most $1.00, ever. An agent that drafts and sends constantly has effectively chosen a different cost structure entirely, one that scales with what it does rather than with who it is. That's the whole argument for pricing identity and activity separately instead of bundling them into one subscription number nobody can reason about in advance.
It's also why DimeBox restricts which names you can claim for that one-time fee: reserved, phishing-prone slugs like admin, support, or billing are rejected outright, regardless of payment. See how reserved names are blocked. That restriction isn't about cost at all - it's a reminder that the dollar you're paying buys a name, not trust, and the two are kept deliberately separate.
Even heavy use doesn't make the inbox itself more expensive to keep. The message history is a rolling window, not an unbounded archive - older messages are pruned once an inbox passes its cap, so an identity that's been live and busy for a year doesn't carry a bigger fixed cost than one created yesterday. See how that pruning window works. The entire cost structure stays activity-priced, never storage-priced.