Open-source project
xai-org/x-algorithm avatar
xai-org/x-algorithm

Inside X's For You Feed: Architecture, Scoring, and Visibility Logic

Algorithm powering the For You feed on X. **Note:** The transformer implementation is ported from the Grok-1 open source release by xAI, adapted for recommendation system use cases.

33,457 stars5,428 forksRustApache-2.0

At a glance

What is it?
xai-org/x-algorithm is the open-sourced Rust codebase that governs which posts appear in the X For You feed. It exposes the ranking model, scoring weights, visibility filter pipeline, and a transparency tool that shows users how their content is labeled.
Who is it for?
Policy researchers and journalists who want to verify ranking or filtering claims should start with xai-value-model/scoring.rs for weights and visibility-filtering/ for filter logic. Engineers studying recommendation architecture will find the separation of Thunder, Phoenix, and SimClusters retrieval into distinct modules instructive.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository received new commits within the last day.
What is it written in?
Mainly Rust, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

In-Network and Out-of-Network: Two Sources for Every Feed

The For You feed is assembled per request from two distinct post pools. Thunder keeps recent posts from accounts a viewer follows in memory and serves them as the in-network component. For out-of-network posts (from accounts the viewer does not follow), two retrieval systems run in parallel: Phoenix and SimClusters. Phoenix reads the viewer's recent engagement history and produces candidates by estimating content affinity. SimClusters identifies communities of similar interest using cluster membership to retrieve relevant posts from outside the follow graph.

Both pools merge into a single candidate set and are scored by the same ranking model. Ads, Who to Follow suggestions, and prompt cards are added afterward by the Blending Pipeline and are not ranked by the machine learning model. The result is that the feed is always a mixture, and the balance between in-network and out-of-network content is not a static dial but a function of what Phoenix and SimClusters return on each individual request.

How Phoenix Scores Posts: What the Weighting Numbers Actually Mean

A persistent misconception about the algorithm concerns how action weights work. The README addresses this directly. The weights in xai-value-model/scoring.rs scale predicted probabilities of each action, not raw engagement counts. Phoenix estimates, for each candidate post, how likely a specific viewer is to Like, Share, Block, Report, or dwell on that post. Those predicted probabilities are multiplied by the corresponding weights to produce a single numeric score.

A weight of 468 for a report compared to 1 for a like does not mean one report cancels 468 likes. It means the model's prediction of how likely you are to report something is multiplied by 468 when computing the score. Since the predicted probability of reporting is very low for most content in most users' histories, the practical effect on any given post score is bounded by the viewer's own behavior pattern. The August 2026 update added comments to home-mixer/params/param.rs and xai-value-model/scoring.rs specifically to prevent this misreading.

The xai-value-model/ directory is where these weights live. Readers can audit the current values directly from the source, which is precisely the point of the open-source release. The weights are a complete picture of the scoring formula; the gap is that the feature distributions of real users are not published alongside them.

Visibility Filtering: From Label Generation to Enforcement

Ranking sets the order of posts. Whether a post can appear at all is decided by a separate system, visibility-filtering/, which reads labels attached to posts and accounts and decides whether to show a post, hide it entirely, or place it behind an interstitial. Those labels are produced by several upstream subsystems added in full to the repository in August 2026.

Botmaker/ and botmaker-rules/ apply rule-based labels to posts. Agatha/, bdsm/ (a behavioral detection scoring model), and user-cred-v2/ score accounts on behavioral dimensions using machine learning. Media content passes through media-model-proxy/ and clip/ for image and video analysis. Abuse-enforcement-service/ applies enforcement actions downstream.

The repository also includes a country-specific filter introduced in August 2026: home-mixer/filters/brazil_2026_election_filter.rs removes posts from accounts reported to Brazil's Electoral Court for the 2026 election, unless the viewer explicitly follows the account. This example shows how legal compliance requirements are implemented at the filter layer and how the open-source structure makes such changes auditable to anyone reading the code.

The Under the Hood Transparency Tool

The under-the-hood/ directory hosts a tool that aggregates label statistics for an account and its posts into a user-facing report. The September 2026 update extended this report to include information about whether any of a user's posts were withheld from a specific country following a legal demand, and which country issued that demand.

This is the output layer. The logic that actually applies visibility limits lives in visibility-filtering/ as described above. For researchers studying content moderation transparency, the Under the Hood tool represents the user-visible surface of decisions made by the labeling pipeline. The reports show aggregate label statistics, not raw model scores, which limits how precisely they reveal why any individual post was limited.

