How X's For You timeline algorithm works
Trace how X builds viewer context, retrieves and filters posts, predicts engagement with Phoenix, and selects a For You timeline.
The whole story in 5 lines
X builds each For You feed by turning one viewer's context into candidates, eligible survivors, isolated predictions and a...
- The request begins with viewer history and social rules, not with a universal list of popular posts.
- Thunder contributes recent followed posts while Phoenix retrieval discovers relevant posts beyond the follow graph.
- Eligibility filters remove duplicates, stale items, seen posts and blocked authors before expensive ranking.
- Phoenix predicts several actions per candidate while an attention mask prevents candidates from influencing one another.
- Weighted predictions, source adjustments and author diversity turn scored candidates into the served order.
The Map
A For You feed is not one permanent ranking. X assembles a fresh candidate pipeline for a viewer, using the context available when that person refreshes.
A candidate is a post that may be shown, while context is the viewer information used to judge whether that post fits this request.
Retrieval gathers possible posts, filtering removes ineligible ones, and ranking orders the survivors by predicted value for this viewer.
Home Mixer orchestrates those jobs, while Thunder supplies recent followed posts and Phoenix handles discovery plus transformer based scoring.
We will keep one illustrative viewer and candidate set throughout the lesson. Now let us begin with the context that shapes every later decision.
Build Viewer Context
The journey starts with one viewer and one refresh request. Home Mixer turns account facts and request data into a context packet for every later stage. Nothing is ranked before this packet exists. That ordering makes the evidence boundary explicit from the start.
Recent likes, replies, reposts, and dwell actions form an ordered trail. That history gives the models evidence about what has held this viewer's attention.
Follow, block, and seen-post records add hard rules beside those preferences. What belongs in the request before retrieval?
The completed packet combines viewer preferences with eligibility rules. Retrieval can now search widely without forgetting blocked authors, seen posts, or the allowed discovery scope. Both travel together so retrieval cannot silently discard policy.
Adjust History and Discovery, then compare the interest signal and retrieval scope under fixed viewer rules.
The request context is now the shared input for every downstream decision. Next, we will send that packet to sources that gather possible posts. Every candidate source reads the same request boundary.
Gather Candidates
Now that the request has context, retrieval needs a manageable set of possible posts. Scoring the entire X corpus for one refresh would be impractical. Retrieval narrows that impossible search into a working deck. Ranking can then inspect each member carefully.
Thunder reads recent posts from followed accounts. This in-network stream preserves the viewer's social graph and supplies familiar authors without searching globally.
Phoenix retrieval uses the viewer representation to discover relevant out-of-network posts. That second stream introduces topics and authors beyond existing follows.
The two streams merge into one candidate deck while keeping source identity attached. Later rules can treat every post consistently and still apply source policy.
Switch the Sources control between Mixed and Following. Compare the two-source deck with the smaller in-network pool while viewer context stays unchanged.
Retrieval widens the choice set before expensive ranking begins. Next, explicit eligibility rules will remove candidates that should never reach Phoenix scoring.
Remove Ineligible Posts
The merged deck may contain repeated, stale, or disallowed posts. Home Mixer checks eligibility before spending expensive Phoenix ranking work on any candidate.
Deduplication keeps one copy when the same post arrives through multiple sources. Retrieval overlap therefore cannot occupy several positions in the final feed.
Seen-post memory and social rules remove viewed or blocked content, while the age rule removes old posts. Which cards survive every eligibility rule?
Rejected cards leave through reason-specific chutes that preserve why each candidate failed. Only the remaining posts continue toward the transformer scorer.
The survivor row now contains only posts that satisfy this request's explicit rules. These candidates have earned the more expensive model work that follows.
Switch Filter policy. Follow x707 as Strict age removes it from the eligible survivor row.
Filtering has separated hard eligibility from learned preference. Next, Phoenix will score every survivor while preventing temporary batch neighbors from influencing one another.
Score with Phoenix
★ If you remember one thing · Candidate isolation keeps a post's score independent of the neighboring posts in its ranking batch.
We now have eligible candidates, so Phoenix combines viewer history with each post. It predicts actions such as favorite, reply, repost, dwell, and negative feedback. That boundary is the core scoring guarantee.
The attention mask lets every candidate read the shared viewer history. Each candidate position can also read itself, but it cannot read neighboring candidates.
The same target post now enters two batches with different neighbors. If candidate isolation works, should its output meter move between those batches?
Both output meters stop at the same length because the target sees identical viewer context and self data. The different neighbors remain disconnected from its score.
Switch Candidate isolation. Compare stable meters with the divergence created by connected temporary neighbor paths.
Candidate isolation makes ranking independent of temporary batch composition. Next, Home Mixer will combine the action predictions and apply serving policy to choose the feed. That makes downstream comparisons easier to reason about.
Select the Feed
Phoenix has produced several action probabilities for every survivor. Home Mixer still needs one ordering value that can compare those candidates consistently.
A weighted scorer multiplies every action probability by its configured weight. Positive and negative contributions then add into one raw candidate score.
Candidates sort by raw score, but repeated authors and out-of-network posts may receive policy adjustments. What can change before the feed is served?
Author diversity and source policy reshape the order rather than inventing posts. The same scored deck can therefore produce different final sequences for different goals.
The final stack contains the top policy-adjusted survivors for this request. That ordered stack is the illustrative For You timeline returned to the viewer.
Toggle Author diversity and Feed goal. Compare the served order and discovered-post discounts before delivery.
Selection converts model predictions into a policy-aware served order. Now let us step back and connect the entire request pipeline from context to feed.
The Whole Feed
We started with viewer context because every later decision needs the same history, social rules and impression memory for this one request.
Then retrieval widened the choice set by combining recent followed posts from Thunder with discovered candidates from Phoenix.
Filtering narrowed that deck using explicit eligibility rules before expensive ranking work began, separating policy gates from model preferences.
Phoenix predicted several actions for each survivor while candidate isolation prevented temporary batch neighbors from changing a post's score.
Finally, weighted predictions, diversity and source adjustments produced the served order that this viewer receives on the For You screen.
The published architecture and names are real, while our small values are illustrative. Together they show that a personalized feed is a staged request pipeline.
The whole story in 5 lines
X builds each For You feed by turning one viewer's context into candidates, eligible survivors, isolated predictions and a...
- The request begins with viewer history and social rules, not with a universal list of popular posts.
- Thunder contributes recent followed posts while Phoenix retrieval discovers relevant posts beyond the follow graph.
- Eligibility filters remove duplicates, stale items, seen posts and blocked authors before expensive ranking.
- Phoenix predicts several actions per candidate while an attention mask prevents candidates from influencing one another.
- Weighted predictions, source adjustments and author diversity turn scored candidates into the served order.