Twitter Free API Options in 2026

What changed in 2026 (updated August 2026)

If you last priced the X API before this year, almost everything you remember has moved. Three changes landed inside seven months and each one invalidates a different piece of the advice still circulating in older blog posts.

• February 2026: fixed plans gave way to consumption billing. The $200 Basic and $5,000 Pro subscriptions stopped taking new signups, and the default way to buy X API access became per-resource rates rather than a monthly tier.
• June 2026: Basic was deprecated outright. Monthly and annual alike. Remaining subscribers were moved onto pay-per-use at the end of their billing cycle, so being grandfathered in stopped being a position anyone holds. A bill that used to be a predictable $200 is now whatever the call volume prices out at.
• Throughout: the free tier stayed nominal. It still exists and it is still write-centric, with roughly 100 post reads a month. That is enough to confirm a token works and nothing else. Any guide describing a free tier you can collect data on is describing 2022.

The practical consequence for anyone searching for a free Twitter API is that the question has changed shape. There is no longer a free readable tier to qualify for, so the real question is which paid route has the lowest floor, and the answer is whichever one does not make you commit to a monthly plan before you know your volume.

Pay-per-use, in plain English

Consumption billing sounds like a simplification and it is not, quite. Under a plan you knew your bill and had to discover your limits. Under pay-per-use you know your limits and have to discover your bill, which is a different kind of uncomfortable and the reason people find the new model harder to reason about.

The mechanics are straightforward. You buy credit up front and each API call debits it at a published rate for that resource type. On the official X API a post read is $0.005 and a user read is $0.010, so the unit is one object, and a request returning a hundred posts debits a hundred times. Creating a post is $0.015, rising to $0.200 when the post contains a URL. Here the unit is one call at $0.0008 regardless of how many objects come back, which is why a search returning twenty tweets works out near $0.04 per thousand rather than $5.

Three questions decide whether a consumption model treats you well, and they are worth asking of any vendor rather than only this comparison. What is the unit, an object or a request? What happens to a failed call, is it billed? And does unused credit expire? Ours are: a request, no, and never. Get those three answers and you can compare any two rate cards honestly.

The one thing consumption billing genuinely fixes is the floor. There is no minimum, so a month where you make forty calls costs about three cents rather than a subscription. For anyone testing an idea, that is the whole difference.

The 3 million post reads cap

The detail most people miss when they price the official pay-per-use tier is that it is not open-ended. It carries a hard ceiling of 3 million post reads per monthly billing cycle, and there is no way to pay your way past it on the same plan.

Read what the cap counts before you plan around it, because it is easy to get backwards. It counts DISTINCT post reads, and X deduplicates repeat sightings of the same post inside a 24 hour UTC window, so polling faster does not move the meter at all. Watching 50 accounts that post five times a day costs the same 7,500 post reads whether you check every 15 minutes or once an hour. What fills 3 million is BREADTH, not cadence: a wide keyword search, a historical backfill, or a corpus that touches millions of different posts. Those jobs hit the ceiling, and the only route past it is an Enterprise contract with no published price, which means a sales conversation and a procurement cycle rather than a billing change you make on a Tuesday afternoon.

The consequence for anyone planning a build is that the cap should sit in your capacity model from the start, not be discovered later. If your projected volume gets anywhere near 3 million reads a month, the official route has a cliff in it and you should know where. There is no equivalent ceiling here: the same $0.0008 per call applies at any volume, and there is no tier above which the arrangement changes.

The xAI credit kickback, read this before you spend

X credits a percentage of X API credit purchases back as xAI API credits, on a ladder tied to cumulative spend inside the current billing cycle: nothing below $200, 10 percent from $200 to $499, 15 percent from $500 to $999, and 20 percent at $1,000 and above. It is a real benefit and it is quoted often enough in comparisons that it is worth being precise about what it does and does not do.

Two conditions decide whether it is worth anything to you. The credits are spendable on the xAI API, not on the X API that earned them, so this is a discount only if you were already going to build on Grok. If you were not, it is a voucher for a product you do not use. And cumulative spend resets each cycle, so a team spending $150 a month never leaves the zero rung, while a team spending $1,000 in a single cycle reaches 20 percent.

What it does not do is change the per-resource rate you pay for data. A post read is still $0.005 whether or not you qualify. So when you model the two options, apply the kickback to your inference budget rather than netting it off the data bill, or the comparison quietly credits you twice.

Real-world cost examples

Rates are abstract until they meet a job. Four workloads people actually run, priced on both routes at published rates, with our own side shown at a full 20-tweet page since that is the assumption behind the $0.04 per 1,000 tweets figure.

One honest caveat on our column, because it is the assumption the whole $0.04 per 1,000 tweets figure rests on. A per-call rate only beats a per-object rate when pages come back full. Across 396,817 of our own read calls, pages averaged about 13 tweets and search pages closer to 8 (per our own billing logs), which puts the real delivered cost nearer $0.06 to $0.11 per 1,000 rather than $0.04. Scale the right-hand column up by between one and a half and three times and the comparison is still not close, but that is the number we would rather you planned with.

Already on legacy Basic or Pro?

These two cases are different and it is worth knowing which one you are in before you plan anything.

