SpaceXAI's X Search meter moves from calls to results on 21 September — and the number you now pay for is one the model picks, not you
TL;DR: From 21 September 2026, 12:00 PM PT, SpaceXAI bills X Search at $5 per 1k posts fetched and $10 per 1k user profiles fetched, replacing $5 per 1k calls. Break-even is exactly one post per call, so any real search costs more — a call returning thirty posts goes from $0.005 to $0.15. The counting rule includes parent and quoted posts, context pulled in by thread shape rather than by your query. The documented tool parameters — handle allow/deny lists, date bounds, media understanding — contain no result-count cap. Grok token prices are unchanged (grok-4.6 at $2/$6 per million under 200k, $4/$12 over). The change is narrow, it is a price rise, and it moves the forecastable part of the bill into the model’s hands. Three days’ notice.
What changed
One line on SpaceXAI’s pricing page, replacing another.
Until 20 September, X Search costs $5 per 1,000 calls. A call is a call: you issue a query, results come back, you are billed once regardless of whether the response contains two posts or two hundred. From 21 September at 12:00 PM PT, the meter reads $5 per 1,000 posts fetched and $10 per 1,000 user profiles fetched.
The counting rule is documented explicitly, and it is broader than the query: every post returned by a search or thread fetch, including parent and quoted posts, counts; every profile returned by a user search counts.
Nothing else on the rate card moved. grok-4.6 remains $2 per million input and $6 per million output below 200k context, $4 and $12 above it, with cached input at $0.50 and $1.00. grok-4.5, the grok-4.3 and grok-4.20 series, and grok-build-0.1 are all unchanged. This is a tooling charge, not a model repricing — which is exactly why it is easy to miss and worth a paragraph of arithmetic.
The arithmetic
Break-even is one post per call.
That sentence is the whole story. If an average X Search call returned precisely one post, the old and new bills would be identical. Every result beyond the first is new money, at a fifth of a cent each.
Run it against realistic shapes:
- A call returning 10 posts: $0.005 → $0.05. Ten times.
- A call returning 30 posts: $0.005 → $0.15. Thirty times.
- A profile search returning 10 profiles: $0.005 → $0.10. Twenty times.
A search API that returns one result is a lookup, not a search. The reason to call one is to get a page of matches, which means essentially every production workload sits on the wrong side of break-even by an order of magnitude or more.
None of this makes the new meter unfair. Per-result billing is a defensible way to charge for a data product — arguably a fairer one, since a caller retrieving two posts stops subsidising a caller retrieving two hundred. The point is narrower and non-negotiable: presented as granularity, it functions as a repricing, and any team modelling this as cost-neutral will be wrong by roughly the average size of its result sets.
The part you cannot control
Here is what separates this from an ordinary price rise.
Under per-call billing, the billable quantity was a number you chose. You decided how many searches to run; the meter counted your decisions. Under per-result billing, the billable quantity is how many results come back — and the published tool surface gives you no way to set it.
The documented X Search parameters are allowed_x_handles and excluded_x_handles (twenty maximum each), from_date and to_date, and enable_image_understanding / enable_video_understanding. Filters on what gets searched. Nothing on how much comes back.
So the denominator is set by the model’s search behavior and by the structure of the threads it lands in. And the parent-and-quoted clause compounds it: a reply three levels deep bills for the chain above it; a post quoting another bills for both. The multiplier tracks how conversational the retrieved material is — which varies by topic, by news cycle, by how argumentative a given week happens to be, and not at all by anything in your request.
The practical consequence is that nobody can give you a confident per-call cost estimate, including the vendor. You can measure your historical average and assume it holds, which is the best available method and still an assumption about discourse shape.
This is the same pattern we keep finding at the metering layer rather than the model layer: Sakana’s orchestration tokens, where the effective price diverged from the advertised one because the harness generated tokens the buyer did not write; Salesforce’s per-action meter, where a long-horizon runtime bills on units the agent decides to consume; and Anthropic’s on-demand compaction, where the model rewriting its own context meant usage.input_tokens stopped describing the invoice. Four vendors, one direction: the meter is migrating from things the buyer counts to things the model does.
Who this actually hits
Teams that chose Grok for X access. This is the group that matters, and it is defined precisely by having made the decision this change devalues. Real-time X data is the capability rivals cannot replicate — it is the reason Grok appears on shortlists where its benchmark position alone would not carry it, and a recurring theme in Grok versus ChatGPT comparisons. That differentiator is intact as a capability and more expensive as a line item. Somewhere in the middle of those two facts is a build-versus-buy conversation that was settled and now is not.
Social listening and brand monitoring. The worst-hit shape, because the workload is high-volume, broad-query, and lands squarely in the conversational threads where the parent-and-quoted multiplier bites hardest. A dashboard refreshing hundreds of queries hourly was cheap under per-call pricing almost by accident. It is not cheap now, and the discussion-heavy topics these tools exist to watch are exactly the ones carrying the most billable context per match.
Agents that search opportunistically. If you run agents that decide for themselves when to reach for X — the agent platforms pattern — you have a compounding exposure: the model chooses when to search and the results determine the charge, with no cap on either. Per-run cost variance is about to widen in a way that budget alerts set on call volume will not catch.
Everyone else on Grok. Largely unaffected. Token prices held, Grok 4.6’s launch economics are unchanged, and the Bedrock endpoint split remains the more consequential decision for enterprises weighing data residency.
What to do before Monday
Measure the ratio you never had to know. Your new bill is posts-and-profiles returned, not calls made. Pull thirty days of X Search volume and, if you logged responses, count actual results per call. That single number converts your current invoice into your future one. If responses were not retained — common, since there was no reason to care — instrument today and sample through the weekend. Two days of real data beats an estimate, and the deadline is Monday.
Take the two levers that exist. Tighten from_date and to_date so searches stop reaching further back than the task requires, and use allowed_x_handles wherever you genuinely only care about a known set of accounts. Both trade recall for cost, which is an unattractive trade and the only one on offer.
Split profile lookups out. They bill at double. Isolate them in your code so the expensive line is visible on its own rather than buried in a general search path.
Ask the question the docs do not answer. If X Search volume is material, contact SpaceXAI before Monday and ask directly whether a result-limit parameter ships with the change. The answer determines whether this is a manageable repricing or an uncapped one, and it is not currently documented.
Re-run the comparison if X was the reason. For research and citation workloads that are not specifically about X, Perplexity and general web search cover much of the ground at different economics. For developers building on top of this, the honest framing is that Grok’s integrated-X advantage just became a priced feature rather than an included one, and priced features belong back in the evaluation.
The smaller point
Three days’ notice on a documentation page, for a change that multiplies one line of the bill by the size of your result sets. The token row — the number everyone watches, benchmarks and blogs about — did not move at all.
That is the durable lesson, and it is not specific to SpaceXAI. Model pricing is the competitive surface, so it is advertised, compared and held stable. The meters around the model are where the economics quietly get rewritten, and they move on doc-page notices with no launch post attached. If your cost monitoring watches tokens, it is watching the part of the bill vendors have the least incentive to change.
Read the tooling rows. That is where the repricing lives.
Frequently asked questions
What exactly is changing, and when?
On 21 September 2026 at 12:00 PM PT, X Search stops being billed at $5 per 1,000 calls and starts being billed at $5 per 1,000 posts fetched plus $10 per 1,000 user profiles fetched. The unit of account moves from the request you issue to the results that come back. SpaceXAI's documentation states the counting rule plainly: every post returned by a search or thread fetch counts, including parent and quoted posts, and every profile returned by a user search counts. Grok token pricing is untouched — grok-4.6 remains $2 per million input and $6 per million output below 200k context, doubling to $4 and $12 above it, with the other models in the family unchanged as well. This is a change to one line of the bill, but it is the line that used to be predictable.
Is this a price increase or just a different way of counting?
It is a price increase for every workload except a degenerate one. Break-even sits at exactly one post per call: if your average search returned precisely one post, your cost would be identical before and after. Every additional result is new money. A search returning ten posts goes from half a cent to five cents; one returning thirty goes from half a cent to fifteen cents, a thirtyfold increase on the same request. Profile lookups are worse at twice the per-result rate. Real search calls do not return one result — they return a page of them, which is the entire reason to call a search API rather than fetch a known URL. The framing of granularity is accurate as a description of the mechanism and misleading as a description of the effect.
Can I cap how many posts come back to control the bill?
Not through any documented parameter, and this is the sharpest edge in the change. The published X Search parameters cover which accounts to include or exclude (allowed_x_handles and excluded_x_handles, maximum twenty each), the date window (from_date and to_date), and whether images and video are interpreted (enable_image_understanding and enable_video_understanding). None of them limits result count. So the quantity you are now billed on is chosen by the model's search behavior and by the shape of the threads it lands in, not by a value you set. Handle allowlists and tight date bounds are the only levers that exist, and both narrow relevance to buy cost control. If a limit parameter ships alongside the pricing change, it is not in the docs as of publication, and that is worth confirming with SpaceXAI before 21 September if search volume is material to you.
What is the parent-and-quoted-post rule, and how much does it actually cost?
It is the clause that makes the new meter hard to forecast. A thread fetch does not return only the posts matching your query — it returns the conversational context around them, and the documentation confirms parent and quoted posts count toward billing. That means a reply three levels deep bills for the chain above it, and a post quoting another bills for both. The multiplier is set by how conversational the retrieved content happens to be, which varies by topic in ways you cannot predict from your query. Discussion-heavy subjects — breaking news, product complaints, anything argumentative — carry more context per match than announcement-style posts do. You are paying for structural context your query did not request, at a rate that fluctuates with the discourse. Nobody can hand you a reliable per-call estimate, including SpaceXAI.
What should I do before 21 September?
Measure first, then decide. Pull your X Search call volume for the last thirty days and, if your logs retain responses, count the posts and profiles actually returned — that ratio, not your call count, is your new bill, and most teams have never had reason to look at it. If responses were not logged, instrument now and sample for a couple of days; three days of real data beats a guess. Then take the obvious mitigations: tighten date windows so searches stop reaching back further than the task needs, use allowed_x_handles where you genuinely only care about a known set of accounts, and separate profile lookups from post searches in your code so the double-rate line is visible on its own. Finally, check whether X data is load-bearing for your product at all. Several of these workloads are sentiment-flavoured nice-to-haves that were affordable at $5 per 1k calls and are not obviously affordable at per-result rates.
Does this make Grok a worse buy overall?
Only for the narrow set of buyers who chose it specifically for X data, which is admittedly the set most likely to have chosen it. Grok's token economics are unchanged and remain competitive — the model family's value proposition against the frontier alternatives does not move on this announcement. What moves is the differentiator. Real-time access to X is the one capability Grok has that rivals structurally cannot match, and repricing that access from a flat call fee to a per-result meter narrows the gap between 'the model with X built in' and 'a model plus a separate data subscription.' If you picked Grok for its reasoning or its price-per-token, carry on. If you picked it because X Search was cheap and integrated, you should re-run the comparison, because half of that sentence just changed and the other half was always available elsewhere.
Sources
Related tool reviews
Questions or corrections? Email Pick Right. Want the full list? See all news.