There is no free way to send outbound mail through DimeBox. Every send — drafted or raw — goes through the same priced route, $0.01 per call, whether it's one email or the start of a loop that fires a thousand of them. That's not an oversight waiting to be fixed with a free tier later; it's the point.
Receiving mail can be free because the cost of accepting an incoming message is small and bounded — it either lands in the inbox or it doesn't, and an inbox has a fixed rolling cap on how much it can hold regardless. Sending is different: an outbound email leaves DimeBox's infrastructure and lands in someone else's mailbox, on someone else's domain reputation. A free, unmetered send endpoint would be an open invitation for exactly the traffic that gets domains blocklisted — volume sending with no cost attached to trying again, and again, and again.
A traditional API controls abuse with a rate limit: so many calls per minute, enforced by a counter. A per-call price does something similar without needing a separate throttling system — every additional send costs the caller something real, which naturally damps runaway loops in a way a free endpoint never does on its own. An agent with a bug that calls send in a tight loop burns through its wallet balance or needs to keep signing payments; it doesn't get to send mail indefinitely for nothing. See why charging in cents changes how agents behave for the broader argument.
This also means abuse resistance doesn't depend on DimeBox correctly detecting bad behavior after the fact. A rate limiter has to recognize a pattern as abusive before it acts, which means some abuse always gets through before detection catches up. A price is in effect before the first call even goes through — there's no detection lag, because the deterrent is the same on call one as it is on call ten thousand.
The one case where a send call is never charged is when it fails — a 422 for a bad request, or any other response above 400, settles no payment at all. The rule is the same across every paid DimeBox route: payment only settles on a response under 400. See why DimeBox never charges for a failed API call for the mechanics. This matters here specifically because it means the cost of sending is tied to actually sending, not to the act of attempting to.
If an agent's design assumes it can send speculatively — draft three variants and send all of them to see what lands, or retry a send on a hunch rather than a real failure — that design gets expensive fast, on purpose. The cheaper pattern is to decide what to send once, with a tight brief, and send it once. How much does it cost an AI agent to send one email walks through the actual per-message math; why micropayments finally make sense for machine-to-machine commerce covers why a price this small is still worth charging at all.
Rolling your own SMTP relay instead of paying per send doesn't make sending free — it moves the cost into infrastructure, domain reputation management, and deliverability tuning that someone still has to pay for and maintain. DimeBox vs rolling your own SMTP + LLM stack covers that tradeoff directly. A per-call price just makes the cost visible at the point where the decision to send gets made, instead of hiding it in a bill that shows up later.
This holds even during development: there's no sandbox mode that sends real mail for free. What exists instead is Base Sepolia, a separate network where the USDC being spent is test currency with no real value — the send call itself still goes through the same payment gate and the same $0.01 price, it's just paid for with money that costs nothing to acquire. See testing agent email flows end-to-end on Base Sepolia for how that works in practice. The payment gate itself is never bypassed, even in a test environment — which is deliberate, since it means test runs actually exercise the real code path instead of a separate, unpriced one that could drift from production behavior.
A one-line reply and a long drafted message both cost the same $0.01 to send — the price attaches to the act of sending, not to the length of what's inside it. That's a deliberate simplification: metering by message size would add a second variable for a caller to reason about, for no real reduction in the underlying cost of sending one more message through the outbound path. No subscriptions, no seats covers the broader pricing philosophy this fits into — a flat per-action price instead of a bundle of variables to optimize against.