What email actually costs when your agents send it

Email looks cheap per message, which is why people budget for it badly. The line item is small and the surrounding costs are not: the tokens spent reading threads, the weeks spent building the parts a mail API does not give you, and the occasional expensive month where a sending domain has to be rebuilt.

27 July 2026 · 5 min read

What you are billed for#

Three axes, and most people only think about the first.

Messages. Sends draw down a monthly allowance, and both replies and cold sends draw down the same one. On MCPmailer that is 3,000 a month on Free with a 100 a day ceiling, 10,000 on Pro, and 150,000 on Startup, with overage metered at $0.001 an email on Pro and $0.0006 on Startup.

Inboxes. An identity per agent is the correct architecture, so the number of agents is a cost line. Three are included on Free, ten on Pro and then a dollar each, 150 on Startup.

Storage. Mail with attachments accumulates. 3 GB on Free with 30 day retention, 10 GB on Pro, 150 GB on Startup, and ten cents a gigabyte beyond that. Retention is unlimited on paid plans, which is a feature and a bill: archive what you have dealt with.

Current numbers and the full comparison are on the pricing page, also available as markdown if you would rather your agent read it.

Working an example#

A support agent answering 40 threads a day, roughly 1.2 replies each, is about 1,400 messages a month. One inbox. Attachments occasional. That fits inside Pro with room to spare, so the marginal cost of the agent is the plan, not the mail.

Now add a billing agent doing 600 chases and a scheduling agent doing 900 coordination messages. Three inboxes, about 2,900 messages, still inside Pro. This is the shape most teams land on: the cost is dominated by the plan and the agent count, not by volume, until volume becomes genuinely large.

At 150,000 messages a month you are in Startup territory, where overage is cheaper and the interesting question changes from price to whether that volume is conversational at all. Five recipients per message is a hard cap, and campaign-shaped sending belongs on campaign infrastructure.

The costs that are not on the invoice#

Tokens. This is usually the larger number and it is entirely within your control. A fifty message thread fed to a model whole, with quoted history, costs multiples of the same thread stripped and summarised. get_thread returns conversations without the quoted repetition for this reason, and extracting the fields you need from an attachment beats pushing a contract through a model every time the thread is revisited. See attachments.

Engineering. The parts a raw mail API leaves you: threading, quoted-history stripping, waiting for replies without a scheduler, suppression on bounce, idempotency under webhook retries, an oversight surface a non-technical colleague can read. That is weeks, and then it is maintenance forever. The comparison of building on IMAP or a provider API is in agent inbox or shared mailbox.

Reputation. The expensive one. A sending domain that gets filtered costs a quarter to recover, because reputation attaches to the domain and you cannot buy trust for a new one. Everything in deliverability for agent senders and the warmup plan is cheaper than the alternative.

Bad answers. A confidently wrong reply costs a support contact, sometimes a customer. This is why evaluation is a cost control and not a nicety.

Keeping the bill predictable#

• Set a monthly spend cap. Available on paid plans, and the single best protection against a loop that discovers it can send.
• Archive aggressively. Storage is the line that grows quietly, and archiving keeps list_messages useful at the same time.
• Count inboxes deliberately. One identity per agent is right; one per experiment that nobody turned off is not.
• Watch tokens per thread, not just messages per month. Long threads and whole attachments are where the real money goes.
• Alert on volume changes, in both directions. A spike is a runaway; a collapse is a broken webhook.

Free is a real tier, with a real edge#

Three thousand messages a month, 100 a day, three inboxes, and 30 day retention is enough to build the thing, run it against real mail for a fortnight, and decide whether it works. The daily ceiling is the constraint that bites first: an agent answering a busy inbox will meet 100 a day before it meets 3,000 a month, and the refusal says daily_send_quota_exhausted with the reset time rather than failing silently.

Move to a paid plan when the daily ceiling starts refusing work you wanted done, not before.

Questions#

How much does email for AI agents cost?

It is driven by messages, inboxes, and storage. Free covers 3,000 messages a month across 3 inboxes, Pro is $20 a month for 10,000 messages and 10 inboxes, and Startup is $200 for 150,000 messages and 150 inboxes, with metered overage beyond. See pricing.

Do replies cost the same as cold sends?

Yes, both draw down the same daily and monthly allowance. The difference is behavioural: a cold send carries an unsubscribe link and is watched by the duplicate-content and velocity tripwires.

What is the biggest hidden cost?

Usually tokens, then engineering time on the parts a raw mail API does not provide. The most expensive rare event is a damaged sending domain, which takes months rather than money to fix.

How do I stop an agent running up a bill?

Set a monthly spend cap, and alert on volume changes. A refused send returns monthly_spend_cap_reached, which the agent can act on rather than retry.

Does an inbox per agent get expensive?

At a dollar per additional inbox on Pro it is rarely the dominant cost, and the alternative, several agents sharing one identity, costs you attribution, scoping, and clean revocation.

Is there a free tier worth using?

Yes, and it is sized for exactly the right thing: building the agent and running it against real mail for a couple of weeks before committing.