Skip to main content

X/Twitter algorithm guide

How the X/Twitter algorithm works in 2026

Publishing a good post does not guarantee that the right people will see it. X builds each For You feed for one viewer at a time, using several selection, prediction, and filtering steps before a post earns a place.

By ImNotAVirus Updated September 1, 2026

The short answer

The X/Twitter algorithm does not give every post a universal score and send the winners to everyone. It builds the For You feed separately for each viewer.

For each request, X gathers possible posts from accounts the viewer follows and accounts they do not follow. It removes candidates the viewer should not see, predicts how that person may respond to each remaining post, applies ranking adjustments, keeps the strongest candidates, and runs another visibility check before building the final feed.

That distinction matters. A post can miss a viewer because it was never retrieved, because it was filtered, or because other candidates scored higher for that person. "The algorithm did not like my post" hides several different problems behind one sentence.

The steps below come from the official X For You feed repository, updated in August 2026. The repository contains the core recommendation code, but X also documents experiments and a small set of unpublished files. It is useful evidence, not a complete explanation for every impression.

X gathers candidates, filters them, predicts viewer actions, ranks the survivors, and applies final visibility checks.

Step 1: X starts with the viewer

The feed request begins with context about the person opening X. That context includes recent actions, followed accounts, blocks, mutes, muted keywords, followed topics, and posts already seen or served.

This is why two people can open X at the same time and receive completely different feeds. The ranking model is not asking whether a post is good in the abstract. It is estimating whether this viewer is likely to find it worth their attention.

The practical consequence is easy to miss: copying the format of a large account does not copy its audience. Their post enters feeds with a different relationship graph, different viewer histories, and different competing candidates.

Step 2: candidate posts come from two places

X calls the two groups in-network and out-of-network.

Candidate sourceWhat it contributes
In-networkRecent posts from accounts the viewer follows, supplied by Thunder
Out-of-networkPosts from accounts the viewer does not follow, found through Phoenix retrieval and SimClusters

These systems create a pool of possibilities. Retrieval is not the same as ranking: being selected as a candidate only gives a post the chance to compete.

The separate guide on how X recommends posts to non-followers explains that discovery path in more detail.

Step 3: X loads the context needed to judge each candidate

Candidate hydration adds the post text and media, author details, language, engagement counts, quoted-post context, account labels, and other information used later in the pipeline.

This stage is plumbing, but it explains why the model can consider more than a sentence and a like count. It evaluates a post inside a viewer, author, content, and account context.

Step 4: obvious mismatches leave before scoring

Pre-scoring filters remove candidates that should not compete for this request. The published list includes:

  • duplicate candidates returned by more than one source;
  • posts older than 48 hours;
  • posts the viewer has already seen or received in the session;
  • content from blocked or muted accounts;
  • posts matching the viewer's muted keywords;
  • subscriber-only posts the viewer cannot access;
  • some replies and reposts from outside the viewer's network.

Many of these filters are personal to the viewer. A muted keyword can remove a post for one person while the same post remains eligible for someone else. This is different from an account-wide penalty.

Step 5: Phoenix predicts possible viewer actions

For each surviving candidate, Phoenix predicts the chance that the viewer will take several actions. The public list covers positive engagement, clicks, attention, follows, and negative feedback.

Those predictions are combined into a score. X then applies adjustments including repeated-author decay, an out-of-network discount, and a boost that can lift newer authors toward a target position. A separate reranking service can change the order again.

The important word is "predicts." X is not adding the post's public likes and replies into a simple formula. The guide to X/Twitter ranking signals explains why reading the published weights as points per engagement produces the wrong answer.

Step 6: the highest-scoring candidates survive selection

X sorts the candidates by their final score and keeps the top group. A post that loses here was not necessarily bad. It lost a viewer-specific competition at that moment.

The competing set changes with the viewer, time, recent activity, experiments, and available inventory. This is one reason a rigid recipe such as "use this format and receive more reach" cannot be derived from the repository.

Step 7: visibility is checked again

Ranking decides order. Visibility filtering decides whether a post may be shown at all.

After selection, X checks visibility decisions for the post and related content, then collapses additional branches of the same conversation. The final blending pipeline can insert ads, Who to Follow suggestions, and prompts around the ranked posts.

Our visibility filtering guide separates ordinary viewer-level filters from labels that can limit distribution. That is a better starting point than treating every weak result as a shadowban.

What creators can use from the code

The repository supports four useful conclusions:

  1. Reach is viewer-specific. A post is competing for individual feeds, not one global chart.
  2. Retrieval, ranking, and visibility are different gates. A weak result does not identify which gate mattered.
  3. The model predicts several kinds of response, including attention and negative feedback. Likes alone do not describe the decision.
  4. Experiments and configuration changes mean the live mix can move. One code snapshot should not become a permanent content rule.

It does not support a universal posting formula. The sensible response is to use the public code to form a hypothesis, then test that hypothesis against your own account.

Turn the explanation into an account decision

PilotMyX cannot reveal the hidden score X assigned to a post, and it should not pretend to. It can show what happened across the posts and replies you wrote, keep their available metrics together, and help an AI agent compare fair samples before recommending what to test next.

Start with a question the public repository cannot answer for you:

Which topics and openings repeatedly earn attention on my account, after I separate posts from replies and remove the largest outliers?

That moves the work away from generic algorithm folklore and toward a decision you can measure.

Use your own account

Turn the next guess into a decision you can test.

Analyze what works on my account