X killed its free tier in February 2026 — the real cost of the alternatives

If your X integration stopped working this year and you went looking for the free tier, it is gone. Not reduced — gone.

This is what replaced it, priced out at volumes you might actually run. Every X figure below comes from X's own pricing documentation, read on 7 September 2026. Where I could not confirm something at the source, I say so rather than estimating.

Updated 28 September 2026. Expanded with the per-resource arithmetic worked out, a comparison of the open alternatives with measured payload sizes, and a FAQ. One correction: when this went up, none of our own social routes were live. As of that date, fourteen are live across ten networks, each with its own page — so the section on alternatives now links to real routes instead of a promise.

Did X really remove the free tier, or just shrink it?

Removed. There is no free option in the documentation — not a smaller one, not a rate-limited one, not a trial.

There are also no named subscription tiers left to compare. X moved to pay-per-use: you buy credits up front in the Developer Console, and each request deducts from them.

The detail that matters more than the prices: reads are charged per resource returned, not per request. One search that comes back with 100 posts is 100 charges, not one. That single design choice is what makes the new pricing behave differently from every tier system developers learned on, and it is where most cost surprises come from.

What does the X API cost in 2026?

Writes are charged per request instead, from $0.005 to $0.200 depending on the action. Creating a post costs $0.015. Creating a post with a URL in it costs $0.200 — thirteen times more, which is a pricing decision with an opinion inside it.

What does that cost at volumes you would actually run?

Per-resource pricing is easy to underestimate, because the unit is small and the multiplier is not. The arithmetic, using X's own numbers:

A single search returning 100 posts costs 50 cents. Run that hourly for a month and you are at $360 — for one query, refreshed hourly, on one keyword.

Put a few keywords behind it and the shape becomes clear:

That is the number worth sitting with before you architect anything. The old free tier taught a generation of developers to poll cheerfully. Polling is now a line item.

Why does "per resource" change how you should build?

Because the two things you can do with an API now have very different prices, and they used to have the same one.

Under a request-based tier, re-reading a list you already have and discovering a list you do not have cost the same: one request each. Under per-resource pricing, discovery is the expensive operation and re-reading is the cheap one — for a reason that is easy to miss.

What is the 24-hour rule, and how much does it actually save?

X's documentation states that the same resource requested twice within 24 hours is only charged once.

This is genuinely useful and almost nobody factors it in. Worked out:

# A job watching 500 known posts, hourly, for a month.

# Naive reading of the price sheet:
500 posts × 24 hours × 30 days × $0.005  = $1,800

# With the 24-hour deduplication rule:
500 posts × 1 charge/day × 30 days × $0.005 = $75

# Same job. Same data. 24× difference.

The saving is not a discount you apply for — it is automatic, and it is the difference between a job that is unaffordable and one that costs less than lunch.

It also quietly changes what architecture is sensible:

• Re-reading a known set is nearly free. Tracking the engagement curve of posts you already found costs one charge per post per day, however often you look.
• Discovering new sets is what costs. Every new post a search surfaces is a new charge.
• So cache your identifiers, not your payloads. Keeping a list of post IDs you are watching is what unlocks the rule. Throwing the list away and re-searching to rebuild it pays full price every time.

Design around that and the same budget goes several times further. Ignore it and you will conclude the API is more expensive than it is.

Is there a ceiling on pay-per-use?

Yes, and it is not negotiable at your tier: pay-per-use is capped at 3 million post reads per monthly billing cycle. Above that you are into Enterprise, which means a sales conversation rather than a credit card.

Three million sounds enormous until you divide it:

A moderately busy monitoring product touches that ceiling. And the failure mode is not the price — it is discovering the cap after you have built for growth, which is a rebuild rather than an invoice.

Is the xAI credit real money?

Spending on X API credits earns back xAI API credits — 10–15% at $200–$999 of cumulative spend, up to 20% above $1,000.

Read it plainly: it is a discount denominated in someone else's product. If you were going to buy xAI inference anyway, it is worth real money. If you were not, it is worth nothing, and it should not appear in your cost model as though it were cash back.

Which February was it — 2026 or 2023?

Both, and this is the trap for anyone researching it.

X killed free API access in February 2023 as well, and that announcement is still widely linked. Two February cut-offs, three years apart, and search results mix them freely. If a source about "the February change" does not say which year, it is not usable.

On the 2026 date specifically, here is what I can and cannot stand behind:

X's own announcement forum returns 403 to automated requests, so I could not read the announcement body at the source. I am not going to state the date as though I had.

What are the alternatives, and what do they actually cost?

Five options. The last two are the ones that get skipped.

How does Bluesky's free API actually compare?

Bluesky's API is open, free, and needs neither a key nor an account — it is the AT Protocol's own public surface. Measured on our side, a profile read is 634 bytes on the wire (sampled 2026-09-10), and a feed read with limit=25 is about 93 KB.

Two things worth knowing before you build on it:

• The DID is the identity, not the handle. A Bluesky handle can change; the did:plc or did:web cannot. Anchor on the DID or a renamed account reads as a different one. Our Bluesky profile route does this; if you are calling the protocol yourself, do it too.
• A repost is not a post. In the raw author feed, roughly 1 in 20 items is someone else's post, boosted. Counting them credits the account with writing it. Our Bluesky posts route excludes them by authorship.

And Mastodon?

Also open, also no key, also no account — via each instance's official API. A profile read is 932 bytes on the wire.

