A subscription is a bet. You pay a fixed amount every month because you expect to use a tool often enough, or need it available often enough, that the average cost per use comes out ahead of paying per use. That bet only makes sense for a decision-maker who thinks in months: a person budgeting a team's tool stack, renewing or cancelling once a billing cycle.
An AI agent doesn't think in months. It thinks in actions. An agent drafting a follow-up email doesn't ask "is this subscription worth it this month" - it asks "can I justify this one call, right now, given what's in the task." That's a per-call question, and a per-call question needs a per-call price.
A monthly API plan bundles a quota of calls into one price, then charges overage past that quota. Two things break for an agent:
There's a second-order effect too: a subscription typically requires signup before the first call - an account, an API key, sometimes a card number - just to find out whether the tool is worth using at all. An agent (or the process that spawned it) can't complete that signup flow on its own in most cases; a human has to do it ahead of time and hand the agent a key. Pay-per-call collapses that step: the first call an agent ever makes can also be the one that pays for itself, with nothing provisioned in advance.
Pay-per-call fixes both problems above by attaching the price to the request. DimeBox charges per action - a draft, a send, a priority receive - with no subscription required for any of it and no API key to provision before the first call. The price is stated up front as part of the call itself, via a 402 response that names the exact amount, rather than living in a plan a human picked weeks earlier. See the API reference for the current price on every route.
This only works because the payment mechanism is designed to travel with the HTTP request instead of living behind an account. x402's exact scheme lets a caller sign a payment for one specific call and attach it as a header; there's no session, no stored card, no plan tier to look up server-side. HTTP 402 existed for exactly this since the beginning of the status code registry - it just didn't have a payment rail that made per-call settlement practical until stablecoins on cheap chains showed up.
Callers who'd rather not sign a crypto payment on every call still get the per-call pricing - they fund a wallet once with a card and authorize calls with a bearer secret instead of a signature. Same per-action prices, same no-subscription-for-the-core-product deal, just a different authorization mechanism. See how the wallet works and the DimeBox wallet page for setup.
Per-call pricing isn't universally cheaper - it's just differently shaped. An agent that drafts and sends a handful of emails a week will almost always come out ahead paying per call instead of committing to a plan sized for heavier usage. An agent sending hundreds of emails a day, every day, is a different case: at high enough volume, the per-call total can exceed what a flat-rate plan would have charged, and the operator running it has a predictable enough workload to actually use a subscription's guarantees.
That's part of why DimeBox's wallet supports an optional monthly subscription on top of the per-call prices - not a subscription that replaces per-call billing, but one that waives a one-time setup fee for callers who know they'll be funding the wallet regularly anyway. It's a convenience on top of per-call pricing, not a return to seat-based SaaS. See why DimeBox doesn't price around seats for the fuller argument, and a side-by-side look at subscription email tools vs pay-per-call if you're choosing between the two models for a specific workload.
The deciding factor isn't "subscriptions are bad" - it's who's making the pricing decision. A person picking a tool for a team reasons in months and budgets. An agent executing a task reasons in actions and marginal cost. Price the thing the way the caller actually thinks about it, and a lot of the friction in agent-facing billing disappears on its own.