X Algorithm Open Source: Weights, Filters, Labels

What the X algorithm repository on GitHub contains

The repository at github.com/xai-org/x-algorithm holds the core code that decides which posts a viewer sees in the For You feed on X. In-network posts come from accounts the viewer follows, and out-of-network posts come from accounts the viewer does not follow, found through machine-learning retrieval.

Visibility filtering is the separate step that decides whether a post may be shown at all. A label is a tag that other systems in the repository attach to a post or an account, such as an adult-content or spam label. The visibility rules read those labels.

The For You feed code and its Apache-2.0 license

The code is licensed under the Apache License 2.0. The feed is assembled for each request, and a model called Phoenix reads the viewer's recent engagement history, predicts how likely the viewer is to take each action on each post, and ranks in-network and out-of-network posts together. The August 13, 2026 release added four things:

• Configuration parameters, including the weights that blend predicted actions into one score for a post.
• Code for the systems that affect whether a post is filtered out of the For You feed.
• The code used to train the models the feed uses, replacing the earlier Phoenix demonstration model, plus code that generates synthetic data for a small proof-of-concept training run.
• SimClusters, which groups accounts and posts by who engages with what and adds out-of-network candidates.

How a For You request moves through the pipeline

Each request passes through two pipelines. The Post Pipeline finds, ranks, and filters posts, and the Blending Pipeline wraps it and adds ads, Who to Follow recommendations, and prompts that the model does not rank. The Post Pipeline runs in this order:

1. Query hydration: load the viewer's recent engagements, follow list, blocks, mutes, and muted keywords.
2. Candidate sources: Thunder, which keeps recent posts from followed accounts in memory, supplies in-network posts. Phoenix retrieval, SimClusters, and a shared list of popular recent posts supply out-of-network posts.
3. Candidate hydration: load post text, media, author details, and account labels.
4. Pre-scoring filters: remove posts the viewer should not see before ranking.
5. Scoring: predict action probabilities, combine them with the weights, and apply adjustments.
6. Selection: sort by final score and keep the top K posts.
7. Post-selection filters: remove the posts that visibility filtering answered drop for.

Ranking and visibility are separate. Ranking sets the order. Visibility filtering decides whether a post can be shown.

Main updates: August 13, August 14, September 18, October 13

The README lists dated entries under Notable Updates. The October 13 entry is a refresh of the Brazil account list inside the August 14 item.

Dated entries in the README, 2026

Date	What the entry says
August 13	Adds the ranking weights, the filtering code, Phoenix training code, and SimClusters. Introduces Under the Hood.
August 14	Explains that weights scale predicted probabilities, not counts. Adds the Brazil 2026 election filter.
September 18	Under the Hood reports now show visibility limits applied to comply with law, and the country.
October 13	The Brazil election filter's account list was updated.

What the For You ranking weights actually scale

A post's score is a weighted sum of predicted action probabilities. The weights are set in the code, so anyone can read them. The easiest way to misread them is to treat them as multipliers on counts.

Weights scale predicted probabilities, not engagement counts

The README says the weights scale a viewer's predicted probability of an action, not how many likes or reports a post has. It names the ratio of 468 only as an example of a wrong reading: seeing that a report carries 468 times the weight of a like and concluding that one report cancels out 468 likes. The August 14 entry also says X added comments to the code, in home-mixer/params/param.rs and xai-value-model/scoring.rs, so that people and LLMs reading it are more likely to understand it correctly.

The model first predicts how likely this viewer is to like, reply to, or report this post, and the weight then multiplies that prediction. If a viewer is unlikely to report a post, the large report weight multiplies a small number. Those predictions come mostly from the viewer's own behavior, so the same post can score differently for two viewers.

The score formula and its three adjustments

The README gives the score as the sum, over all actions, of each weight times the predicted probability of that action. Positive actions push the score up and negative actions push it down. Phoenix predicts a probability for each action in these groups:

Actions Phoenix predicts

Group	Actions
Engagement	favorite, reply, repost, quote, share, share via DM, share via copy link
Clicks	post, profile, link, photo expand, video open, quoted post
Attention	video quality view, dwell, dwell time, click dwell time
Author follow	author
Negative	not interested, mute author, block author, report, not dwelled

