A comprehensive, interactive guide to how X decides what appears in your For You feed — from raw candidates to ranked results.
The For You feed blends posts from accounts you follow (in-network) with posts found by Phoenix retrieval and SimClusters (out-of-network). Phoenix predicts what you may do next, Home Mixer turns those probabilities into a score, and a separate visibility system decides whether a post can be shown at all.
An in-memory post store that tracks recent posts from all users in real time. It serves posts from accounts you follow in sub-millisecond lookups via Kafka-ingested events.
Rust · In-MemoryA two-tower ML model that encodes you and all posts into embedding vectors, then retrieves the most relevant out-of-network posts via approximate nearest-neighbour search.
JAX · Two-TowerA second out-of-network source. It groups accounts and posts by shared engagement patterns, then finds candidates from communities that match the viewer.
Graph · ClustersA transformer trained and served from the released Phoenix code. It reads your engagement history and predicts 24 actions for every candidate post.
Transformer · Multi-actionThe glue layer written in Rust that wires together all pipeline stages: query hydration, candidate sourcing, enrichment, filtering, scoring, and final selection.
Rust · gRPCAn AI pipeline that classifies every new post for spam, safety violations, and topic category using Grok-powered vision-language models before posts enter the ranking pool.
Python · Grok VLMA reusable Rust framework defining composable traits (Source, Filter, Scorer, Hydrator…) that run in parallel where possible with built-in observability and error handling.
Rust · AsyncEvery feed request runs through these stages in sequence. Click any stage to expand details.
All query hydrators run in parallel. Their results are merged back into the query object before the next stage begins.
Sources run in parallel and their results are pooled together into a single candidate list for the next stage.
Hydrators fetch additional data and write it back to each candidate. They run in parallel since they don't depend on each other.
Filters run one after another. Each partitions candidates into "kept" and "removed." Removed candidates are discarded (or tracked for logging) and never scored.
Removes: duplicates, posts older than the age threshold, your own posts, posts from blocked/muted accounts, previously seen posts, paywalled content you can't access, and muted keywords.
Scorers run in order, each updating candidates with new fields. The full scoring chain is:
The TopKScoreSelector sorts all surviving candidates by their final score (descending) and takes the top K. Non-selected candidates are passed to side effects for logging and caching.
VFFilter asks the separate visibility-filtering service whether to allow, drop, or interstitial a post. AncillaryVFFilter also checks parents, quoted posts, and reposted posts. DedupConversation removes extra branches of the same thread.
Side effects run async in the background: caching scored posts in Redis, publishing served candidate IDs to Kafka, updating impression history, logging for A/B experiments.
The August release exposes both the request path that builds the feed and the labeling path that determines what is eligible to appear.
Written in Rust. Exposes a gRPC ScoredPostsService endpoint. Wires together all pipeline stages and owns the final response format.
Consumes post create/delete Kafka events in real time. Maintains per-user stores for original posts, replies/reposts, and video posts. Auto-trims old posts.
Two JAX models: a two-tower retrieval model (user + candidate towers) and a Grok-based transformer ranker. Ported from Grok-1, adapted for RecSys.
Clusters accounts and posts from engagement patterns, then retrieves out-of-network candidates from communities relevant to the viewer.
Uses a determinantal point process over post embeddings to reduce near-duplicate neighbours without discarding relevance.
Python pipeline that classifies new posts for spam, safety violations, and topics using Grok's VLM. Powers embeddings and policy enforcement at ingest time.
Evaluates viewer relationships and labels from Grox, media models, account models, rule engines, and enforcement systems. Returns allow, drop, or interstitial.
A Rust crate defining trait-based abstractions for building recommendation pipelines. Sources, Hydrators, Filters, Scorers, Selectors, and SideEffects.
New in 2026. Blends ads into the organic feed at appropriate positions. Tracks brand-safety signals so ads don't appear adjacent to sensitive content.
Phoenix predicts 24 actions across engagement, clicks, attention, author follow, and negative feedback. RankingScorer combines them using published default weights, then applies additional adjustments and diversity reranking.
Explore a nine-signal subset using the August 2026 published defaults
Educational approximation only. The real scorer uses 24 predictions, conditional weights, score offsets, experiment configuration, author/network adjustments, and VMRanker. A post can also be removed by visibility filtering regardless of score.
Filters run at two points: before scoring (to avoid wasting ML compute on ineligible posts) and after selection (for final safety checks).
Phoenix is a two-stage ML system: a two-tower retrieval model to narrow millions of posts to thousands, and a Grok-based transformer ranker to score each one with full context.
Encodes you and every post into a shared embedding space. Finds the top-K posts most similar to you via dot-product ANN search.
Input: [user token] + [engagement history sequence] + [candidate posts]. Candidates attend to user + history but not to each other.
Candidates can only attend to the user token and engagement history — never to each other. This means each post's score is independent of what else is in the batch, making scores cacheable and consistent across requests.
Can attend Blocked Self only
Neither the ranking nor retrieval model uses hand-crafted feature IDs. Instead, both users and posts are embedded via multiple independent hash functions:
Multiple hash embeddings are summed (reduced) before entering the transformer, providing collision resistance and graceful handling of unseen IDs.
Every post goes through Grox before it can be ranked. Grox uses Grok's vision-language model to understand text and images together — enabling nuanced classification that pure text models miss.
Uses Grok VLM to classify posts as spam. Has a dedicated path for low-follower accounts (SpamEapiLowFollowerClassifier) that applies stricter standards to new or small accounts.
Two-pass safety system: a fast initial screen (BangerInitialScreen) followed by the full PostSafetyScreenDeluxe that evaluates PTOS (Policy, Terms of Service) categories.
Classifies posts into categories to power topic-based feeds and filtering experiments. Supports post-based filtering at 90%, 75%, and 50% confidence thresholds.
TopicsGenerates dense embedding vectors for posts using both text and image content (v2 and v5 embedders). Used as features for the Phoenix retrieval model's candidate tower.
MLGenerates natural-language summaries of posts, used as additional input features to the Phoenix embedding pipeline for richer content understanding.
NLPA DAG-based task scheduler (grox/engine.py) that orchestrates classifiers, embedders, and publishers. Tasks declare dependencies and the engine resolves execution order.
Five things worth knowing about how the algorithm actually works — and what they imply for users and creators.
A high model score does not guarantee that a post appears. Phoenix and RankingScorer decide order; visibility filtering separately evaluates viewer relationships and safety labels, and can drop a post after ranking.
Block, mute, "not interested," and report all carry negative weights in the scoring formula. Using them actively trains the algorithm away from similar content. The scoring formula explicitly penalises posts you're predicted to dislike.
The author diversity scorer applies an exponential decay to repeated authors sorted by score. Even if one account dominates your highest scores, later posts from that account get progressively smaller multipliers — ensuring your feed isn't flooded by a single creator.
After the diversity step, out-of-network posts get score × OON_WEIGHT_FACTOR (less than 1). However, new users get a higher OON factor to help them discover content before building a follow graph, and topic feeds get their own OON factor.
Candidate isolation in the transformer means a post's score doesn't change based on what else is in the request. This makes scored posts cacheable in Redis — so if you've already paid the ML cost for a post, its score can be reused in future requests.
The new ads blending system includes brand safety hydrators that track safety labels on organic content. Ads are not injected adjacent to content that violates brand safety thresholds, and the injection positions are validated against the organic post layout.
This release replaces the demonstration-level picture with substantially more of the production system: real defaults, full model training code, visibility decisions, and the systems that create safety labels.
Key Home Mixer parameters now expose the production-default values used to blend Phoenix predictions, including strong negative weights for not interested, mute, block, and report.
The repository now includes the code used to train the feed models, a Rust serving layer, synthetic data generation, and a quickstart for a proof-of-concept training run.
The released visibility-filtering/ code shows ordered rules that can allow, drop, or return an interstitial response. Additional recommendation-only rules apply to out-of-network posts.
Botmaker, Scarecrow, Agatha, BDSM, user credibility, media models, adult-content classifiers, and abuse enforcement reveal how posts and accounts receive labels used by filtering.
Out-of-network retrieval is no longer explained as Phoenix alone. SimClusters finds posts through communities formed by shared engagement patterns and runs alongside Thunder and Phoenix retrieval.
After scoring adjustments, VMRanker uses a determinantal point process over embeddings to reduce similarity between neighbouring posts while preserving relevance.
X is piloting an account-level transparency report at x.com/i/under_the_hood, backed by code in the released under-the-hood/ directory.