What X’s algorithm code does not explain about reach

X has opened more of the code behind its recommendation and visibility systems. It has also given some users information about labels that can affect the reach of their posts. The move gives researchers more to examine and users more insight into visibility restrictions. But it does not necessarily explain why a particular post reached, or failed to reach, a particular audience.

What X has opened

X’s August 13, 2026 release added configuration parameters, ranking weights, visibility-filtering code, and the code used to train and run its Phoenix recommendation model. All of it went to X’s public repository at github.com/xai-org/x-algorithm. That is a much larger release than the version of its algorithm that the company open-sourced in 2023.

The same update introduced Under the Hood, a transparency feature in account settings. It lets a pilot group of eligible users download aggregate information about labels on their accounts and posts that can affect visibility.

Ranking and visibility are separate

Phoenix ranks posts that enter the For You feed. Separate visibility-filtering systems determine whether posts are shown, dropped, or placed behind an interstitial. X’s published code also includes the systems that generate the labels used by those filters.

That distinction matters because users often describe any unexplained loss of reach as a shadowban. X’s Under the Hood tool provides information about some visibility labels, but it is not a simple shadowban detector.

The For You feed combines posts from accounts a user follows with posts from accounts they do not follow. X says Phoenix uses a viewer’s recent engagement history to predict how that viewer is likely to interact with each candidate post. It then combines those predicted actions into a score, using weights contained in the published code.

The repository includes weights for actions such as likes, replies, reposts, quotes, direct-message shares, and copied-link shares. It also includes negative signals such as reporting, muting, blocking, and marking content as not interesting.

Why a ranking algorithm is still more than its weights

Those weights have generated viral interpretations of their own. One widely circulated reading suggested that a report is effectively worth 468 likes in the opposite direction. The published default weight for a predicted report is -234, while a predicted like carries a weight of 0.5.

X’s own documentation pushes back on that reading directly. Its repository states that it would be incorrect to conclude that one report cancels out 468 likes based on those numbers.

The weights apply to predicted probabilities, not raw engagement counts. A report does not literally cancel out 468 likes on a post. Phoenix predicts how a particular user is likely to interact with a particular post, then combines those predictions with other signals.

The code therefore exposes a mathematical component of the ranking system, rather than a simple formula for gaining or losing reach.

X’s repository says ranking establishes the order of posts, while visibility filtering determines whether a post can be shown at all. Other systems attach labels to accounts or content, which can then feed into those visibility filters.

A post could therefore receive a lower ranking because Phoenix predicts that a user is less likely to engage with it. Separately, a visibility filter could prevent the post from appearing or place it behind an interstitial.

X’s Under the Hood tool focuses on this second layer. Eligible users are accounts that are at least a year old and have posted 10 or more times in the past month. They can download aggregate information about labels applied to their accounts and posts, where those labels can limit visibility. The current test is limited to that pilot group, with broader availability dependent on feedback.

TechCrunch reported that eligible users can download a JSON file containing aggregate information about labels applied to their accounts over the past month.

That could give users evidence that a particular visibility mechanism affected their account. It still may not tell them why a particular label was triggered or how much it reduced the reach of a specific post.

More code does not mean a complete explanation

For researchers, publishing source code creates something that can be inspected, tested, and compared with observed behaviour.

The latest repository contains substantially more than X’s 2023 release. That August 13 update alone added production ranking configuration, visibility-filtering systems, and the code behind Phoenix itself.

But X has not published the entire live recommendation environment.

The company says production systems are continuously trained and that the public repository contains particular snapshots and components. That means researchers can examine how parts of the system are structured. They cannot necessarily reproduce why one person saw one post in one position at one moment.

The same applies to Under the Hood. Aggregate information about labels can show that certain visibility mechanisms may have been applied. It does not necessarily explain how a label was triggered, how strongly it affected reach, or how that effect interacted with ranking.

X’s published architecture contains candidate retrieval, ranking, filtering, and blending stages. Posts can come from accounts a user follows or from accounts they do not follow. The final feed also contains elements that Phoenix does not rank in the same way, including ads and other recommendations.

That means the published weights explain only one part of the feed.

The 468-likes example shows why. A number in source code can look easy to understand when presented as a ratio. But the underlying system works through predicted probabilities and several stages of ranking and filtering.

For users, the more useful questions may be simpler: What happened to my post, and what can I do about it? Publishing source code does not necessarily answer either question.

What does Indian regulation require?

India’s Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 apply here. They require significant social media intermediaries to publish their rules, regulations, privacy policy, and user agreement under Rule 3(1)(a). They also require monthly compliance reports covering complaints received and action taken under Rule 4(1)(d).

These requirements create transparency around platform policies, complaints, and certain moderation processes. They do not require a significant social media intermediary to publish the source code of its recommendation system or its ranking weights. Nor do they require a user-level explanation of how a particular post was ranked.

X’s decision is therefore notable in India. But it does not mean Indian law requires other platforms to follow the same model.

The broader policy question is whether transparency obligations should go further when automated systems materially affect a user’s ability to reach an audience.

MediaNama has previously reported on transparency concerns around X’s content restrictions in India, including cases involving posts withheld under government blocking orders. That is different from algorithmic downranking. But both raise questions about what users should be told when something materially changes who can see their content.

A government blocking order is a legal restriction. Recommendation and visibility systems are platform mechanisms. The two should not be treated as the same thing.

What should platforms disclose?

Source-code publication may be most useful to researchers. User-level explanations may matter more to people whose posts suddenly lose visibility. Aggregate reports can help the public understand how often platforms apply particular moderation or filtering mechanisms.

The policy question for India is therefore less about whether every platform should publish its entire ranking stack. It is more about what a user should be entitled to know when an automated system materially affects the reach of their content.

China’s draft recommendation-algorithm rules, for example, proposed requirements for platforms to make recommendation mechanisms transparent and understandable. Platforms would also have to explain the basic principles and purposes of their algorithmic recommendation services. MediaNama reported on those proposals in 2021.

That is a different regulatory model from simply asking a company to open-source its code. It focuses more directly on what users should be told about recommendation systems.

Questions sent to X and MeitY

That is the question MediaNama put to X and MeitY, along with:

Does X plan to expand the Under the Hood pilot beyond accounts that are at least a year old and have posted 10 or more times in the past month, and on what timeline?

Beyond aggregate monthly label data, will X tell users which specific post or action triggered a visibility label?

Does MeitY consider the current Rule 3(1)(a) and Rule 4(1)(d) disclosure requirements sufficient for ranking and visibility-filtering systems, or is any additional transparency requirement under consideration?

MediaNama has sent these questions to X and MeitY. Neither had responded at the time of publication. This article will be updated if they do.

X’s disclosure gives researchers and technically sophisticated users substantially more visibility into how its recommendation and filtering systems are constructed. Under the Hood could also give some users a more concrete way to investigate unexplained changes in visibility.

But neither provides an explanation for every individual recommendation or restriction. Knowing that the machinery is open is different from knowing what the machinery did to you.

As platforms rely more heavily on automated systems to determine what users see and who sees their content, that distinction will matter more.

Also read: