xAI is changing the economics of X Search. RuntimeWire was built for a narrower retrieval model

Starting September 21st, xAI will stop charging a flat fee for Grok’s X Search calls and begin billing for every post and user profile returned. For products that depend on large-scale X ingestion, the difference could be significant. RuntimeWire was architected around a different assumption: use human editorial judgment to narrow the field first, then let machines investigate deeply.

By · Published · Updated

Primary source: xAI Docs

Why it matters

Agent costs will rise with the amount of X data Grok retrieves, making open-ended social research less predictable and potentially far more expensive.

A human hand uses a focused lens to select specific data from a vast, flowing stream, while a digital counter in the background indicates rising costs.

xAI just sent an email to developers announcing new search pricing for the API.

Screenshot from a RuntimeWire inbox email announcing SpaceXAI's X Search pricing change, which takes effect September 21st, 2026. Pricing shifts from $5 per 1,000 tool calls to $5 per 1,000 posts fetched and $10 per 1,000 user profiles fetched.

When xAI announced its new X Search pricing, my first thought was that this could become expensive very quickly for AI products that treat X as a primary data source.

Beginning September 21st at 12:00 PM PT, xAI will change X Search from a per-call model to a per-item model.

Current pricing

  • $5 per 1,000 X Search tool calls

New pricing

  • $5 per 1,000 posts fetched
  • $10 per 1,000 user profiles fetched

xAI says every post returned by a search or thread fetch counts, including parent and quoted posts. User profiles are billed separately. Its documentation also makes clear that X Search can involve keyword search, semantic search, user search and thread retrieval, with agents deciding how to use those tools during a request. (xAI X Search documentation) (xAI pricing)

That changes the unit developers need to think about.

Under the current model, the cost is tied mainly to the number of tool invocations. Under the new one, it is tied to how much X data the agent actually retrieves.

A simple example

The difference becomes obvious when a single search returns a lot of material.

Posts returned Current X Search cost New post-fetch cost
1 $0.005 $0.005
10 $0.005 $0.05
50 $0.005 $0.25
100 $0.005 $0.50
1,000 Depends on call count $5.00

Those figures exclude model inference.

The shift matters most for AI systems that intentionally cast a wide net: social intelligence products, monitoring systems, research agents and news products that ingest thousands of posts so they can identify a much smaller number of relevant signals.

The new model puts a direct price on breadth. The more material an agent retrieves in order to discover what matters, the more the retrieval layer costs.

Aligned News is a useful example

Robert Scoble's Aligned News is interesting here because its methodology is unusually public.

Aligned News says it monitors 63 curated X lists covering more than 100,000 accounts and retrieves more than 5,000 posts per sweep. Its system applies more than 100 signal keywords, compares activity across lists and uses semantic search over a large indexed corpus. (Aligned News methodology)

Scoble has also repeatedly said publicly that Aligned News is pulling roughly 30,000 X posts per day and spending about $100 to $150 per day on X API calls.

That works out to approximately:

  • $3,000 to $4,500 per month today
  • ~30,000 posts per day
  • ~900,000 posts per month

At xAI's new post-fetch rate, 30,000 posts per day would cost:

30,000 x $0.005 = $150 per day

or about:

$4,500 per month

for post retrieval alone.

That does not include profile fetches, additional thread expansion or Grok inference.

If a system also fetched 3,000 user profiles per day, the profile charge would add another:

$30 per day

or roughly:

$900 per month

That would put the retrieval layer around $5,400 per month before model tokens.

The exact bill for any service depends on architecture, caching, deduplication and how much surrounding context is fetched. The larger point is easier to see: systems built around broad social ingestion now have a very visible marginal cost attached to that breadth.

I checked RuntimeWire's own X usage

After reading the pricing notice, I pulled RuntimeWire's X API usage for the last 30 days.

From August 11th through September 10th, RuntimeWire fetched:

Metric Last 30 days
X posts 37,680
User profiles 1,560
Total billable events 40,160
API requests 52,570
Total cost $206.34

That is roughly:

  • 1,256 posts per day
  • 52 profiles per day
  • $6.88 per day in X API cost

Applying xAI's new pricing to that same usage gives a surprisingly close result.

RuntimeWire under the new xAI pricing

Posts

37,680 x $5 / 1,000 = $188.40

Profiles

1,560 x $10 / 1,000 = $15.60

Combined

$204.00

Our actual bill for the same period was $206.34.

So for RuntimeWire, the new pricing model is already very close to the economics we are living with today.

The difference is architectural

The interesting comparison is not really the monthly bill. It is the amount of X data each system needs in order to do its job.

Aligned News says it processes roughly 30,000 posts per day.

RuntimeWire fetched roughly 1,256 posts per day over the same kind of 30-day window.

That is a difference of about 24x.