Exploring the Codebase: Structure and Access

The README does not document a standalone build or installation path for the full system. This is not a deployable server that someone outside X can run. It is a reference implementation organized as a Rust monorepo with one directory per functional subsystem.

The home-mixer/ directory contains the PhoenixCandidatePipeline that orchestrates the request path. Query hydration in home-mixer/query_hydrators/ loads the viewer's action sequence, follow list, blocks, mutes, and muted keywords at the start of each request. That action sequence is the primary input to Phoenix. The thunder/ directory handles in-network retrieval. Phoenix/ contains model training code and synthetic data generation added in August 2026, which replaces the earlier demonstration model and enables a proof-of-concept training run. SimClusters/ runs alongside Phoenix for out-of-network retrieval. Grox/ handles transformer model internals ported from the Grok-1 open-source release.

The repository is under Apache-2.0 with no GitHub release tags. It tracks a rolling main branch; the last push was on 2026-09-26. Anyone wanting to read the scoring configuration can browse xai-value-model/ directly without building the project.

What the Repository Does Not Include

The README states explicitly what is absent. The ad-serving system and Who to Follow scoring are handled by the Blending Pipeline and are outside this codebase. The ML inference infrastructure used in production, the actual trained model weights for Phoenix, and the production serving stack are not in the repository.

The real-time feature pipeline that assembles viewer action sequences during live requests is also absent. Phoenix's synthetic data generation allows running a proof-of-concept training run but is not a reproduction of the production training setup. Researchers who want to audit targeting in terms of demographic outcomes cannot do so from this repository alone, because feature distributions across users are not included. The code shows the formula; it does not show the inputs that the formula processes at production scale.

Two additional directories in the repository, vm-ranker/ and phoenix-rankall/, contain ranking components not detailed in the main README. They are visible in the top-level file tree but the README does not document their role explicitly.

Who Benefits from This Code and a Comparison to Other Open Systems

Policy researchers and journalists who need to verify ranking claims, filter behavior, or election-related rules have the primary material they need here. The code is annotated, the scoring weights are in readable configuration files, and the full visibility filter pipeline is now included. This makes x-algorithm more readable than YouTube's recommendation system, which publishes high-level documentation and research papers but not the production ranking code itself. The difference in approach is meaningful: X exposes the actual weight values and filter conditions; YouTube describes the system's objectives without showing the configuration.

Engineers studying recommendation system design will find the architectural separation of Thunder, Phoenix, and SimClusters instructive as a pattern for mixing follow-graph retrieval with ML-based discovery. People expecting to run a local recommendation feed, scrape data, or build a competing service will not find what they need here. The repository is reference code and documentation, not a product anyone can deploy.

Editorial conclusion

Policy researchers and journalists who want to verify ranking or filtering claims should start with xai-value-model/scoring.rs for weights and visibility-filtering/ for filter logic. Engineers studying recommendation architecture will find the separation of Thunder, Phoenix, and SimClusters retrieval into distinct modules instructive. Anyone expecting a runnable server or production model weights should look elsewhere; the README confirms both are absent from this repository.

Frequently asked questions

How does the X algorithm work?

In-network posts come from Thunder, which holds recent posts from accounts the viewer follows in memory. Out-of-network posts come from Phoenix retrieval and SimClusters. Phoenix predicts the viewer's likelihood of each action (Like, Share, Report, dwell) on each post, and those predicted probabilities are multiplied by weights in xai-value-model/scoring.rs to produce a score. Visibility-filtering/ then decides separately whether each scored post can be shown.

Is the X algorithm open source?

Yes. The repository is published at github.com/xai-org/x-algorithm under the Apache-2.0 license. The last push to the main branch was on 2026-09-26. The repository does not include production model weights or the live inference infrastructure.

Is the X algorithm biased?

The README does not make bias claims. The code includes visibility filters applied to content from accounts flagged by labeling systems including botmaker-rules/, agatha/, and user-cred-v2/, as well as country-specific filters such as the Brazil 2026 ElectionFilter. Whether the labeling systems introduce demographic bias is a question the repository alone cannot answer, since the training data and real user feature distributions are not published.

What is the X algorithm?

It is the codebase that determines which posts appear in the For You feed on X. It combines in-network posts from accounts you follow (via Thunder) with out-of-network posts discovered by Phoenix retrieval and SimClusters, ranks them using predicted action probabilities weighted by values in xai-value-model/, and applies visibility filters from visibility-filtering/ before the feed is served.

Official sources

  1. Official README
  2. Project repository
Community notes

Community notes