X API pricing: what pay-per-use actually costs

#Quick answer

The X API costs whatever you use. There are no tiers and no monthly plan in 2026: X's own pricing page states the API is pay-per-usage with no subscriptions, and there is no free tier, though a new account can now earn up to $70 in one-time free credits. You load credits in the developer console and every request draws them down, at $0.001 to $0.010 per resource read and $0.005 to $0.200 per write. A personal dashboard can run under a dollar a month. A link-posting bot at volume runs into the hundreds.

Last updated: October 2026

Almost every page ranking for x api pricing still shows a table of tiers with a Free row, a $100 Basic row and a $5,000 Pro row. Those plans are gone. X retired them across 2026 and moved everyone onto metered billing, which means the question "how much does the API cost" no longer has one answer. It has an arithmetic problem, and the inputs are published. Below is the current rate card straight from X's docs, five worked monthly bills for the projects people actually build, the two billing rules that change the total more than the prices do, and the credit rebate nobody mentions.

#There are no tiers any more

The X API (formerly the Twitter API) sold flat monthly subscriptions until 2026. That model is finished. Legacy Basic subscribers were migrated onto pay-per-use after 1 June 2026, and the Pro plan was deprecated on 14 August 2026, with individual subscriptions ending at each customer's cutover date after 1 September 2026 (Blotato's pricing guide, updated 10 September 2026, tracks both migrations). A developer signing up today is never shown a plan selector.

What replaced it is a prepaid credit balance. You buy credits in the developer console, and per X's pricing documentation (accessed 2026-09-30), "credits are deducted in real-time as you make API requests." There is still no free tier in the old sense of a monthly allowance that renews. What arrived on 2 October 2026 is a pair of one-time signup incentives worth up to $70, and they are narrow enough to deserve their own section below. The setup flow for getting an X API key now ends at a billing screen rather than a plan page, and until credits are loaded your calls fail rather than bill.

#The rate card

These are X's published prices, not estimates. Reads are billed per resource returned; writes are billed per request.

One line dominates the rest. A post containing a link is priced at $0.200, which is over thirteen times a plain post at $0.015. Nothing else on the card carries a multiplier like that, and it is the reason a link-heavy posting bot is the most expensive small project you can build on this API. Pushed events bill separately and at read-equivalent rates, so a webhook is not a way around the card: see the X Activity API for the per-event prices.

#Five worked bills

The rate card on its own tells you very little. Here is what it turns into for projects people actually ship, using the deduplication and owned-read rules described in the next section.

The spread between the first and the last row is roughly 800x, and none of it is explained by "tier." It is explained by how much new material the project touches. The dashboard re-reads the same handful of resources it already read. The listening tool discovers thousands of fresh post IDs every pass and pays full freight on each one.

For the theoretical ceiling: 3 million post reads at $0.005 is $15,000 in a single billing cycle, which is where a standard account stops and Enterprise begins.

#The two rules that actually set your bill

Both are in X's pricing docs and both are missing from most guides.

Resources are deduplicated within a 24-hour UTC day. Request the same post ID twelve times in one UTC day and you are charged once. That single line is why the dashboard row above costs under a dollar: polling hourly does not multiply the bill, because the resource set does not change. Two consequences follow. Align batch jobs to the UTC day boundary rather than local midnight, or one run straddling 00:00 UTC bills the same set twice. And when you need a known collection refreshed, refresh it inside one UTC day rather than spreading it over two.

Owned reads are billed at $0.001. Pulling your own posts, your own followers and your own engagement data is a tenth of the price of reading the same objects on someone else's account. If you are building a personal dashboard, structure it around owned-read endpoints and the bill barely registers. Most of the cost horror stories come from projects that read the public graph when they only needed their own slice of it.

The pattern underneath both rules is the same. X is pricing breadth, not effort. Depth against a fixed set is close to free. Discovery is what you pay for. That is worth knowing before you write the code, because it is much harder to retrofit.

#Up to $70 in free credits, and who actually gets it

X added two one-time credit incentives on 2 October 2026. It is the closest thing to a free allowance this API has offered since the old tiers were retired, and both grants are automatic: no code, no voucher, no form. The balance shows up in the Developer Console under Billing, Credits, Free credits, within about a minute of the qualifying action.

Stack both and a new account starts with $70 it never paid for. At the $0.001 owned-read rate that is 70,000 reads of your own data. In writes it is about 4,600 plain posts, or 350 linked ones.

The eligibility rules are narrow, and worth reading before you touch the billing page:

