RPM and TPM per Model

Update November 2, 2026 — Imagine. grok-imagine-image-quality was removed on November 2, 2026: its requests are now served by Imagine Image 2.0 (grok-imagine-image-2.0, $0.04 per image) in low quality. Replace the identifier in your examples and set the desired quality; grok-imagine-image (version 1.0) is not affected. Imagine Image 2.0 accepts up to five reference images and the auto quality, which is now the default.

The Two Limiting Metrics

The Grok API doesn’t measure your usage with a single counter but with two, which trigger independently: RPM (requests per minute) and TPM (tokens per minute). You can be blocked by one while still far below the other’s ceiling. Critical for what follows: these two counters are tracked per model, so your limits on grok-4.5 have no effect on those for grok-4.3.

This distinction isn’t just documentation detail. It determines how you size your infrastructure, how you distribute load, and exactly where your service will start returning errors on a spike day.

RPM Caps the Number of Calls

RPM counts calls, regardless of their size: a ten-token request and a hundred-thousand-token request weigh exactly the same. Official model sheets express this in requests per second: 150 for grok-4.7 and grok-4.5 (9,000 per minute), 37 for grok-4.3 (2,220 per minute). This is sufficient for a standard conversational application.

RPM becomes the bottleneck as soon as your requests are numerous and short. A pipeline that classifies support tickets one by one, or extracts three entities per sentence across a document corpus, will exhaust its call quota well before approaching its token quota. In this case, the solution isn’t to ask for more RPM but to batch several items into a single call.

TPM Caps the Processed Volume

TPM sums input and output tokens over a sliding minute, with, according to official sheets, 50 million tokens per minute for grok-4.7 and grok-4.5, and 10 million for grok-4.3. The behavior here is exactly the inverse of the previous case: few calls, but very heavy ones.

Take a document analysis service that sends folders of 50,000 tokens each. On grok-4.3, the request ceiling would authorize 2,220 submissions per minute, but TPM stops at 200 documents: 200 × 50,000 = 10 million. You therefore saturate at about one-eleventh of your theoretical capacity in number of calls, and no parallelism setting will let you exceed this wall.

Limits Specific to Each Model

Ceilings aren’t the same depending on the nature of the model called, and you need to know this scale before promising throughput to a client.

These values are from the official model sheets as of November 2, 2026; your team’s effective limits display in the xAI console.

Since the counters are independent, saturating one model doesn’t block the others. If grok-4.5 returns 429s, grok-4.3 continues to accept your requests as if nothing happened. This is an often overlooked throughput lever: rather than waiting for a quota increase, route simple tasks—classification, extraction, short summary—to a less solicited model, reserve grok-4.5 for truly complex reasoning, and leave flux orchestrating several sub-agents to grok-4.20-multi-agent-0309. Your platform’s overall throughput then becomes the sum of several quotas instead of just one.

Monitoring Consumption Without Dedicated Headers

The Grok API returns no headers in its responses indicating how much RPM or TPM you have left. In other words, nothing will warn you of approaching the ceiling: the only way to know where you stand is to keep the accounting yourself, on the client side.

This tracking relies on three elements: a request counter per minute per model, a token counter fed by the usage object that every response contains, and an alert threshold triggered around 80% of limits. This last point is the most important: an alert at 80% leaves you time to adjust—distribute load, smooth submissions, trigger a tier upgrade—whereas an alert at 100% only confirms the incident in progress.

Key Takeaways

• Limits are measured in RPM (requests/minute) and TPM (tokens/minute)
• Text models offer 1,800 RPM and 10M TPM as standard
• Each model has its own independent limits
• Distributing load across models allows multiplying effective throughput
• Implement client-side tracking to anticipate limits