X rate limits by plan: what each tier actually allows

X overhauled its API pricing twice in the first half of 2026, and the changes hit automation budgets hard. But the limits that govern day-to-day publishing on X run on two separate systems: the API quota layer and the UI-level caps that apply to every account regardless of plan. Most guides conflate them. This one separates them, prices out the real cost differences by workflow type, and maps what each tier actually permits.

X Twitter Rate Limits by Plan 2026: The Full Breakdown

X publishes its limits across multiple help pages, and the structure is easy to misread. The posting caps, read limits, and follow quotas that most guides cite are UI-level constraints applied to every account through the web interface. The API has a separate quota system. Which system governs your workflow determines which numbers matter to you.

All X accounts share a 2,400-post daily cap at the UI level. This ceiling covers original posts, replies, reposts, and quote posts combined. A Premium+ subscription does not raise it. A pay-per-use API plan does not raise it. It is flat across tiers, and a rolling sub-limit of roughly 50 posts per 30-minute window sits inside it.

Read limits are where tiers diverge. Free accounts can view approximately 1,000 posts per day. Premium subscribers ($8 per month) get up to 10,000 per day. New accounts start at roughly 500 per day while the account warms into normal activity.

Follow limits split by subscription: free accounts are capped at 400 per day, Premium and Premium+ subscribers at 1,000 per day. All tiers hit a hard 5,000-account following ceiling regardless of subscription level. The details of the ratio gate that activates at that ceiling are in the follow section below.

The single most important operational note for automation planning: real-browser automation tools operate entirely outside the API quota system. The relevant limits are the UI-level ones, 2,400 posts per day and roughly 50 posts per 30 minutes. API pricing tiers and write quotas do not apply to browser-based workflows. If your tool submits actions through the X web interface rather than through OAuth API calls, every dollar figure in the API repricing discussion is irrelevant to your monthly budget.

API Limits vs. UI Caps: Two Different Systems Most Guides Conflate

X enforces two distinct rate-limit systems that rarely interact. The UI layer is account-level: it applies to any action taken through the X web interface or mobile app, regardless of whether the account has API access. The API layer applies only to requests routed through developer application tokens under OAuth. A single account can be subject to both simultaneously if it is also connected to an API-based app, but the limits are tracked separately.

Real-browser automation submits actions through the X web interface, not through the API. The April 2026 API repricing, including the $0.20-per-URL-post charge introduced on April 20, 2026, has zero direct cost or capability impact on browser-based workflows. Those tools see the same UI-level limits as any manual user. The API price increases are beside the point for them.

The April 20, 2026 update did something more significant than raise prices: it removed follow, like, and quote-post write endpoints from all self-serve API tiers. These actions are now available via the API only to Enterprise subscribers. Developers who built engagement automation on the self-serve API lost those capabilities on that date, with no grandfathering for Basic or Pro subscribers.

Browser-based tools did not lose those capabilities. They can still execute follows, likes, and quote posts within X's UI-level limits, without requiring any API plan. For practitioners who need engagement automation alongside publishing and do not have an Enterprise contract, browser-based tooling became the only practical non-Enterprise option after April 20.

The question "which plan do I need?" has a completely different answer depending on your toolchain. If your automation routes through the X API, you need to evaluate API tiers: pay-per-use for new developers, or legacy Basic and Pro if you enrolled before February 2026. If your automation routes through a browser-based agent, the UI-level limits are the same for all subscription tiers, and the plan question reduces to whether you need the higher read allowance that Premium provides.

What Are the X Twitter Rate Limits by Plan for Posting in 2026?

At the UI level, every X account posts under the same ceiling regardless of subscription: 2,400 posts per day, counting original posts, replies, reposts, and quote posts equally. That daily cap sounds generous until you look at the rolling sub-limit sitting inside it.

The binding constraint for most high-cadence publishing workflows is not the 2,400-post daily cap. It is the rolling 30-minute window, which allows roughly 50 posts before enforcing a temporary lockout. We see this with thread publishing and content queues consistently: a practitioner pushing a large thread at high speed runs into the rolling window, not the daily limit. The 30-minute ceiling is what stalls a workflow in practice.

Read limits differ meaningfully across tiers. Free accounts are limited to approximately 1,000 posts per day. Premium subscribers get up to 10,000 per day. New accounts start at roughly 500 per day. If content research or competitive monitoring is part of your workflow, the difference between free and Premium on the read side is significant.

