The X Subscription pools eligible first-party Grok usage across chat and Cursor on a weekly allowance with a live meter and reset. Teams still need to watch the boundary: third-party models and usage beyond the included pool require separately paid top-ups.
Summary
xAI’s X Subscription combines Grok, Grok Bot, Cursor and X Premium, with monthly tiers listed at $0, $8, $30, $100 and $200. Its included Grok allowance is weekly, applies to eligible first-party usage across Grok and Cursor, and can be tracked on a live meter before resetting. Third-party Cursor models and usage beyond that pool are paid separately through top-ups. The practical question for teams is therefore not simply how much the bundle costs, but how work gets routed as the shared allowance runs down.
What happened
The announcement describes a shared weekly pool for eligible first-party Grok-model use across Grok and Cursor, with a live usage meter and reset. That makes the allowance a movable budget: demand from chat can reduce what remains for coding, and vice versa. The boundary matters. Third-party models in Cursor do not draw from the included Grok pool, and use beyond the included allowance is separately paid through top-ups. xAI lists monthly tiers at $0, $8, $30, $100 and $200; these prices alone do not establish how much work a team can complete. New customers can subscribe, while existing SuperGrok, Cursor and X Premium subscribers can retain their plans or switch when offered in billing settings. The global rollout is described as beginning over the next few days.
What the archive adds
The archive describes Grok Bot as an early autonomous-agent product, placing this bundle within xAI’s expansion beyond chat. The dossier says AP reported that Cursor brings distribution among expert software developers and has faced compute constraints; that context makes the pairing strategically plausible, but does not prove why xAI chose this precise allowance design or how it will perform. The archive supplies no adoption results for pooled subscriptions. These precedents help frame the move, not settle its economics.
Trend signal
AI providers are packaging multiple work surfaces while retaining different metering rules beneath the subscription. Here the included weekly Grok pool spans chat and coding, but third-party model calls and overages cross into separately paid top-ups. The result is a shift from choosing among separate product bills to managing allocation and routing within a shared allowance. A live meter improves visibility, but does not itself decide which tasks should consume the pool or who can authorize top-ups.
Why now
Three pressures plausibly explain the timing and design. First, according to the dossier, AP reported that Cursor brings distribution among expert software developers, giving xAI a route into coding workflows. Second, AP reported that Cursor has faced compute constraints; access to xAI infrastructure may make the partnership commercially useful. Third, xAI is packaging Grok, Cursor and X Premium together, and the announcement’s shared weekly allowance provides a mechanism for cross-product use. The latter is an inference about strategy, not a stated motive.
Connections to other events
The concrete implication is that a team’s model-routing policy now affects how far its included allowance stretches. A developer may use first-party Grok in Cursor while the pool remains, then face a separate top-up for over-limit usage or a third-party model. According to the dossier, AP reported that Cursor brings expert-developer distribution and has faced compute constraints; one plausible motive is to connect that developer reach with xAI’s model usage and infrastructure. The weekly meter gives teams a way to observe depletion, but only controls over routing and top-ups can turn that visibility into predictable spend.
Why it matters
Teams should treat the included pool and paid top-ups as separate budget categories, even though they appear within one subscription relationship. Agree which tasks should use first-party Grok, who may select third-party Cursor models, and who approves top-ups when the weekly pool is exhausted. The live meter can inform those decisions during the week; it cannot substitute for clear ownership of model choice and spend. Buyers should compare the offer with their current plans only after checking the actual allowance and top-up controls in their account.
What happens next
- The live meter and reset will lead some teams to manage first-party Grok use across chat and coding as a shared weekly budget rather than as independent product usage. (3 months, 65%). Watch for: Account guidance or customer reports describe users monitoring the shared meter and shifting Grok tasks between chat and Cursor during a week.
- Top-up authorization and visibility will become a material adoption question for team buyers using Cursor models beyond the included pool. (6 months, 60%). Watch for: Team documentation or customer discussions specifically address who can trigger top-ups and how those charges are surfaced.
Limits and uncertainty
The evidence does not establish the allowance quantity, its precise task-level eligibility beyond the stated first-party pool, or how administrators can constrain top-ups. The listed tiers do not show whether a particular team’s usage will fit. The dossier’s account of Cursor’s developer distribution and compute constraints is reported context, not evidence of the bundle’s adoption or xAI’s internal motive. This analysis could be wrong if most teams rarely exhaust the pool or if their work seldom uses third-party models.
Skill to build now
Build a one-week routing log against the live meter: record eligible first-party Grok tasks in chat and Cursor, note the pool before and after, and flag every third-party-model call or top-up. Use the results to draft a simple team rule for who can route to paid usage and who approves it.
Reader takeaway
This week, use the live meter during a representative coding-and-chat workweek. Record when eligible Grok usage draws down the shared weekly pool, what remains at reset, and when a task uses a third-party model or requires a top-up. Then test the account’s available top-up controls and assign an approver before moving a team onto the bundle.
Open question
Can team administrators set meaningful limits or approval rules for third-party-model and over-pool top-ups, or does the live meter inform users without giving managers control over the separate spend?