Twitter API Cost Calculator

What changed in the February 2026 X API pricing?

Every cost estimate written before this year is now wrong in the same way, so it is worth stating the change plainly before you trust any figure, including ours. In February 2026 X replaced fixed monthly subscriptions with consumption billing. The $200 Basic and $5,000 Pro plans stopped taking new signups, and the default way to buy access became a rate per resource rather than a tier.

Basic then went further. X deprecated it outright, monthly and annual alike, and moved remaining subscribers onto pay-per-use from 1 June 2026 at the end of their billing cycle. Anyone who budgeted a predictable $200 a month is now on a metered bill, and the direction it moved depends entirely on whether they were using the old allowance. Pro is closed to new signups and X has not said publicly whether it faces the same migration, so treat its future as open rather than settled.

Two consequences for this calculator. First, there is no longer a plan to model, so the official column is a pure rate times volume calculation: $0.005 per post read, $0.010 per user read, $0.015 to create a post and $0.200 when that post carries a URL. Second, the pay-per-use tier carries a hard cap of 3 million post reads a month, which is a real cliff rather than a soft limit, and past it the only route is an Enterprise contract with no published price. If your projection lands near that number, the estimate above stops being the whole story.

Why did the X API get so expensive?

Mostly because the unit changed, not because a number went up. That distinction decides whether your own bill rose or fell, so it is worth being precise about.

Access used to be sold as a seat. You paid a fixed monthly figure, $200 for Basic or $5,000 for Pro, and inside that figure the number of records you read did not change the invoice. A request that returned a hundred posts cost the same as one that returned three. That pricing is expensive for a small workload, because the floor is the whole cost, and cheap for a large one, because the price does not move with volume.

Consumption billing moved the meter onto the records. A read is now $0.005 per post and $0.010 per user, so that same request returning a hundred posts bills a hundred times. Nobody changed their code and the bill moved anyway, in whichever direction their old allowance was being used. That is the whole mechanism behind the sticker shock, and it is why a comparison written before February 2026 is not merely out of date, it is measuring a different thing.

It also explains why per-call providers open such a wide gap on read-heavy work specifically. We bill the request; X bills its contents. On a workload that reads one record per request the two models converge. On anything that reads pages, they diverge by roughly the page size, which is why the tier table above shows the gap growing with volume rather than staying flat.

Can I still get the $200 Basic X API tier?

No, and the distinction worth knowing is that Basic is not merely closed to new customers, it is gone. X stopped taking Basic and Pro signups when consumption billing launched in February 2026, then deprecated Basic outright, monthly and annual alike, and moved the remaining subscribers onto pay-per-use from 1 June 2026 at the end of their billing cycle. There is no waitlist, no legacy path and no application.

Pro sits in a different position and guessing about it is expensive. It is closed to new signups, and X has not said publicly whether it faces the migration Basic did. An existing Pro subscriber should budget as though consumption billing is coming rather than assume the plan holds. A new project cannot buy it at any price, so for anyone reading this to size a build, Pro is not an option regardless of how it resolves.

For a budget written against the old $200 line, the useful reframe is that it was never a price, it was a floor plus an allowance. Under metered billing the floor is gone and only the usage remains. A job that read a few thousand posts a month against that plan will now pay a fraction of it. A job that filled the allowance will pay a multiple of it. The calculator above is the way to find out which one you are, and the answer is frequently the opposite of what people expect.

The 3 million post reads cap, and what happens at it

Pay-per-use is metered but it is not unlimited. The tier carries a hard ceiling of 3 million post reads a month, and it behaves like a cliff rather than a soft limit. There is no higher published rate to step up into. Past that line the only route is an Enterprise contract with no public price and a sales cycle attached.

Three million sounds generous until a real workload is put against it, and the reason it disappears quickly is the same per-object billing described above. A single keyword monitor polling every five minutes is 8,640 requests a month, which is nothing. But each of those requests bills for every post it returns, so a full page makes it 172,800 post reads from one monitor. Twenty such monitors, or one backfill of an active account's history, or any job that reads conversations rather than sampling them, reaches the ceiling inside a month.