The weights live in home-mixer/params/param.rs, and the arithmetic is in xai-value-model/scoring.rs. Three adjustments follow the weighted sum:

• Author diversity: each post after an author's first is multiplied by a decaying factor, down to a floor.
• Out-of-network discount: posts from accounts the viewer does not follow are multiplied by a factor below 1. So are replies and reposts from accounts the viewer does follow.
• New-author boost: posts from authors whose impressions are below a threshold are lifted toward a target position.

Then VMRanker calls a separate service, vm-ranker, that reorders the result. It uses a determinantal point process, a method that gives up a little score so that neighboring posts are less alike.

Visibility filtering decides whether a post is shown

Ranking sets the order of posts. Visibility filtering decides whether a post can be shown at all. The README says this is done separately, from the viewer's own actions such as blocks and mutes and from labels that other systems in the repository attach to posts and accounts.

Four answers per post: allow, notice, interstitial, drop

For each post and viewer, visibility filtering gives one of four answers. These checks run after the order is fixed.

The four visibility answers

Answer	What happens
ALLOW	The post is shown normally.
NOTICE	The post is shown with a notice attached to it.
INTERSTITIAL	The post is shown behind a screen the viewer can tap through, for example for adult or graphic media.
DROP	The post is not shown.

The rules read the labels, whether the viewer blocks, mutes, or follows the author, whether the account is protected, suspended, or deactivated, subscriber-only status, and the viewer's settings and country. The first rule that answers drop ends the evaluation.

A further set of rules applies only when the post is a recommendation from an account the viewer does not follow, and those rules can only drop, as with spam caught at high recall. The same post is allowed to a follower.

A dropped post is removed after ranking. So is any post whose parent in the thread, quoted post, or reposted post was dropped. Interstitial and notice posts stay in the feed, and the repository does not contain the code that draws the interstitial or the notice.

Pre-scoring filters and the Brazil 2026 election filter

Pre-scoring filters run before ranking, in a fixed order, and remove posts the viewer should not see. The README lists them in home-mixer/filters/. These are some of them:

Examples of pre-scoring filters

Filter	Removes
AgeFilter	Posts older than 48 hours
SelfTweetFilter	The viewer's own posts
MutedKeywordFilter	Posts matching the viewer's muted keywords
AuthorSocialgraphFilter	Posts from accounts the viewer blocks or mutes
PreviouslySeenPostsFilter	Posts the viewer has already been shown

The list also holds Brazil2026ElectionFilter. In line with Brazilian electoral law, it removes posts from accounts reported to Brazil's Electoral Court for the 2026 election, unless the viewer explicitly follows the account. The account list was updated on October 13, 2026.

What the open source release leaves out

The README says a limited set of files is not published. It names two examples and then points to a tool that stands in for them.

Grox prompts and some botmaker rules stay unpublished

X gives one reason: code that affects how posts are distributed can be used to try to game the system. The files held back include the Grox prompt files and some rules for botmaker, the rule engine that applies labels.

Grox runs as posts are published and holds classifiers for categories such as spam, adult content, and violent media. Its prompts are the written instructions given to a large language model (LLM).

Everything that is published can be inspected. Some of it is designed to run end to end, such as training and running the Phoenix scoring model. Other code may come without build or deployment files.

Under the Hood shows the labels on your own account

In place of the withheld files, X is piloting a tool called Under the Hood. It shows aggregate statistics about the labels on an account and its posts that can limit visibility. The README lists three benefits:

• A person sees the outcome of these systems, and whether they affect the account.
• A person sees whether a label was applied by hand outside the automated systems.
• A person can match a label to the code to understand how it affects post visibility.

Since September 18, reports also show whether an account or its posts had visibility limited to comply with law. A person can see whether a post was withheld in a country after a legal demand, and which country. X says it will shape the tool based on feedback and expand availability over time.

The README is a single long web page. Feeding the whole page to an AI tool, or keeping a copy to cite later, is easier as Markdown.

A saved copy also shows later what the README said when it was read. To turn a page URL into Markdown, try the tool that does it.