Mastodon is federated, and that is not a detail:

• The handle is always user@instance. @gargron alone identifies nobody. Our Mastodon profile route refuses a bare name with a 400 instead of guessing an instance.
• The boost ratio is much higher than Bluesky's — 15 in every 20 items in the raw feed. Worse, the outer object of a boost arrives with empty text and zeroed metrics, so counting them reports an account posting empty statuses. Our Mastodon posts route excludes them.
• There is no identity verification to read. Mastodon verifies that you control a link, not who you are. Any field claiming a verified badge for a Mastodon account is claiming something the platform never granted.

What about buying from a reseller?

Several vendors sell X data collected from public pages. They are compared here with real pricing. The trade-offs are the usual ones: you are exposed to a middleman who can change what comes back, and who may compete with you.

Worth reading alongside that: the cost of one of the larger resellers, worked out per run, and what bandwidth actually costs when you collect from public pages yourself.

Do you need per-post data at all?

The question behind most X integrations is "is this topic growing?" — which is a question about change over time, not about individual posts. It is answered by an archive rather than a firehose, and at a fraction of the reads.

That is the other product here, and it is live. Concretely, as of 27 September 2026 it holds 474 hourly windows since 7 September across eleven sources — 42,660 records from the VS Code Marketplace, 25,460 from Hacker News, and so on, with 13 error rows in twenty-one days across the whole table. Which sources are collected, which are not, and why, is listed one page per source under sources — including the page for X, which says plainly that we do not collect it.

Why doesn't HonestHook collect from X?

Because collecting X for the archive would need a third-party provider we have not turned on, and we would rather say that than imply coverage we do not have. The same is true of Reddit — switched off over licence terms, not over anything breaking — and of Bluesky search, where the search API returns 403 to our datacenter IP while the profile routes work fine.

That distinction matters and it is the one most providers blur: a network can be closed to bulk collection and open to a single public profile read at the same time. Bluesky is exactly that. Treating "we have Bluesky" as one claim, rather than two, is how coverage tables end up lying.

What breaks when you build on a metered API?

Three things, in the order they bite:

1. A budget that runs out mid-month. Credits are prepaid. When they are gone, calls fail — and how your code handles that failure is usually untested.
2. A silent wrong number. This is the expensive one. A scraper or client that returns a plausible value from the wrong field does not error, so nothing alerts. We wrote about how that failure actually looks and about the specific case of the wrong follower field.
3. The ceiling, discovered late. See above. 3M reads per cycle is a wall, not a slope.

If you are building on any of this, the two pages worth having open are the status page, which is never cached, and the pricing page — ours is one credit per call, and a call that finds nothing costs nothing.

FAQ

Is there any free way to read X data in 2026?

Not through X's API. The documentation offers no free option. Reading public pages yourself is a different question with a different answer, and it depends on volume and on terms you should read before you rely on them.

How much does 1,000 X posts cost?

$5, at $0.005 per post resource. A thousand user profiles is $10, at $0.010 each.

Does the 24-hour rule apply across different endpoints?

X's documentation frames it per resource, not per endpoint — the same post requested twice inside 24 hours is charged once. We have not tested it across endpoints, so we are not going to claim it works that way.

What happens if I go over 3 million post reads?

You are into Enterprise, which is a sales conversation rather than a higher credit-card tier. Plan for the cap before you need it.

Is Bluesky a realistic replacement for X?

For volume, no. For the question most X integrations are actually asking, often yes. The API is free, needs no account, and the profile and posts surfaces are stable. Whether that is enough depends on whether you needed X specifically or needed public conversation — and those two get conflated constantly.

Do I need an account or a key for Mastodon?

Not for public profiles and public posts. You do for post search across the network, which is why we do not collect Mastodon for the archive while the profile route is live.

Which fields can a public profile read actually give me?

Fewer than most vendors imply, and the honest answer varies by network. Followers and following are widely available; post counts and verification badges frequently are not. Each of our routes lists what it does not return and why — Threads, for instance, exposes neither following nor post count, so both come back null rather than zero.

Where do I start without paying anything?

A free key is 1,000 credits a month with no card. The quickstart is one call.

The part worth remembering

The specific prices will drift. What will not is the shift underneath them, and it is the same shift Reddit made three months later: public conversation data stopped being infrastructure and became inventory.

Every platform that can meter it is metering it. Build as though the free surface you are using today has a price attached tomorrow, because on current evidence it does.

Our own position, including the uncomfortable parts, is on the social data page.

What we actually serve

We don't serve X. If you're here because X's API priced you out, these are the platforms we do serve with one key:

• Bluesky — free upstream, no account needed. Profile and posts.
• Threads — public profiles. It returns neither following count nor post count, and both come back null rather than 0.
• Mastodon — public profiles and public posts. Search across the network needs an account, so we don't offer it.
• Every alternative we measured, including the ones we lose to.

None of those is X, and none of them is a drop-in replacement for it. If you needed X specifically — its users, its reach, its conversations — no key here fixes that, and the honest answer is that you pay X or you change the requirement.

Get a free key — 1,000 credits a month, no card

Prices, the 24-hour deduplication rule, the 3M cap and the xAI credit tiers were read from X's own API pricing documentation on 7 September 2026 — primary source. The February 2026 announcement date is from secondary reporting and is flagged as unverified above. Payload sizes for Bluesky and Mastodon, and the archive figures, are our own measurements, dated in the text. This pricing has changed twice in three years; verify before you commit engineering time.