For accounts using the X API under pay-per-use pricing, the posting costs as of April 20, 2026 are: $0.015 per plain-text or media post write, and $0.20 per post containing any URL. Read costs run $0.001 per owned resource, covering your own posts, mentions, followers, and lists, and $0.005 per standard post read on other accounts' content.

Pay-per-use has a monthly ceiling of 2 million post reads. Volume above that requires an Enterprise contract, which starts at approximately $42,000 per month. That threshold matters for analytics and social listening workloads, not typical content publishing, but teams running both functions under one account should plan for it.

Follow and Read Limits Across X Subscription Tiers

Follow limits split by subscription tier. Free accounts are capped at 400 follows per day, with hourly soft caps of 30 to 50 actions before the system slows responses. Premium ($8 per month) and Premium+ ($16 per month) raise the daily limit to 1,000, with hourly soft caps of 80 to 100. Premium Basic ($3 per month) sits between those two, closer to 500 per day.

At 5,000 accounts followed, every tier hits a hard ceiling. X then enforces a roughly 1:1.1 follower-to-following ratio before permitting additional follows. Your follower count needs to clear that ratio before you can follow anyone beyond the 5,000-account mark. This ratio gate applies regardless of subscription level and is not lifted by Premium or Premium+ plans.

Automation that continues attempting follows at this ceiling is one of the more common triggers for account restrictions. The pattern of repeated failed follow attempts reads as automated behavior even when the daily count is low. Accounts that ignore the ceiling and keep sending follow requests tend to collect warnings faster than those that wait out the ratio gap. The practical fix: pause follow campaigns at the 5,000 ceiling, grow your follower count until the ratio clears, then resume.

On April 20, 2026, X removed follow, like, and quote-post write endpoints from all self-serve API tiers. These actions are now Enterprise-only through the API. Developers on legacy Basic or Pro plans who were using follow endpoints had them cut off on that date. No self-serve tier retains API access to these actions.

Browser-based tools can still execute follows, likes, and quote posts at UI-level limits without any API plan. This capability gap between API-based and browser-based automation is now a primary consideration when evaluating tooling. For practitioners who want engagement automation alongside publishing, the April 2026 change effectively forces a choice between browser-based tools or an Enterprise API contract.

The April 2026 API Repricing: Free Tier Gone, URL Posts at $0.20

On February 6, 2026, X discontinued the free API tier and closed signups for both Basic ($200 per month) and Pro ($5,000 per month) plans to new developers. Pay-per-use became the sole entry point for any new API access from that date. The change gave developers operating on free-tier access no migration path other than upgrading to pay-per-use.

Legacy Basic and Pro plans remain active for subscribers who enrolled before February 2026. Legacy Basic provides 50,000 post writes and 15,000 reads per month at the flat $200 monthly fee. Legacy Pro provides 300,000 post writes per month and 1,000,000 reads at $5,000 per month, along with full-archive search and streaming endpoints. Neither plan accepts new signups. These are the last flat-rate API tiers that exist.

Then came April 20, 2026. Plain-text and media post write costs rose from $0.010 to $0.015. URL-containing post writes jumped from $0.010 to $0.20, a 1,900% increase. Owned reads dropped to $0.001 per resource, a meaningful discount for analytics-heavy workflows that pull their own post data, mentions, and follower lists.

The URL-post pricing is where the cost math turns severe. At $0.20 per URL-containing write, 1,000 link posts costs $200. That is the full monthly cost of legacy Basic, a plan that covered 50,000 writes at the prior rate. For newsletter promotions, blog amplification, or any publishing workflow that leans on link posts, the cost calculation under pay-per-use needs to be run separately for text-only posts and URL posts. They behave like two different products at these price points.

Any team currently on a legacy Basic or Pro plan should audit their usage before making changes. Dropping a legacy plan is irreversible. There is no re-entry path to those flat-rate tiers once you cancel. Pay-per-use is the only available alternative, and at URL-post volume the cost difference becomes apparent within the first billing cycle.

30-Minute Rolling Window: The Ceiling High-Cadence Publishers Hit First

Most coverage of X's posting limits focuses on the 2,400-post daily cap. That number is almost never the operational constraint for real publishing workflows. The rolling 30-minute sub-limit, roughly 50 posts per window, is what causes lockouts in practice.