The practical consequence is that the cap is a planning input rather than an operational one. By the time you meet it you are procuring rather than scaling, and procurement lead time is measured in weeks while a traffic spike is measured in days. If your projection lands anywhere within sight of 3 million, price the alternative before you need it.

For reference, the same volume on our side is a question about requests rather than records, so it does not produce a cliff at all. Three million posts at a full page of 20 is 150,000 calls, or $120 at $0.0008 a call. Nothing changes structurally at that number, because there is no tier above it to negotiate into.

Pay-per-use, in plain English

Consumption billing swaps one uncertainty for another. 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 why a calculator is now more useful than a pricing table.

The mechanic is simple: you buy credit up front, and each call debits it at a published rate. What differs between vendors, and what decides the answer, is the unit. The official X API bills per object, so a request returning a hundred posts debits a hundred post reads. We bill per call, so one request costs $0.0008 whether it returns twenty tweets or three. That single difference is most of the gap in the table above, and it also explains why the two numbers cannot be compared by reading the rate cards side by side.

Three questions make any two consumption rates comparable, and they are worth asking of every vendor you price, not just these two. Is the unit an object or a request? Is a failed call billed? Does unused credit expire? Our answers are a request, no, and never. Once you have those three for each side, a spreadsheet does the rest.

How this calculator models a call, and where it is optimistic

Any tool that turns tweets into dollars has an assumption buried in it, and a calculator that hides its own is not much use. Ours is page density: converting a tweet count into a call count requires deciding how many tweets a call returns, and the figures above assume a full page of 20.

That is the best case rather than the typical one. Across 396,817 of our own read calls, pages averaged about 13 tweets, and search pages specifically averaged closer to 8 (per our own billing logs), because a narrow query simply has fewer matching results to fill a page with. So the honest range for delivered cost is $0.06 to $0.11 per 1,000 tweets rather than a flat $0.04, which is between one and a half and three times the headline. If you want a conservative number, take the figure above and multiply by three.

The direction of that error is worth knowing too. Because the rate is per call rather than per tweet, a denser query makes our number better and never worse, so the way to move your real cost toward the headline is to broaden queries and paginate less often, not to negotiate a rate.

Five ways a Twitter API cost estimate goes wrong

Most budgets that blow out do so for one of five reasons, and none of them is the unit rate. They are worth checking against your own projection before you commit to a vendor.

1. Counting the data you want, not the calls you make. A monitoring job that polls every five minutes makes 8,640 calls a month per query whether or not anything matched. On a per-call rate an empty poll still costs a call; on a per-object rate it costs nothing. That asymmetry can invert a comparison entirely for a low-yield query.
2. Forgetting the enrichment fan-out. Pulling 100,000 tweets is one number. Pulling the author profile behind each one is another workload on top, and on vendors that price profile lookups above their standard rate it can be the larger half of the bill. Our reads are one rate, so a profile call is a call.
3. Ignoring retries and failures. Ask whether failed calls are billed before you size a retry budget. We do not bill them, so a backoff loop costs time and not money, but that is not universal and on some scraping platforms a run that returns nothing bills in full.
4. Modelling a plan you will not fill. A subscription's headline rate assumes full consumption. A $40 plan used at ten percent is ten times its advertised per-unit price, and exploratory or seasonal workloads almost never fill a plan. The floor, not the rate, is the real cost of spiky volume.
5. Missing the ceiling. The official pay-per-use tier caps post reads at 3 million a month. A projection that crosses it is not a bigger bill, it is a different commercial arrangement with a sales cycle attached. Check where your growth curve meets that line.

The general defence is to model calls rather than records, and to run one week of real traffic against a free credit before signing anything. Our $0.50 signup credit is about 625 calls, which is enough to measure your own page density rather than inheriting ours.

Measuring your own tweets-per-call multiplier

