Cost Optimization & FinOps

On-Demand vs. Reserved Capacity: A Decision Framework

Pay-per-token is the default everywhere Claude runs. Reserved capacity trades flexibility for predictability — and whether that trade wins depends on five factors, not on discount folklore.

Claude 3P 101 · Updated July 2026 · Unofficial guide

Every Claude platform bills on-demand by default: per-token, no commitment, scale to zero. The reserved alternatives differ by platform. Amazon Bedrock offers Provisioned Throughput — fixed-cost hourly billing per Model Unit (each delivering a defined input- and output-tokens-per-minute level), with no-commitment, 1-month, or 6-month terms, where longer commitments carry lower hourly prices. Google Vertex AI offers its own Provisioned Throughput, a fixed-cost, fixed-term subscription (regional endpoints only; arranged through sales) whose requests are prioritized over pay-as-you-go. On the first-party side, Anthropic's Priority Tier is closed to new purchases — existing commitments run to contract end — and Microsoft Foundry documents no reserved option: CCU billing is postpaid pay-as-you-go with no prepaid credits. Note that committed-use discounts on marketplace platforms are negotiated with the cloud provider, not Anthropic, and no discount percentages are published — so the framework below deliberately avoids assuming any.

Factor 1: volume predictability

Reserved capacity bills whether you use it or not. It only makes sense where a floor of traffic is genuinely constant — a 24/7 production workload with a stable baseline. If your volume is spiky, seasonal, or still growing unpredictably, on-demand's scale-to-zero property is worth more than any fixed rate; idle Model Units are the most expensive tokens you'll never process. The workable hybrid: reserve the floor, let bursts overflow to on-demand (Priority Tier commitments, for instance, automatically fall back to standard tier on overflow).

Factor 2: latency requirements

Reservation buys priority, not just price structure. Vertex's provisioned requests "are prioritized over the standard pay-as-you-go requests"; Anthropic's Priority Tier "prioritizes requests in this tier over all other requests," minimizing overloaded-server errors. If your workload is customer-facing and 529-style overload errors are business incidents, reserved capacity is partly an availability purchase — evaluate it against your latency SLOs, not just your invoice. Batch-tolerant workloads, by contrast, get a guaranteed 50% discount on-demand and should almost never be the traffic justifying a reservation.

Factor 3: budget horizon

Finance teams often prefer a fixed monthly number over a variable one, even at equal expected cost. Reserved capacity converts opex volatility into a predictable line item — valuable for annual budgeting, less so if your organization re-forecasts quarterly anyway. Match the term to your planning horizon: Bedrock's 1-month term is a cheap way to test the model before a 6-month commitment.

Factor 4: contract flexibility

Model generations move fast. A reservation is typically bound to a specific model (Priority Tier commitments name a model version; Google's supported-model list for Provisioned Throughput covers Haiku 4.5, the Sonnet 4.x line, and Opus 4.x models — check current coverage for the newest generation). Committing for six months to a model you may want to migrate off in three is a real cost. Shorter terms, and reserving only for workloads with stable model choices, keep the option value.

Factor 5: feature access

Reserved capacity narrows features. On Bedrock, inference profiles do not support Provisioned Throughput, and AWS's batch inference is not supported for provisioned models. On Vertex, Provisioned Throughput requires regional endpoints — no global endpoint, which also intersects with the 10% regional pricing premium structure. Priority Tier is not available on Claude Sonnet 5 at all. If the roadmap needs those features on the reserved traffic, on-demand wins by default.

FactorFavors on-demandFavors reserved
VolumeSpiky, growing, uncertainStable 24/7 floor
LatencyBatch-tolerantStrict SLOs, overload-sensitive
BudgetRe-forecast oftenFixed annual number required
FlexibilityModel choice in fluxModel locked for the term
FeaturesNeeds batch, inference profiles, global endpointsPlain high-volume inference
Sequence matters: exhaust the published on-demand levers first — batch (50%), prompt caching (0.1x reads), and model right-sizing — then price a reservation against the optimized baseline. Reserving capacity to serve an unoptimized workload locks in the waste.

Where to go next

Platform specifics live in Bedrock Provisioned Throughput and the provisioned-throughput payoff model; committed-use negotiation context is in committed use on Bedrock.

Sources