We see this with thread publishing consistently. A practitioner scheduling a 60-tweet thread at high cadence exhausts the rolling window in approximately 20 minutes and receives a temporary posting lockout. The account is not suspended; it simply cannot post until the 30-minute window resets. From the user's perspective the effect looks like a tool malfunction, which is why this constraint causes more operational confusion than the daily cap does.

The fix requires changing scheduling architecture, not just slowing down. Distributing thread segments across multiple 30-minute windows by inserting scheduled gaps between batches avoids the lockout entirely. The same daily volume stays identical; only the distribution changes.

Original posts, replies, reposts, and quote posts all count equally toward the rolling 50-post sub-limit. There is no post type that costs less than another. If you are mixing original content with a repost campaign in the same queue, every action draws from the same bucket.

The rolling window is enforced at the account session level. Any automation tool, whether API-based or browser-based, is subject to it when actions flow through an authenticated account session. Choosing a higher API tier or a browser-based tool does not bypass this constraint. It is platform-level enforcement independent of how the action was submitted.

Pay-Per-Use Pricing and X Twitter Rate Limits by Plan: The Cost Breakdown

Current pay-per-use rates, effective April 20, 2026: $0.015 per plain-text or media post write, $0.20 per URL-containing post write, $0.001 per owned read, and $0.005 per standard post read on other accounts' content. These rates apply to all new API users. Legacy Basic and Pro subscribers pay flat monthly fees on different terms while those plans remain available to them.

The crossover math matters for teams evaluating their tier options. For URL posts at $0.20 each, the breakeven is clear: 1,000 URL-containing posts per month reaches $200, which equals the full monthly price of legacy Basic, a plan that covered 50,000 writes. For plain-text posts at $0.015 per write, divide legacy Basic's $200 monthly cost by that rate to find where pay-per-use draws even. High-frequency link posters should not treat pay-per-use as a minor upgrade from the old pricing. At URL-post volume, it is a different cost structure entirely.

Monthly post reads are capped at 2 million under pay-per-use. Volume above that ceiling requires Enterprise at approximately $42,000 per month. Most content publishing workflows will never approach the read ceiling; it matters primarily for analytics platforms and social listening tools that read millions of posts per month as a core function.

Pay-per-use billing includes a deduplication rule: X charges only once per unique resource within a 24-hour UTC window. Re-fetching the same post, user profile, or bookmark multiple times in a day counts as a single charge. This benefits analytics workloads that periodically refresh the same data. For publish-heavy content workflows that are writing new posts rather than re-reading existing ones, the deduplication rule provides no cost savings.

One factor that changes the effective cost for some teams: X returns a percentage of API spend as Grok and xAI credits, in the range of 10 to 20 percent. Teams that are already using Grok in content or research workflows should account for this rebate before committing to a pricing tier. At meaningful API spend volume, the effective cost of pay-per-use is lower than the listed rates once the credit return is factored in.

Build a Posting Schedule That Survives Behavioral Detection

X's behavioral detection does not look only at daily counts. It flags timing regularity, action velocity, continuous 24/7 activity without natural breaks, and repetitive content structures. An account that stays under every published daily limit can still collect a restriction warning if its behavioral pattern looks automated.

The signal that surprises most practitioners is periodicity. An account posting at mechanically consistent intervals, say exactly every 2 hours around the clock with no variation across weekdays or weekends, attracts ML scrutiny faster than an account posting the same total daily volume with natural spacing variance. X's system is calibrated to detect that regularity. Volume is not the flag; the rhythm is.

Practical cadence design: 8 posts per day with plus-or-minus 15-minute jitter in posting intervals, a realistic overnight gap with no activity, and some variation in cadence across the week. That pattern does not guarantee immunity, but it avoids the clearest automation signals in X's detection stack. The key variable is periodicity, not just total daily volume.

X's automation rules explicitly prohibit automated follow/unfollow, auto-liking, engagement pods, DM spam, and follow-churn, the pattern of following then unfollowing within 24 to 48 hours. These are the leading causes of account suspension for automation-adjacent activity, and the prohibition applies equally across all subscription and API plan tiers.

Staying within the published daily limits does not guarantee account safety. X can restrict accounts for behavioral pattern signals alone, regardless of plan tier or API subscription status. The numerical limits define the ceiling. How you approach that ceiling, meaning the timing distribution, variance, and overnight behavior, determines whether your activity reads as human or automated.

Frequently asked questions