I finally hit the SuperGrok limit

August 17, 2026 4 min read

I finally used all of the weekly allowance on my $30/month SuperGrok plan. I had to work at it.

This was not a normal week that happened to end at 100%. I kept Grok Build busy across several real projects, ran long coding sessions, and deliberately leaned on it instead of switching tools. The result made the plan look like good value to me, not a stingy limit.

The useful question is not “how many tokens does SuperGrok include?” xAI does not publish the allowance that way. The useful question is what work my local tools recorded before the shared weekly meter reached 100%.

The week

The weekly window ran from 2026-08-10T02:53:15.569Z inclusive to 2026-08-17T02:53:15.569Z exclusive. Mission Control’s Fedora hub first recorded the shared Grok weekly meter at 100% on 2026-08-14T15:41:09.203Z. The five-minute quota snapshots stayed at 100% and carried the same reset timestamp.

That first snapshot is an observation bound, not the exact second I crossed the line. Quota collection began after the meter was already full. I know it was full by that timestamp, but I cannot recover the earlier crossing time from the retained data.

xAI’s Grok usage FAQ describes one compute-weighted weekly pool shared by API, Build, Chat, Imagine, and Voice. A long coding task consumes more than a simple chat message. The account Usage page shows the percentage and reset schedule, but it does not expose a fixed token or prompt allowance. The current xAI pricing page lists SuperGrok at $30/month.

What Mission Control recorded

I queried /api/consumption/agent-usage on the Fedora / Strix Halo Mission Control hub for that exact UTC window. I did not use the partial database on my laptop.

Measure	Recorded
Sessions	31
Usage/request facts	8,157
Input tokens	9,658,311
Output tokens	1,230,939
Cache-read tokens	305,716,608
Cache-write tokens	0
Session cost	Unset

The 8,157 figure is Mission Control’s count of usage and activity facts. It is not a count of prompts, provider requests, or billable API calls. One agent turn can produce many recorded facts.

Cache-read tokens are separate too. They describe context reused by the agent sessions, not 305 million fresh input tokens. xAI’s API rate-limit documentation says cached prompt tokens count toward API tokens-per-minute limits, but that does not tell me how the SuperGrok subscription pool weights cached context.

Model mix

Most of the token-bearing work used grok-4.6-build:

Model	Sessions	Input	Output	Cache read
`grok-4.6-build`	23	6,997,972	1,003,963	252,998,656
`grok-4.5-build`	7	2,660,339	226,976	52,717,952

The source rollup has 31 distinct Grok sessions. The token-bearing model rows above account for 30 session memberships, while zero-token and unknown-model facts overlap the source sessions. I am not adding those model rows and presenting the result as a second distinct-session total.

The work behind it

The project breakdown looks like a week of coding, not a synthetic load test:

Project	Sessions	Input	Output	Cache read
Mission Control	12	3,812,710	474,146	148,067,840
Betting intelligence platform	7	1,661,249	322,504	45,661,056
bshp	4	2,286,643	186,312	59,529,600
Model prompt tests	3	1,108,536	176,872	42,143,744

Mission Control was the biggest slice. That work included the observability code used to produce this extract. The other large pieces were application work, this site, and model evaluation. There were smaller sessions in agent-skills-plugin, opportunity-scout, and benbishop-context too.

Project session counts can overlap when a session contributes facts with different attribution, so this table is a set of recognizable slices rather than another total.

What 100% does not mean

It would be tempting to turn these numbers into “SuperGrok includes 9.66 million input tokens” or “the limit is 305.72 million cached tokens.” Neither claim follows from the evidence.

The shared pool is compute-weighted across several products. Mission Control records local Grok Build activity and the shared weekly percentage, but the retained quota snapshots do not contain the Usage page’s per-product breakdown. I cannot prove that Build alone consumed the whole allowance. I also cannot reconstruct xAI’s private weighting formula from local token counters.

Mission Control’s session costUsd is unset for Grok. The logs contain internal usage-shaped fields, but they are not an invoice and I am not converting them into an API-equivalent dollar figure. Subscription usage, API pricing, and local agent telemetry are three different datasets.

The narrow claim is enough: this is the coding-agent workload recorded during the weekly window in which my shared SuperGrok pool reached 100%.

Was it worth $30?

For me, yes. Thirty-one agent sessions in a week included substantial work across multiple repositories. I reached the cap only after choosing Grok repeatedly and running several long tasks. On lighter weeks I had not come close.

That does not make the limit universal. Different products consume the shared pool at different rates, and xAI can change plans or weighting. It does give me a concrete answer for this one week: I got enough real coding work from the included allowance that hitting 100% felt more like a successful stress test than a reason to complain.