System Approx. X posts/day Retrieval approach
RuntimeWire ~1,256 Selective, investigation-driven
Aligned News ~30,000 Broad, continuous ingestion

I architected RuntimeWire with this distinction in mind.

I never wanted the newsroom to operate by continuously vacuuming up social content and asking a model to decide what mattered afterward. RuntimeWire was designed to use editorial judgment earlier in the process.

The workflow is closer to:

human or editor spots a signal -> system investigates -> evidence is gathered -> story is evaluated

rather than:

ingest everything -> rank everything -> filter everything -> investigate the survivors

That choice was partly editorial. It was also technical.

A human editor is very good at reducing the search space.

If I see one obscure engineer post something that looks unusual, I do not need to ingest 100,000 unrelated posts before deciding whether it is worth investigating. I can point the newsroom at that signal and let the machines go deep from there.

They can pull the surrounding thread, inspect related accounts, search for corroboration, compare technical artifacts, examine filings and build out the reporting.

The expensive machinery is applied after something has crossed an editorial threshold.

RuntimeWire was built to spend machine effort on investigation rather than indiscriminate collection.

Why that matters under per-item pricing

Under xAI's new pricing, targeted investigations remain relatively cheap.

If one investigation retrieves:

  • 20 posts -> $0.10
  • 50 posts -> $0.25
  • 100 posts -> $0.50
  • 500 posts -> $2.50
  • 1,000 posts -> $5.00

That gives a newsroom a lot of room to investigate deeply without needing a giant X ingestion budget.

The economics become more difficult when the system continuously retrieves large amounts of social data in order to discover the small percentage worth analyzing.

For example:

Posts fetched per day Monthly post cost at new rate
1,000 $150
5,000 $750
10,000 $1,500
30,000 $4,500
100,000 $15,000

Profiles can add materially to that. At $10 per 1,000 profiles, a system resolving tens of thousands of users per day can create a second meaningful cost center.

The agentic part deserves attention

This pricing change also matters because X Search is designed for agentic use.

xAI documents X Search as a tool that can involve:

  • keyword search
  • semantic search
  • user search
  • thread fetching

Its pricing documentation says the agent can decide which tools to call as it works through a request, which means cost can vary with the complexity of the task. (xAI Tool Usage Details)

That creates an interesting operational problem.

A developer may think they are asking one question:

Find what researchers are saying about this model and explain the disagreement.

The agent may interpret that as several searches, multiple thread fetches, quoted-post retrieval and user lookups.

Under a per-call model, developers can reason mostly about how often the tool is invoked.

Under a per-item model, the cost depends on how much material the agent gathers along the way.

That makes retrieval behavior part of the product's unit economics.

Broad ingestion still has real advantages

There is a reason systems like Aligned News ingest so much material.

A broad monitoring system can find weak signals that no human editor has consciously noticed yet. It can detect patterns across many unrelated accounts and identify unusual activity before anyone thinks to search for it.

That is valuable.

Aligned News explicitly describes this kind of process: large list coverage, thousands of posts per sweep, cross-list comparisons and semantic search over a growing index. (Aligned News methodology)

RuntimeWire is making a different tradeoff.

I want machines to go very deep once we have reason to believe something is interesting.

That is the architecture that leads us into binaries, unreleased software, court filings, hidden product surfaces, technical documentation and source material that may have little to do with X after the initial signal.

X often tells us where to look.

It usually does not need to be the entire thing we are looking at.

RuntimeWire has substantial headroom

At current usage, our X-data bill is around $200 per month.

Even with substantial growth, the numbers remain manageable.

RuntimeWire usage multiplier Approx. monthly X cost
1x ~$206
2x ~$413
5x ~$1,032
10x ~$2,063

At 10 times our current X usage, RuntimeWire would still be spending less per month than Scoble says Aligned News already spends today.

And at that level, RuntimeWire would be fetching roughly 12,500 posts per day, still well below Aligned News' reported 30,000.

That gives us a lot of room to scale without changing the basic architecture.

Why I built it this way

I designed RuntimeWire around a simple assumption: AI would make research and investigation much cheaper, while editorial judgment would remain scarce and valuable.

That led me toward a newsroom where humans and editors narrow the field before expensive automated work begins.

The result is visible in our X usage.

In the last 30 days, RuntimeWire fetched fewer than 38,000 posts and spent about $200 on X API access.

For an AI-native newsroom producing work at our volume, that is a surprisingly small retrieval footprint.

xAI's pricing change makes the architectural tradeoff easier to quantify.

If your product needs to read millions of posts in order to discover a few important ones, per-item billing can become a major operating expense.

If your system uses editorial judgment to decide where the machine should spend its attention, the economics look very different.

I built RuntimeWire around the idea that machines should investigate broadly once humans have decided where to look. xAI is now putting a very explicit price on the alternative.

Reader comments

Conversation for this story loads after sign-in.