The single input that turns this calculator from an estimate into a budget is your own page density, and you can measure it in an afternoon on free credit rather than inheriting our average.

The method is two counters. Run the queries you actually intend to run, not a broad test query, and log two numbers per call: how many objects came back, and that you made a call. Divide the first total by the second after a few hundred calls and you have your multiplier. Then divide $0.0008 by that multiplier and multiply by a thousand, and you have your true cost per 1,000 tweets, specific to your workload.

Expect it to land between our two measured figures. Timeline and follower work tends to fill pages and lands near the top of the range. Narrow keyword searches run thinner, because a tight filter simply has fewer matching results available to fill a page. Neither is a defect, and knowing which one you are is the difference between a budget that holds and one that is optimistic by a factor of three.

What a call costs across all 109 endpoints

The calculator models one blended read rate, which is right for sizing and wrong in the details, because not every call bills the same. Here is the whole rate card, read from the same file the biller is kept in sync with rather than from a marketing page.

Two rows in that table matter more than the rates themselves. 24 of 109 endpoints bill nothing at all, and that is a deliberate choice rather than a promotion: a customer whose balance has run out should still be able to read their balance and find out why, so account, monitor, webhook and feedback calls are free. And 62 of 109 sit at the flat $0.0008 read rate, which is the reason a single blended figure models most workloads honestly in the first place.

The tiers above standard are narrow and each has a physical reason. Full thread expansion and Grok chat hold a connection open across several upstream round trips. Full account history walks every page on your behalf rather than handing you a cursor. A login is billed once and only when it succeeds. The split across the catalogue is 65 reads and 44 writes, and simple write actions, liking, retweeting, bookmarking, following and their undos, bill at the same $0.0008 as a read, so adding engagement to a read pipeline does not move it into a different price class.

How far the $0.50 signup credit actually goes

Every new account starts with $0.50 of balance and no card. That is credit rather than a trial window, so it does not expire on a date, and it buys a specific and calculable amount of work rather than an unspecified taste of the product.

At the standard read rate of $0.0008 a call, $0.50 is 625 calls. What those calls return depends entirely on your queries. On a full page of 20 tweets it is 12,500 tweets. At the roughly 13 tweets per call we measure across our own read traffic it is closer to 8,100. Both figures are real; which one you get is a property of your queries rather than of the credit.

That is the case for quoting a free allowance in calls rather than in records. The number worth taking away from a free credit is not how much data arrived, it is your own tweets-per-call multiplier, measured on the queries you actually intend to run. That multiplier is the one input this calculator cannot supply for you, and 625 calls is comfortably enough to measure it. Run the real job on the credit and you leave with a budget rather than an estimate.

Costing an agent workload, not just a scheduled pipeline

This calculator, like every other one in the category, assumes a scheduled pipeline: a known query at a known cadence. A growing share of real traffic is a language model deciding at runtime what to look up, and that workload behaves differently enough on cost to need its own model.

Two things change. Volume is bursty rather than flat: nothing for an hour, then a dozen calls in ten seconds while the model follows a thread. That is the shape a monthly plan handles worst, because you must size the plan for the peak and pay for it during the quiet. And the call mix is not enumerable in advance, since an agent asked one question may search, read a profile, then expand a conversation depending on what it finds.

So budget by session rather than by month. Measure the end-to-end cost of one representative agent task, typically a handful of calls at $0.0008, then multiply by expected sessions and add headroom for the long tail where the model keeps digging. Because the same endpoints are exposed as MCP tools on the same key and the same rate, that per-session figure is identical whether the caller is your backend or the model itself.

What is the cheapest way to read my own X data?

If the data you want belongs to your own account, the cheapest route is not an API at all, and that is worth saying plainly on a page that sells API calls.

X lets you request a data archive from your account settings. It is free, it covers your own posts, likes, direct messages, follower list and ad interactions, and it arrives as a bulk download. For a one-off export, a personal backup or a records request, that is the correct answer and every paid route is a worse version of it. Nobody should be paying for their own back catalogue.

