Skip to content

Two-Option Cost Comparison

Two rate cards, each with its own fixed monthly fee, against one workload — with the request volume at which they cross over.

The workload

Option A

Option B

Option B is cheaper by
$2,850 / month

They cross at 29,851 requests a month. Below that, the option with the smaller fixed fee wins; above it, the option with the cheaper per-request cost does.

A — cost per request
$0.02
B — cost per request
$0.0027
A — fixed + usage
$0 + $3,900
B — fixed + usage
$500.00 + $550.00
A — total per month
$3,900
B — total per month
$1,050
Difference per month
$2,850
Difference per year
$34,200
Crossover volume
29,851 req / month
You are at
670.0% of the crossover
What this assumes: both options are billed on the same three meters — a flat monthly fee plus per-token input and output — and the workload is identical on both. That last part is the assumption to check hardest: if one option needs a longer prompt to reach the same quality, or produces longer answers, it is not the same workload and the comparison flatters it. The fixed fee is charged in full whether or not you use it, which is what creates the crossover. Rates are per 1,000,000 tokens. No overage rates, no tiering, no tax.

Two rate cards, one workload. The comparison is trivial arithmetic and people still get it wrong, almost always in the same way: they compare the input rates, notice one is six times the other, and stop. Input rate is one of five terms here, and on a workload with long outputs it is not the dominant one.

The crossover volume is the number worth linking to. Any option with a fixed monthly fee and cheaper usage beats a pure pay-as-you-go option only above some volume, and that volume is a single division: the difference in fixed fees divided by the difference in per-request cost. Below it you are paying a subscription for capacity you are not using; above it the subscription is a discount. Knowing where the line sits turns "which plan should we be on" into a fact about this month's request count rather than a preference.

What the arithmetic cannot tell you is whether the two options are actually interchangeable. Cost per request is only comparable if quality, latency and failure rate are close enough that you would ship either one. If the cheaper option needs three more retries per hundred requests, add them to its request count before you read the result. If it needs a longer system prompt or a few-shot block to hold quality, raise its input tokens — the honest version of this comparison usually means running the tool twice with different workloads on each side, not once with a shared one. And if the expensive option lets you drop a validation pass, that saved call belongs on its side of the ledger.

Two-Option Cost Comparison · Multigrid