TL;DR: Grok touches X data through three separate products with three separate rules: the consumer assistant inside the X app or grok.com (one conversational query at a time, no export), xAI's priced X Search API tool ($5 per 1,000 calls, handle and date filters), and X's own developer platform (pay-per-resource, capped at 3 million post reads a month). None of them hand you bulk scraping. All of them are legitimate for analysing public conversation in aggregate (sentiment, themes, how a discussion moved), and none of them should be pointed at a named private person.
What can Grok actually see on X, and through which door?
"Analyse X conversations with Grok" collapses three genuinely different things into one phrase, and the differences are exactly where a workflow goes wrong.
| Feature | Consumer Grok (X app / grok.com) | xAI X Search tool (API) | X's own Developer Platform |
|---|---|---|---|
| Who it's for | Anyone with an X account | Developers with an xAI API key | Developers with an X developer account |
| How you pay | Included with X / Grok access | $5 per 1,000 successful calls | Pay-per-resource credits |
| Query shape | One conversational question | Parameterised: handles, dates, semantic search | Direct endpoint calls (search, timelines, users) |
| Bulk export | Capped at 3M post reads/month, then Enterprise |
The rest of this post walks through each door in order, then the prompt patterns that stay on the right side of "aggregate analysis" versus "profiling a person."
What does the consumer Grok assistant do when you ask it about a topic on X?
Inside the X app, tapping the Grok icon puts you in front of the same assistant available at grok.com, and X's own help documentation is specific about how it decides what to search: Grok "has a unique feature that allows it to decide whether or not to search X public posts and conduct a real-time web search on the Internet." Its "access to real-time public X posts" is what lets it "respond to user queries with up-to-date information and insights on a wide range of topics." You don't configure this: you ask a question, and Grok chooses whether searching X, searching the web, both, or neither would help.
That's genuinely useful for a one-off question ("what's the general reaction to [product launch] been on X this week?") and genuinely limited for anything systematic: there's no way to export the underlying posts, no scheduled or recurring query, and no handle-list or date-range control; those live one door over, in the API. X's own documentation is candid about the assistant's reliability, too: "This is an early version of Grok. It may confidently provide factually incorrect information, missummarize, or miss some context." Treat a conversational summary as a starting point, not a citation-grade result, unless you've asked it to show its sources (more on that below).
For a question that genuinely needs more digging than a quick check, it's worth reaching for grok.com directly rather than the in-app icon, and picking a deeper mode. Grok's mode picker covers Auto, Fast, Expert and Heavy, with Fast as the default; a request to summarise a week of scattered conversation benefits from Expert or Heavy in the same way a quick factual lookup doesn't, because the deeper modes spend more effort reasoning over what the search actually turned up rather than answering off the first few results.
X also documents, in the same article, that your interactions with Grok on X (including voice inputs and their transcriptions) can be used to train and personalise Grok's models. These are two separate settings, not one: a "Data Sharing" toggle covers whether your data trains and fine-tunes the underlying models, and a separate "Grok Personalization" toggle covers whether your own history shapes the answers Grok gives you specifically. Both live under Privacy & Safety, and making your account private prevents your own posts from being used either way. You can delete your entire conversation history from the same settings menu, and X's help documentation states plainly, in answer to whether it sells your data: "No. We do not sell your data." The same page notes Grok on X is available in every country where X itself operates, so the consumer door is the one with the widest reach even though it's the narrowest in what it lets you configure.
Tool use is the general concept here: the model itself decides when to reach for a search tool instead of answering from what it already knows. The API surfaces that same decision as something you can configure directly.
What does xAI's X Search tool add for developers?
At the API level, documented at docs.x.ai, X Search is a distinct, named tool: "The X Search tool enables Grok to perform keyword search, semantic search, user search, and thread fetch on X (formerly Twitter)." It's available through the xAI SDK, the OpenAI-compatible Responses API, and the Vercel AI SDK, and it takes real parameters instead of leaving everything to the model's judgment:
| Parameter | What it does |
|---|---|
allowed_x_handles / excluded_x_handles | Scope to (or exclude) up to 20 X handles (mutually exclusive with each other) |
from_date / to_date | ISO8601 date range, both dates inclusive |
enable_image_understanding | Analyse images found in matching posts |
enable_video_understanding | Analyse videos found in matching posts (X Search only, not Web Search) |
X Search parameters, per docs.x.ai, checked September 3, 2026.
xAI's documentation is explicit that allowed_x_handles and excluded_x_handles "cannot be set together with" each other "in the same request." You're narrowing the search one way or the other, not both. Pricing sits in the same documentation set: X Search is billed at $5 per 1,000 successful calls, the same rate as Web Search and Code Execution, on top of standard token costs for the model's reasoning and output. That last part matters more than it looks: xAI's own pricing documentation notes that "the agent autonomously decides how many tools to call, costs scale with query complexity." A broad topic over a long date range can invoke the search tool more than once behind a single question, and the bill follows accordingly.
A minimal call, scoped to a date range, looks like this in the xAI Python SDK:
from xai_sdk import Client
from xai_sdk.chat import user
from xai_sdk.tools import x_search
from datetime import datetime
client = Client(api_key="YOUR_XAI_API_KEY")
chat = client.chat.create(
model="grok-4.6",
tools=[
x_search(
from_date=datetime(2026, 8, 1),
to_date=datetime(2026, 8, 31),
),
],
)
chat.append(user("What's the general sentiment on X about [topic] this month?"))
response = chat.sample()
print(response.content)
print(response.citations)
A separate but related Web Search tool exists for the open web rather than X specifically, and it's worth not confusing the two: Web Search scopes to domains via allowed_domains, capped at 5, while X Search scopes to handles via allowed_x_handles, capped at 20. Both can run in the same request if a question needs both public web coverage and X-specific coverage, and both return the same kind of citation list.
This is the layer that makes a repeatable workflow possible: a scheduled job that pulls sentiment on a topic every week, scoped to a date range, is realistic here in a way it isn't through the consumer assistant. It requires an xAI API key and billing set up; it is not something you get by asking Grok nicely inside the X app.
Why can't I just scrape or bulk-export X data through Grok?
Because X Search queries X on xAI's own terms with X, for that one request; it isn't a door into X's underlying data at scale, and X's own developer platform, a completely separate product documented at docs.x.com, makes the scale question explicit. As of a September 3, 2026 check, X's API moved to pay-per-usage pricing: "The X API uses pay-per-usage pricing. No subscriptions—pay only for what you use." Reads are billed per resource, posts at $0.005 each and users at $0.010 each, and the documentation states plainly that "pay-per-usage plans are capped at 3 million Post reads per monthly billing cycle. If you need higher volume, upgrade to an Enterprise plan." Worth noting the asymmetry: X prices Owned Reads, requests for your own posts, bookmarks, followers and the like, at $0.001 per resource, a fifth of the standard rate. That discount applies to your own account's data specifically; it doesn't extend to reading someone else's timeline at scale, which is exactly the gap a bulk-analysis workflow would need filled and exactly the gap none of these three products fills.
What's a legitimate prompt for analysing X conversations in aggregate?
Aggregate analysis: sentiment across a topic, how a public discussion changed over a week, what themes recur in replies to a launch, is exactly what these tools are built for. A few starting shapes, written for the API's X Search tool but adaptable to a conversational ask inside the app:
Search X posts about [topic or product] from [start date] to [end date].
Summarise the main themes, note where sentiment is mixed or negative, and
cite the specific posts that best represent each theme.
Compare how the conversation about [event] on X looked in the first 48 hours
versus a week later. What claims appeared early that later got corrected or
dropped?
Using only posts from [list of official/brand handles], summarise what each
has said about [topic] this month, and flag any posts where their public
statements disagree with each other.
Search X posts about [topic] from [start date] to [end date], including
images and videos in the results. Note any recurring visual themes alongside
the text-based sentiment, and cite each post you draw a conclusion from.
That last shape leans on enable_image_understanding and enable_video_understanding from the parameter table above, which is worth calling out because it's easy to assume X Search only reads text. It doesn't; a topic that's mostly discussed through screenshots, memes, or clips still analyses cleanly as long as the scope stays the topic, not a person.
Notice the shape: a topic or a set of known, typically public/official handles, a bounded date range, and a request for citations. That's the pattern Grok's real-time-data prompt templates already cover in general; X Search is the same discipline applied specifically to X as the source.
Where's the line between aggregate analysis and profiling a person?
The allowed_x_handles parameter exists to scope a search to accounts you already know: a brand's own handle, a competitor set, a list of reporters covering a beat. That's the same mechanism whether you're using it to track how three airlines talk about a delay policy or to build a running file on one named private individual's posting history. The parameter doesn't distinguish; you have to.
A useful test before running a search-backed query is to ask what the output would look like if it worked perfectly. A report titled "sentiment on the new pricing plan" that names no individual by default is aggregate analysis; a report titled with someone's name, structured around what they said and when, is a dossier regardless of how it was assembled. Public figures acting in a public capacity, an executive's own statements about their company, a journalist's own reporting on a beat, sit closer to the aggregate end, because the analysis is still about the public role and its record rather than the private person behind it. The moment a request would be uncomfortable to say out loud to the person it's about, that discomfort is the signal, not the tool.
How do you keep citations honest when Grok summarises a conversation?
xAI's documentation describes the full citations list as "a comprehensive list of URLs for all sources the agent encountered during its search process." It's returned by default with every search-backed response, with no extra configuration required. That list is not the same thing as the posts the summary actually relies on, though: xAI's own documentation notes that the agent can examine a source, decide it isn't relevant enough to use, and still leave its URL in the list for transparency. A long citations list is evidence the tool searched broadly, not evidence every one of those posts shaped the answer you got.
Inline citations, the [[N]](url) links embedded directly in the response text, are on by default for the Responses API and opt-in for the raw SDK. Ask for them explicitly if your client doesn't surface them automatically, and actually open a sample of the cited posts rather than trusting the summary at face value: the same hallucination risk that applies to any model-generated summary applies here, and a citation list you never check is not a safeguard.
This is also where the date range matters more than it looks like it should: a summary of "the conversation about X" that doesn't state which window it searched can quietly generalise from a few loud hours to a whole topic. State the range in the prompt, and expect the same discipline back in the answer. For the equivalent problem in a general search-shaped assistant rather than X specifically, search-shaped prompting for Perplexity covers the same citation-checking habit from a different vendor's angle, and Grok's modes covers how Fast versus Expert changes how much searching happens before you get an answer at all.
The short version
Three products, one underlying platform: the consumer Grok assistant decides on its own whether to search X, answers one question at a time, and exports nothing. xAI's X Search API tool turns that same capability into a parameterised, priced, repeatable request: handles, dates, image and video understanding, $5 per 1,000 calls. X's own developer platform is the only place bulk access lives, and it's metered, capped, and governed by X's own terms, not something a Grok prompt reaches around. Stay on the aggregate side of the line: topics, brands, public discourse, and all three are legitimate tools for understanding a conversation instead of a person.
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 4.8★ on the Chrome Web Store.
Create An Account