An API earns its place when the archive is the wrong shape for the problem, which happens in three cases. You need the data continuously rather than once, because an archive is a snapshot and a fresh one takes hours to prepare. You need it arriving in a pipeline rather than sitting in a zip file. Or you need data about accounts that are not yours, which an archive cannot contain by definition.

If it is the continuous case and the account is yours, the cost is small and easy to bound, because reading your own timeline is a standard read at $0.0008 a call like any other. A job polling your own account hourly is 720 calls a month, about $0.58. Confirming that on your own balance costs nothing, since account reads sit in the free tier above.

Cost controls and production checks before you go live

An estimate is a projection, and what stops a projection turning into a surprise is a small amount of instrumentation. Most of it costs nothing to run, so there is no reason to leave it until after the first invoice.

Know which error costs money and which does not. A 402 and a 429 look alike in a log and mean opposite things. A 402 says the prepaid balance is short, and no amount of retrying will clear it. A 429 says the request rate crossed the ceiling on your key, which is 600 requests a minute with 20 in flight, and backing off does clear it. Retry logic that treats the two the same either hammers a wall that will never open or gives up on a condition that would have resolved in a second.

Poll the balance, not the invoice. Account reads are in the free tier, so a job can check its own remaining balance on every run at zero cost and alert before it runs dry rather than after. Under consumption billing there is no monthly statement arriving to tell you what happened last month, which cuts both ways: no bill shock, but also no scheduled moment where somebody looks.

Count calls in your own code, not just records. The billable unit here is the request, so the thing worth logging beside every response is that a call was made. A counter in your own client is the cheapest possible reconciliation against what you are charged, and it doubles as the numerator for the tweets-per-call multiplier described above.

Treat the prepaid balance as the spend cap it already is. Because credit is bought up front and calls debit it, the most a runaway loop can spend is what is sitting on the account. That is a materially different safety property from a metered account with a card attached, where a bug bills until a human notices. It is worth using on purpose: fund the balance to the size of the mistake you are willing to make, and top it up deliberately.

Choose the right route for your workload

Four routes exist and a cost calculation only decides between two of them. Work down this list and stop at the first one that matches, because reaching for a price comparison in the wrong case is how people spend a week optimising something that was never the deciding variable.

1. The data is your own and you need it once. Request the free archive from X. No API, no cost, no integration to maintain.
2. You need a signed-in user flow, filtered-stream delivery, or a compliance obligation that names the first-party API. Buy the official API and stop reading cost comparisons. Capability decides this one, and no per-1,000 figure moves it.
3. You need public data continuously, read-heavy, under the 3 million post read cap. This is where the calculator applies and where the gap is widest, because the choice is between paying per record and paying per request.
4. You need public data above that cap. The official route is an Enterprise contract with an unpublished price and a sales cycle. A per-call provider has no equivalent cliff, so the question turns into throughput and reliability rather than procurement.

Most workloads that reach a page like this are case three, which is why the calculator leads. Cases one and two are common enough that answering them with a price table is a wrong answer delivered confidently, and case four is common enough that it is worth checking your growth curve against before you commit to either side.

Where this calculator stops being the right tool

A calculator prices unit rate against volume. There are three situations where those two variables are not what decides your bill, and in each of them the number above is accurate and beside the point.

The first is when you need the official API for reasons that are not about data: a signed-in user flow, a compliance obligation, or filtered-stream delivery. Cost is not the deciding variable there, capability is, and no per-1,000 figure changes the answer. The second is when a projection crosses the 3 million post-read cap, because past that line the question is a contract rather than a rate. The third is when the dominant cost is not the API at all: storage, egress and the engineering time to maintain an integration routinely outweigh a data bill measured in tens of dollars, and optimising the small number while ignoring the large one is a common way to spend a week saving nothing.

The honest use of a tool like this is to establish that the data line is small, then go and look at the ones that are not.

Frequently Asked Questions