• The card has to be the first card on the account. Removing a card and adding it back does not reset anything, and X says so in as many words.
• The account must never have made a successful payment. One exception, and it is a useful one: buying credits while saving the card still earns the $20, so a first $10 purchase is not disqualifying.
• Prepaid cards earn nothing. They still work for buying credits. Same for any card whose type X cannot determine.
• Each physical card earns each incentive once, across every account. A second account using the same card gets nothing, which closes the obvious loop.
• Turning auto-recharge on grants nothing by itself. The match lands when the first recharge actually succeeds, so a declined card means no credit until a later one goes through.

Two details decide whether any of this is worth something to you. Free credits expire three months after they are granted, and they are spent before purchased credits, so any usage at all eats them first. That ordering helps on a project you are actively running and is worthless on one you plan to start next quarter. X also notes the incentives were still rolling out when the page was published, so an account that qualifies on paper may see nothing yet.

#Credits, auto-recharge and spend caps

Because the balance is prepaid, the controls around it matter as much as the prices.

• Auto-recharge takes a recharge amount and a trigger threshold. X's docs specify that it "triggers the first time your balance drops below the trigger threshold after having been at or above it," fires at most once every five minutes, and pauses once your balance is at or below zero.
• Spend limits set a maximum per billing cycle. Hit it and requests are blocked until the cycle resets. Set this before you set anything else. A loop bug on a $0.200 endpoint is a genuinely expensive mistake, and the cap is the only thing standing between you and it.
• Negative balances are possible. Requests are blocked "until you add credits to cover the negative balance," so a burst can overshoot zero rather than stopping neatly at it.
• Free credits are spent first. If you earned the signup incentives above, your purchased balance does not move until they are gone or expired. Watch the free-credit line rather than the total when you are estimating burn.
• xAI credit rebate. Buying X API credits earns free xAI API credits on a cumulative-spend ladder: 0% below $200, 10% from $200, 15% from $500, and 20% from $1,000. If your project already pays for model inference, that rebate is real money and almost nobody writing about API pricing mentions it.

#What you still cannot buy

Two limits are worth checking before you plan around the API at all.

The 3 million post reads per billing cycle cap is a hard ceiling on standard accounts. Above it, X directs you to Enterprise, which has no published price. Reported figures circulate widely, but X does not list one, so treat any specific Enterprise number you read as a third-party report rather than a rate.

And the API only does what the endpoints do. Rate limits still apply per endpoint on top of the pricing, and the developer agreement you accept at signup governs what your key is allowed to do. That document, not the rate card, is what decides whether a given automation is permitted. If your plan is mass data collection, read how scraping X with Python actually works in 2026 first, because the economics and the rules both changed.

#When the API is the wrong tool

The API is the right answer when you need data or actions no product exposes: custom analytics over your own history, an internal integration, a research pull, a genuinely novel app. It is the sanctioned route, and for those jobs nothing else substitutes. What the X API does and how to use it covers the endpoint surface in more detail. If you want to drive those endpoints from an AI client rather than write a client yourself, X now hosts MCP servers for the API, the docs and X Ads - the X MCP server guide covers the auth and the limits. For the single endpoint most likely to run up a bill, see X API search, where every read is priced per Post returned.

It is the wrong answer when the goal is your own posting and replying. Run the numbers on the link-bot rows above: $240 a month to publish 40 linked posts a day is more than most scheduling products cost outright, and you still have to build and maintain the thing. For that job, either a scheduler or a browser-based tool does the same work without a metered bill. Our roundup of X API alternatives covers the options, and scheduling posts on X covers the free routes.

X-Autopilot sits on the browser side of that line: it drafts and posts from real Chrome on your own Mac using your existing session, so there is no API key and no per-post charge. Be clear about the tradeoff. Browser-based automation on X is a gray area rather than an approved path, and running locally on your own residential connection is a smaller detection surface than a cloud tool posting through a shared IP pool, not an absence of risk. The API is the route X sanctions; it just prices itself out of ordinary posting.

#The short version of the math

Work out your bill in three steps before you write a line of code. Count the resources your project touches in a day, not the requests it makes, since duplicates inside a UTC day are free. Split that count into your own data at $0.001 and other people's at $0.005 or $0.010. Then add your writes, and multiply any linked post by $0.200 rather than $0.015.

Do that honestly and most projects land in one of two places: a couple of dollars a month, or several hundred. There is very little in between, and which side you land on is decided by design rather than by volume. Keep an eye on X's own daily limits too, because the platform caps still apply to anything you post, however you paid to post it.