Google defines Provisioned Throughput as "a fixed-cost, fixed-term subscription available in several term-lengths that reserves throughput for supported generative AI models." For Claude as a partner model, the pitch is simple: your reserved capacity is yours, and provisioned requests "are prioritized over the standard pay-as-you-go requests." You specify the model and the locations; Google guarantees the throughput. It converts a variable bill and variable availability into a fixed bill and predictable capacity — which is either exactly what you need or an expensive way to pay for idle reservation, depending on your traffic shape.
What you're actually buying
Three properties define the product:
- Fixed cost, fixed term. You pay a subscription fee for a defined term (several term lengths exist), regardless of whether you use the capacity. This is the opposite of on-demand's per-token metering.
- Priority over pay-as-you-go. During regional capacity pressure — the moments when on-demand traffic sees elevated errors or throttling — provisioned requests are served first. For a customer-facing product with an SLA of its own to meet, this predictability is often the real purchase, more than any unit-cost math.
- Sales-led purchase. For partner models like Claude you subscribe by contacting Google Cloud sales, not by self-serve console clicks. Pricing and minimum purchase sizes are quoted through that channel; Google's public docs don't publish a Claude rate card for it, so build your business case with real quotes.
The constraints that shape your architecture
Two documented limits matter before you talk to sales. First, Provisioned Throughput requires regional endpoints — it is not supported on the global endpoint or the us/eu multi-region endpoints, which are pay-as-you-go only. If you built on the global endpoint (a sensible default otherwise), adopting reserved capacity means re-pointing that workload to a specific region. Second, model coverage is a specific list: Google's pricing page currently names Claude Haiku 4.5, Sonnet 4.6, Sonnet 4.5, Sonnet 4, Opus 4.6, Opus 4.5, Opus 4.1, and Opus 4 as supported for Provisioned Throughput. Notably, that published list does not include the newest generation (Opus 4.8, Sonnet 5, Fable 5) as of this writing — check the current pricing page and confirm with your Google account team before assuming your target model qualifies.
A break-even framework (method, not magic numbers)
Because the subscription price is quoted, not public, do the comparison yourself. The logic:
- Compute your on-demand baseline. Monthly input and output tokens at the applicable rates — and use regional rates, since that's what provisioned throughput forces: regional endpoints carry a 10% premium over global list prices (for example, Opus 4.6-class models list at $5 input / $25 output per million tokens on the global endpoint). Include prompt-caching savings you already achieve.
- Get the quote for the throughput level that covers your peak, for each term length on offer.
- Find the utilization break-even. Fixed fee ÷ your effective on-demand cost per unit of traffic = the sustained volume at which the subscription is cheaper. If your realistic average utilization of the reserved capacity sits well above that point, the reservation pays; if your traffic is spiky with a low average, you are buying priority, not savings — which may still be worth it, but call it what it is.
- Model the hybrid. A common pattern is reserving for the steady base load and letting bursts spill to pay-as-you-go (or shifting deferrable work to Google's Vertex batch prediction for Claude at 50% of on-demand). Compare that blend against 100% on-demand and 100% reserved.
Where to go next
Work the general economics in the provisioned-throughput payoff analysis, compare with committed-use negotiation in committed use on Vertex, and revisit endpoint strategy in the endpoint decision guide — reserved capacity and the global endpoint are mutually exclusive.