"A $20 subscription beats the API" has an honest math, and the most-argued 2026 versions of it got the conclusion right and the fine print fuzzy. The honest version: the $20 comparison is a human-versus-machine question, not a price question — and the boundary matters more than the break-even.
The math, stated once
Subscription: a flat monthly price, usage bounded by session windows (tokens draw against a session meter that tracks the model class in use), effectively "unlimited" inside human pacing. API: zero fixed cost, metered per token — structurally cheaper for light use, structurally unbounded for heavy use.
The break-even is the naive framing: at what token count does the $20 stop winning? The number you need is your monthly input-plus-output total, and it depends on the model class the subscription's session meter meters — which moves. Window definitions, model-class tracking, and plan structures all evolve, and API rates are comparatively stable and published. So do not store a break-even number; store the method: project next month's tokens at list price for your mix, compare to the flat price, repeat at every plan change.
That math — for a person at a keyboard, pacing review between steps, working in bursts inside a session window — holds.
Where the math breaks for apps
It breaks in six specific places, and no amount of averaging smooths them away:
- Limits are not your savings. Windows and weekly budgets are session limits: UX throttles, designed against the assumption that a human is at the keyboard. An app pointed at the same surface meets limits that kill a batch job at 3 a.m., with no human available to wait for the window to reset.
- Predictability. An app plans capacity, cost per request, and SLOs against rates. "Plans are set and mechanics change" is not a rate — session meters, model-class tracking, per-model caps: none of it is in an app's error-handling design.
- Programmatic keys are not one of these. Subscription usage is intended for interactive, human-operated use; infrastructure traffic on it is out of scope in the terms at every major provider. Routing a session key through a proxy returns rate-limit errors that direct requests do not — the mechanism announcing a duplicate problem you already have.
- Different 429 shapes. Rate limiting on the subscription path and on the API path are different error classes with different recovery semantics; an app written to the API's retry semantics misbehaves on the subscription's.
- The bill arrives differently. A person sees one line: $20. An app team needs per-key, per-task, per-hour attribution, and metering a subscription's session spends the time the flat rate was hiding.
- Scale along a different axis. A person grows linearly with keystrokes; an app grows super-linearly with concurrent users and agent steps. A break-even computed on personal usage says nothing about product traffic.
Where the math holds
The honest boundary is one rule: a request with a person in the loop goes to the subscription; a machine-originated request goes to the API.
- A person at a keyboard, developing with a coding agent, reviewing between steps: subscription. The flat rate is the right shape for human-paced, bursty work, and a window that forces a break is a feature for a person — natural pacing and a predictable cost ceiling — not a bug.
- A product's batch jobs, CI, scheduled agents, and live API: an API key. Metered tokens, no window, per-key caps as the ceiling — the one you set, resetting the way you set.
- A hybrid product: two pools, two budgets, two error semantics — session keys for the human surface, metered keys for the machine surface. Nothing is broken, nothing is out of scope, and each half of the bill explains itself.
The rule is per request, not per product: a single product's usage split across both surfaces gets classified per request and sent through its pool. What the API side costs per task is a budgeting question with three inputs — volume, shape, and mix; what this post settles is which side of the boundary each of your requests belongs to.
Flat-side prices are on the providers' pages. The metered side's — pass-through per-token, no markup, is on pricing — and a key to test both halves of the rule end to end is at signup.