Dedicated Capacity and Provisioned Throughput
On this page
Reserve Capacity Instead of Sharing It
Provisioned Throughput is the technical backbone of xAI’s Enterprise offering. The principle fits in one sentence: you reserve dedicated processing capacity for your Grok models, and your performance stops depending on the platform’s global load. All the value lies in this independence, and understanding it is key to deciding whether to activate it.
What You Face Without Reserved Capacity
In pay-as-you-go mode, your requests share infrastructure with every other API user. Most of the time, you won’t notice. The problem surfaces during demand spikes, and your operations teams will immediately recognize the symptoms. Response times increase, but worse, they become variable—which is far worse than constant slowness, because an interface designed for a two-second response behaves poorly when it sometimes takes eight. Rate limiting errors appear next, returned with code 429, and your application must then handle retries that further increase the latency perceived by the user. Occasional availability degradations can finally affect the service precisely when demand is highest.
Provisioned Throughput eliminates this exposure. Your requests are processed on capacity reserved for you, with guaranteed priority and much more consistent response times. You aren’t just shifting a cost; you’re shifting a risk: performance risk moves from your application to the provider.
Thinking in Units
You buy capacity in units, and this concept will return in every following lesson. Each unit corresponds to a token-per-minute allocation—TPM—for a given model. Critical for your calculations: input units, which process your prompts, and output units, which produce responses, are purchased separately.
The pricing grid, however, is disarmingly simple: $10 per unit per day, regardless of the model. The unit price never varies from one model to another, but the TPM that unit provides does. A very powerful model gives you little, a lighter model much more, and this gap creates the considerable cost differences we will quantify in two lessons.
Deciding Whether You Need It
A production application subject to strict latency requirements fits exactly the problem this mechanism solves, so there’s little reason to hesitate. Automated support finds itself in the same situation, with an additional argument: every second of wait translates to an abandonment or an incoming call you’ll need to handle another way. Real-time processing of large, predictable volumes is also a good candidate; predictability makes sizing reliable here. More generally, any application where interruption carries a high cost, measurable in dollars or reputation, justifies reserving capacity for it.
The reverse reasoning is just as useful to apply. A nightly batch process without time constraints gains nothing from reserved capacity: whether it finishes at 3:00 a.m. or 4:00 a.m. changes nothing, and pay-as-you-go remains frankly more economical. Same conclusion for prototyping and low volumes. If you’re still hesitating, ask yourself a specific question before committing to 30 days: over the last 30 days, how many hours per day did this service actually run at full load? An honest answer almost always settles the debate.
Key Takeaways
- Provisioned Throughput reserves dedicated capacity at $10 per unit per day
- Minimum commitment is 30 days
- 99.9% SLA is contractually guaranteed
- Performance is constant regardless of global platform load
- Pay-as-you-go remains preferable for low volumes and prototyping