X's For You Feed Algorithm: What the Open Source Release Actually Contains

What This Repository Solves and Who It Is For

This repository publishes the core ranking and filtering logic behind the For You feed on X. It solves a specific problem: how to combine posts from accounts a viewer follows with posts discovered through machine learning, then rank them in a single list. The intended audience is engineers and researchers who want to understand how a large-scale social platform orders content. The README is explicit that this is the code that determines which posts a viewer sees. It is not a library you can install and call. It is a reference implementation of a production system, written in Rust, with components that mirror X's internal architecture. If you are building a recommendation system from scratch, this gives you a concrete starting point for the pipeline structure, not a turnkey product.

The Two-Pipeline Architecture: Posts and Blending

The system is split into two pipelines. The Post Pipeline finds, ranks, and filters posts. The Blending Pipeline wraps that and adds what the model does not rank: ads, Who to Follow recommendations, and prompts. This separation is a key design decision. It means the ranking model only handles organic content, while commercial and auxiliary elements are inserted later. The request path in the README shows a clear flow: a For You request enters the home mixer, which runs the PhoenixCandidatePipeline. Inside that pipeline, query hydration gathers the viewer's recent engagements, following list, blocks, mutes, muted keywords, and already seen posts. Then candidate sources are queried. The two sources are in-network posts from Thunder, which keeps recent posts from followed accounts in memory, and out-of-network posts from Phoenix retrieval and SimClusters. Both are ranked together by the same model. This architecture is worth studying because it isolates the ranking model from the business logic of ads and recommendations.

How Ranking Works: Predicted Actions, Not Raw Counts

The ranking model, Phoenix, reads the viewer's recent engagement history and predicts, for each post, how likely that viewer is to take each action: Like, Share, Reply, Report, and so on. Those predicted probabilities are combined into a single score using weights stored in the code. The README addresses a common misconception directly: the weights scale the predicted probabilities, not the raw engagement counts. A report with a weight 468 times higher than a like does not mean one report cancels out 468 likes. It means the model's own prediction of your probability of reporting is multiplied by that weight. Since that probability is driven by your own behavior, the effect is personalized. This is a subtle but important point for anyone reading the code. The weights are in home-mixer/params/param.rs and the scoring logic is in home-mixer/scorers/ranking_scorer.rs. The README notes that comments were added to these files specifically to help people and LLMs understand this correctly.

Visibility Filtering: A Separate Decision from Ranking

Ranking sets the order of posts, but whether a post can be shown at all is decided by a separate system: visibility-filtering. This component determines whether to show a post, drop it, or show it behind an interstitial. The decision is based on two inputs: the viewer's own actions such as blocks and mutes, and labels attached to posts and accounts by other systems. The labeling systems are included in this release: botmaker and botmaker-rules apply rules, scarecrow applies another set, agatha, bdsm, and user-cred-v2 score accounts on various dimensions, media-model-proxy and clip examine images and video, and abuse-enforcement-service handles enforcement. This separation is a deliberate design choice. Ranking and visibility are independent, which means a post can rank highly but still be hidden. The August 13th release notes say these systems were added to show how filtering works. This is one of the most instructive parts of the repository because it shows that a real feed is not just a ranking model; it is a set of independent policies layered on top.

Getting It Running: What You Can Actually Execute

The README does not give a quickstart command, and the repository is not structured as a single runnable binary. What you can run, according to the release notes, is a proof-of-concept training run of Phoenix. The phoenix directory now contains the code used to train the models the feed uses, plus synthetic data generation code. The synthetic data generation is the key to running anything locally, because the real training data is proprietary and not included. The README says this lets one run a proof-of-concept training run. That is the only concrete execution path described. The rest of the code, such as the home mixer and visibility-filtering, is presented as source for inspection, not as a service you start. The parameter files, like home-mixer/params/param.rs, are real and contain the weights, but they are meant to be read, not loaded into a running system without the surrounding infrastructure.

What Is Not in This Repository

The README has a section titled 'What's not in this repo?' and it is essential reading. The repository does not include the trained model weights for Phoenix, the actual engagement data used for training, or the infrastructure that serves the feed at scale. It also does not include the internal tooling that operates the pipeline. The transformer implementation is ported from the Grok-1 open source release by xAI, adapted for recommendation use cases. That means the core model architecture is not original to this repository. The README notes this explicitly. This is a genuine limitation: you cannot reproduce the exact behavior of the X feed from this code alone. You can understand the logic, but the learned parameters are absent. The synthetic data generation is a workaround for training, but it is not the real data distribution. Anyone expecting to run the actual feed will be disappointed.

A Real Alternative: Compare with Other Open Recommendation Pipelines

If you want a deployable recommendation system, this repository is not the right starting point. A more practical alternative is a project like Meta's TorchRec or the TensorFlow Recommenders library. TorchRec provides modular building blocks for large-scale recommendation models, with training and serving infrastructure that you can actually run. TensorFlow Recommenders offers a higher-level API for building retrieval and ranking models from your own data. The difference in approach is fundamental: x-algorithm is a snapshot of a specific production system, with all the surrounding complexity but none of the data. TorchRec and TensorFlow Recommenders are frameworks designed for reuse. They give you the tools to build your own pipeline, not a copy of someone else's. If your goal is to learn how a real system is structured, x-algorithm is valuable. If your goal is to ship a recommender, a framework with active maintenance and documentation is a more direct path.

Licensing and Maintenance Costs

The repository is licensed under Apache-2.0, which is permissive for use and modification. However, the README notes that the transformer implementation is ported from the Grok-1 open source release by xAI. That means you need to check the Grok-1 license terms as well, because the Apache-2.0 license on this repository may not cover the original ported code. The README does not clarify the interaction between the two licenses. As for maintenance, the repository has no recent releases listed and the last push date is unknown. The README includes notable updates dated August 13th and 14th, 2026, which suggests active development around that time, but there is no release cadence. The code is written in Rust, which has a steep learning curve but strong performance. The maintenance cost for you is high: you would need to understand the entire architecture, adapt the code to your own data, and keep up with any changes in the upstream repository. There is no documentation beyond the README, so you are on your own for deeper questions.

Editorial conclusion

Adopt this repository if you want a reference implementation of a production recommendation pipeline, especially the transformer-based ranking and visibility filtering logic. Do not adopt it if you expect a deployable service: the code lacks the proprietary models, training data, and infrastructure that make the feed work. Before using any part, verify the exact licensing of the Grok-1-derived transformer and confirm that the synthetic data generation produces realistic engagement patterns for your domain. The repository is most valuable as a study aid and a source of tested design patterns, not as a drop-in recommender.

Official sources

1. Official README
2. Project repository