Skip to main content
Lesson 6 of 14 · Grok for Large Enterprises

Units and TPM Allocations per Model

Lesson 6 of 14 Updated November 2, 2026 Intermediate
On this page
  1. Why Units Vary in Value
  2. Allocations by Model
  3. Reading the Table
  4. Translating This Grid into Decisions
  5. Key Takeaways

Updated November 2, 2026 — flagship model. Grok 4.5 is no longer the most capable model: Grok 4.6 (August 12, 2026) and then Grok 4.7 (grok-4.7, September 21, 2026) replaced it, with 500,000 context tokens, reasoning effort from low to xhigh, and the same tiered pricing ($2 / $6 under 200,000 prompt tokens, $4 / $12 above). grok-4.5 remains available; for a new project, start with grok-4.7 (course Grok in 2026, lesson 9).

Why Units Vary in Value

We’ve established that a provisioned throughput unit costs the same regardless of the model. What changes is what you get: each unit grants a specific number of tokens per minute, depending on the model you choose. This variation isn’t arbitrary—it reflects the model’s computational complexity. The more compute a model requires to produce a token, the fewer tokens a unit can deliver per minute.

A second distinction structures the table below: allocations are split between input tokens and output tokens because generation costs significantly more than ingestion. Reading a 1,000-token prompt and writing 1,000 tokens don’t require the same infrastructure effort, and the pricing grid accounts for this.

Allocations by Model

Here are the TPM allocations per unit for the main models available in provisioned throughput (indicative values — consult the official xAI documentation for up-to-date allocations for each model):

Model Input TPM/Unit Output TPM/Unit
grok-4.5 2,000 400
grok-4.3 21,000 12,500
grok-4.20-0309 (non-reasoning) 3,000 700
grok-4.20-0309 (reasoning) 3,000 700
grok-4.20-multi-agent-0309 3,000 700
grok-build-0.1 31,500 4,000

Reading the Table

You can spot high-end models immediately by their low allocations. The grok-4.5 and grok-4.20 models are the most powerful, making them the most compute-intensive, so they offer the least TPM per unit: 2,000 to 3,000 input, 400 to 700 output. Reserve them for tasks that truly require advanced reasoning. The gap with the rest of the range is large enough that undifferentiated use gets expensive—the next lesson shows this with hard numbers.

At the other end, grok-build-0.1 reaches up to 31,500 input TPM and 4,000 output TPM per unit, the highest input throughput in the range. Specialized for code generation, it offers the best throughput-to-cost ratio for development workflows. Its profile matches this type of load exactly: a service that reads large source files to propose fixes consumes heavily on input and relatively little on output.

In between, grok-4.3 delivers 21,000 input TPM and 12,500 output TPM per unit. It’s the only model in the table with generous output capacity, making it particularly suited for simple, high-volume tasks—classification, extraction, summarization—where you produce a lot of text from a modest context.

Translating This Grid into Decisions

In practice, the goal is to match each use case to the model whose allocation profile fits best. A customer support service, internal chatbot, classification pipeline, or any high-volume processing will rely on grok-4.3. Complex analysis, advanced writing, and multi-agent scenarios justify grok-4.20. Code generation and development workflows point toward grok-build-0.1.

You don’t have to make a one-size-fits-all decision at the enterprise level. You can provision several models in parallel and isolate them in distinct capacity pools, using the x-pt-id header to direct each request to the corresponding pool. This way, a single platform can serve an economical chatbot and a premium analysis engine without the former consuming the capacity reserved for the latter.

Key Takeaways

  • TPM allocations vary significantly by model: from 2,000 to 31,500 input TPM per unit
  • Unit cost remains constant at $10/day, TPM varies
  • grok-4.3 and grok-build-0.1 offer the best throughput-to-cost ratio
  • Combine multiple models to optimize costs by task type