Cost calculation and worked example

The formula

Provisioned throughput sizing comes down to simple addition. The daily cost looks like this:

Daily cost = (Input units + Output units) x $10

Next, determine how many units you need based on your TPM requirements and the model’s specific allocation:

Input units = Desired input TPM / TPM per model unit (round up)
Output units = Desired output TPM / TPM per model unit (round up)

Rounding up isn’t just accounting trivia. You can’t buy a third of a unit: if your needs exceed a multiple of the allocation by even a single token per minute, you pay for the whole unit. The following example shows what this looks like on a real bill.

A complete example: grok-4.3

Consider a customer support application requiring 100,000 input TPM and 50,000 output TPM on the grok-4.3 model. Let’s walk through the calculation step by step.

This model offers 31,500 input TPM per unit, giving us the input unit count:

100,000 / 31,500 = 3.17 → 4 units (round up)

Actual capacity obtained: 4 x 31,500 = 126,000 input TPM. Notice the rounding effect: you pay for 126,000 TPM even though you only needed 100,000. Those extra 26,000 TPM aren’t wasted—they form your buffer for traffic spikes—but they do appear on the bill.

On the output side, the allocation is 12,500 TPM per unit:

50,000 / 12,500 = 4.00 → 4 units

Actual capacity obtained: 4 x 12,500 = 50,000 output TPM. Here, the requirement lands exactly on a multiple of the allocation, so no capacity goes unused. This is just arithmetic coincidence, but it illustrates a useful habit: check whether a slight adjustment to your stated need crosses a unit threshold.

Now just add them up:

Daily cost = (4 + 4) x $10 = $80/day
30-day cost = $80 x 30 = $2,400

Comparing it to pay-as-you-go

This figure means nothing until you compare it against the cost of the same volume under usage-based billing. Suppose you actually consume 100,000 input TPM for 8 hours per day, 22 working days per month:

Monthly input tokens = 100,000 x 60 x 8 x 22 = 10.56 billion tokens

The corresponding cost then depends on the model’s per-token rate applied to this volume. If provisioned throughput comes out cheaper, the decision is made. However, price isn’t the only factor: reserved capacity also makes sense when you use it sustainably, more than 6 to 8 hours per day, when guaranteed response times condition the user experience, when platform traffic spikes visibly impact your application, or when a 99.9% SLA is an explicit business requirement. Any one of these reasons alone justifies the premium.

The cost of the wrong model

Let’s take the exact same requirement, this time on grok-4.20-0309-reasoning, a premium model:

Input: 100,000 / 3,000 = 34 units
Output: 50,000 / 700 = 72 units
Daily cost = 106 x $10 = $1,060/day
30-day cost = $31,800

Same application, same volume, and a bill jumping from $2,400 to $31,800 over thirty days. For a customer support chatbot, the fast model is very likely sufficient and costs 13 times less than the premium model. Remember this ratio: no prompt optimization, no commercial negotiation will ever recover a factor of 13 gained or lost at the model selection stage.

Sizing correctly

For your first provisionment, start modest. Begin with a low estimate and scale up: it’s easier to add units than to explain a budget overrun. Then monitor actual usage using the detailed consumption metrics provided by the Management API, which will tell you within a few days if your initial estimate held up. Still, plan for a 20 to 30% capacity margin to absorb spikes, otherwise a single unusual day is enough to saturate the allocation.

Know that a safety net exists: requests exceeding your allocation automatically fall back to pay-as-you-go. An overrun doesn’t cause service interruption; it produces an extra line on the bill—which remains, in most contexts, the desirable compromise.

Key takeaways

• The formula is simple: (input units + output units) x $10/day
• Always round up the number of units required
• Model choice has a major impact on cost: a 13x factor between fast and premium
• Provisioned throughput is cost-effective for sustained usage (6+ hours/day)
• Pay-as-you-go fallback automatically absorbs overruns