If you were on Basic, the decision has already been made for you. X deprecated the plan entirely, monthly and annual, and migrated remaining subscribers to pay-per-use from 1 June 2026 at the end of their billing cycle. The 50,000 posts and 15,000 reads that used to arrive for a flat $200 are now metered, so the first thing worth doing is checking what your actual volume prices out at rather than assuming the bill stayed similar. Teams whose usage sat well under the old allowance often pay less; teams that were using the plan properly usually pay considerably more.

If you were on Pro, you are in a narrower and less settled position. It is closed to new signups, and X has not said publicly whether it faces the same migration Basic did. Treat its future as open rather than decided. If your product depends on something only Pro carried, full archive search or the filtered stream, that dependency is worth naming explicitly in your risk register, because a third-party API serving REST endpoints does not replace a filtered stream.

For either case, the useful exercise is the same: separate the workload that genuinely needs the official API, anything acting on behalf of a signed-in user, anything under a compliance obligation, anything streaming, from the workload that is just reading public data. The second half is usually most of it, and it is the half that moves cheaply.

The honest pitch: skip the X API

We sell an alternative to the official API, so treat this as the interested party speaking. The version of the argument we would make to a friend is narrower than the one a marketing page usually makes.

Skip it if you are reading public data: search, timelines, profiles, follower graphs, lists, communities. That is the large majority of what people want the X API for, and there is no free readable tier to qualify for any more. Be precise about the money, though, because the official per-object rate is not always the loser: a small watch list is genuinely cheap there, since dedup means cadence is free, and our own pricing page shows a 50-account watch job costing $37.50 a month on the official API against $115.20 here. The official rate turns expensive on BREADTH, where a job touching a million distinct posts is about $5,000 against roughly $40. You also skip the developer application and the wait.

Do not skip it if users sign in with their own X accounts and your product acts on their behalf, because that consent-bound OAuth flow is X's and no third party can legally stand in for it. Do not skip it if you have a compliance obligation that data arrive under a signed agreement. And do not skip it if you need filtered-stream style real-time delivery, which resellers serving REST endpoints do not offer.

Most products land in the middle: the official API for the authenticated user flow, a cheaper API for the public reads around it. That is not a compromise, it is what the two things are respectively good at, and it is what we would build ourselves.

What our own billing logs say about page density

Every free-tier comparison on the internet quotes headline rates. Almost none of them quote the number that decides whether a per-call rate is actually cheap, which is how many objects a call returns in practice. We can, because we bill the calls.

Across 396,817 read calls on our own platform, pages averaged about 13 tweets against a maximum of 20, and search pages specifically averaged closer to 8 (per our own billing logs). Search runs thinner than timelines for an obvious reason once you see it: a narrow query has fewer matching results to fill a page with, so the tighter your filter, the emptier your pages. That is the mechanism, not a defect.

What it means for a $0.50 free credit is concrete. At a full page, 625 calls is about 12,500 tweets. At our measured average it is closer to 8,000, and on a narrow search query nearer 5,000. All three numbers are enough to build and test something real, which is the point of the credit, but 12,500 is the ceiling rather than the expectation and we would rather you planned with the middle number.

The useful habit this suggests: measure your own density during the free credit rather than inheriting anyone's average, including ours. Divide tweets landed by calls billed after your first few hundred calls, and you have a multiplier that makes every subsequent estimate yours rather than a vendor's.

Costing an agent workload rather than a pipeline

Most cost guidance in this category assumes a scheduled pipeline: a known query, a known cadence, a predictable call count. A growing share of the traffic we see is not that. It is a language model deciding at runtime what to look up, which behaves differently enough on cost that it is worth its own paragraph.

Two properties change. Volume is bursty rather than flat, because an agent makes no calls for an hour and then twelve in ten seconds while it chases a thread, which is the exact shape a monthly plan handles worst and a per-call rate handles best. And the call mix is unpredictable: an agent asked one question may search, then read a profile, then expand a thread, and you cannot enumerate that in advance the way you can with a cron job.

The practical implication for anyone testing on a free credit: budget by session rather than by month. Measure what one representative agent task costs end to end, a handful of calls at $0.0008, then multiply by expected sessions. Because our endpoints are also exposed as MCP tools on the same key and the same rate, that measurement is the same number whether the caller is your backend or a model, which is not true of every vendor.

A two-week test plan before you commit to any vendor

The cheapest way to avoid a bad data contract is to spend two weeks not signing one. This is the sequence we would run ourselves, and it works against any vendor in the category rather than only this one.

1. Days one to two: run the unhappy paths. Not one successful request. Pagination to the end of a real result set, a deleted object, a protected account, a malformed parameter, and a rate limit. What a vendor does at the edges is most of what you will live with.
2. Days three to five: measure your own density. Log objects returned against calls billed on your actual queries. That ratio is the single input that turns a rate card into a budget, and it is different for every workload.
3. Week two: run the real cadence for seven days. Whatever your monitoring interval would be, run it. A week of genuine traffic surfaces the empty-poll cost, the retry rate and the enrichment fan-out, which are the three things a spreadsheet estimate always misses.
4. Then, and only then, price it. Multiply out from measured calls rather than from wanted records, add the ceiling check, and compare vendors on the same measured basis. A comparison built on your own numbers is worth more than any table on any marketing page, this one included.

The reason a free credit matters is that it makes this plan free. $0.50 with no card is roughly 625 calls, which is enough to complete every step above before anyone approves a budget line.

Frequently Asked Questions