How X Ranks Content – A Code-Based Analysis for Organic Growth

6 min Read
28 Views
Code editor showing X's open-source algorithm files with highlighted scoring functions and engagement prediction logic.

There is no shortage of advice on how to grow on X. Most of it is based on observation and pattern-matching, what seems to work, what influencers report, what correlates with reach.

This article takes a different angle.

I went to the source: X’s public repositories (the-algorithm and the-algorithm-ml). I traced the code to understand how content enters the system, how it is scored, how visibility is enforced, and how the final timeline is assembled.

This is not the complete picture. Posting times, frequency effects, Premium amplification, these may exist in proprietary systems not included in the public release. What follows is limited to what I found in the code. But within that scope, the system is surprisingly legible.

For growth marketers, understanding even part of the ranking architecture shifts strategy from guesswork to structural alignment.

Cheat Sheet: What to Do (and Avoid)

Based on what’s explicitly modeled in the scoring and visibility code:

Do

Optimize for depth, not just reaction. The scoring model weights continued engagement: replies, profile visits, bookmarks, dwell time, and video watch-through (50%+ completion). A like is a signal. A reply that sparks a thread is a stronger one.

Publish original content. Duplication filters run both before and after scoring. Reposted or recycled material faces structural headwinds at multiple checkpoints.

Reduce friction signals. Mutes, dismissals, “not interested” clicks, and reports are negative features fed directly into the score. Content that consistently triggers these responses gets downranked mathematically, not as a penalty, but as part of the core calculation.

Earn conversation. Replies and quote tweets from others generate new candidate tweets that re-enter the system with your content as context. Engagement compounds.

Understand which feed you’re optimizing for. For You is algorithmic – scored, filtered, mixed. Following is mostly chronological. Lists are chronological from list members. Different feeds, different mechanics.

Avoid

Chasing volume without resonance. Posting more does not expand your scoring opportunity. Each tweet is evaluated independently. High-frequency, low-engagement patterns produce a weak signal profile.

Triggering visibility rules. Separate from scoring, a policy layer can drop or suppress content entirely, for spam patterns, duplicate content, low-quality labels, or policy violations. High scores don’t override these rules.

Surface-level engagement farming. Reactions without follow-through (a like with no dwell, no profile visit, no reply) are the weakest positive signals in the model.

Expecting out-of-network reach without earning it. Out-of-network tweets (recommendations to non-followers) are debunched in the mixer – the system limits consecutive recommendations. Your content competes for limited slots alongside every other account trying to reach new audiences.

How Content Gets Served

Before diving into scoring details, here’s the structural flow from the code:

The Pipeline

Candidate sources → Scoring model → Filters → Mixing → Final timeline

1. Candidate sourcing. Tweets are pulled from multiple sources: your network (Earlybird), recommendations (UTEG, TweetMixer), content exploration, lists, and communities.

2. Scoring. Each candidate receives engagement probability scores – predictions for reply, retweet, like, bookmark, dwell, negative feedback, and more. These are weighted and combined.

3. Filtering. Before and after scoring, filters remove content: deduplication, spam, NSFW, visibility policy violations, previously seen tweets, feedback fatigue.

4. Mixing. Scored tweets are ordered first. Then non-tweet modules are inserted: ads, who-to-follow, prompts. Out-of-network tweets are debunched to avoid long runs of recommendations.

Feed Types

For You = Algorithmic. Pulls candidates from multiple sources, scores them, filters them, mixes in modules and ads. This is where the ranking system matters most.

Following = Mostly chronological from people you follow, plus some modules and ads.

Lists = Chronological from list members, plus modules and ads.

The ranking analysis in this article applies primarily to For You. Following and Lists operate on different logic.

How This Analysis Was Done

I downloaded the public repositories locally and explored them end to end using Cursor as the development environment, with Codex assisting in navigation and system-level comprehension.

Codex was not used to create something as I would usually do, but as a little analyst to:

  • Identify pipeline entry points
  • Trace how components depend on one another
  • Follow scoring signals through to their weights
  • Distinguish ranking logic from policy enforcement

All conclusions below are grounded in explicit pipeline definitions, scorers, and rule sets present in the code.

Deep Dive: The For You Timeline Architecture

The Mixer Layer

The assembly point for the For You timeline lives in:

the-algorithm/home-mixer/server/src/main/scala/
com/twitter/home_mixer/product/for_you/ForYouMixerPipelineConfig.scala

This file defines what flows into the timeline, not how tweets are ranked. It combines scored tweet pipelines, module pipelines (Who to Follow), community and exploration sources, and ad pipelines.

Ranking happens upstream. The mixer’s job is composition.

Where Ads Sit

Ads are introduced in the scored tweets mixer:

the-algorithm/home-mixer/server/src/main/scala/
com/twitter/home_mixer/product/for_you/ForYouScoredTweetsMixerPipelineConfig.scala

The sequence from the code:

  1. Sorted organic tweets are inserted first
  2. Out-of-network tweets are debunched
  3. Modules are inserted at fixed positions
  4. Ads are injected via InsertAdResults(...)

Ads do not share the organic scoring function. They are placed during mixing, not ranking. Auction and bidding logic are not present in the open repo. The public code does not show paid activity influencing organic scores.

Where Organic Ranking Happens

Organic ranking is defined in the scored tweets recommendation pipeline:

the-algorithm/home-mixer/server/src/main/scala/
com/twitter/home_mixer/product/scored_tweets/
ScoredTweetsRecommendationPipelineConfig.scala

This file defines the end-to-end lifecycle:

Candidate sourcing – Tweets pulled from Earlybird (in-network), UTEG, TweetMixer, content exploration, lists, communities, and backfill.

Global filters (pre-scoring) – Deduplication, seen/served filtering, feedback fatigue, location and author checks. Tweets can be removed before scoring ever happens.

Scoring pipelines – Model scoring, weighted reranking, heuristic rescoring, and low-signal rescoring chained together.

Post-scoring filters – Additional filtering for spam, NSFW, violence, language, and duplicate conversations.

The structural insight: eligibility precedes ranking. A tweet must survive filtering before it ever receives a score.

Deep Dive: What “Engagement” Means in Code

Predicted engagement signals are explicitly defined as features in:

the-algorithm/home-mixer/server/src/main/scala/
com/twitter/home_mixer/product/scored_tweets/scorer/
PredictedScoreFeature.scala

Positive engagement features:

reply, retweet, fav, bookmark, share, tweet_detail_dwell, profile_dwelled, video_playback_50

Negative engagement features (defined alongside them):

negative_feedback_v2, strong_negative_feedback, weak_negative_feedback, reported

These features are combined in the weighted reranker:

the-algorithm/home-mixer/server/src/main/scala/
com/twitter/home_mixer/functional_component/scorer/
WeighedModelRerankingScorer.scala

Each feature maps to a weight parameter defined in:

the-algorithm/home-mixer/server/src/main/scala/
com/twitter/home_mixer/param/HomeGlobalParams.scala

The system optimizes for a weighted vector of predicted outcomes. Negative signals are mathematically integrated into the score, not applied as a separate punishment. Raw engagement volume is not sufficient on its own.

Deep Dive: Visibility Rules Override Scores

Visibility enforcement is implemented separately from ranking, in:

the-algorithm/visibilitylib/src/main/scala/
com/twitter/visibility/rules/

The routing logic lives in RuleBase.scala. Policy groupings are defined in VisibilityPolicy.scala.

Representative rule classes:

  • LowQualityTweetLabelDropRule
  • SpamHighRecallTweetLabelDropRule
  • DuplicateContentTweetLabelDropRule
  • DoNotAmplifyDropRule
  • NSFW and violence label rules

These rules can drop content entirely, downrank it regardless of score, or apply differently across surfaces (timeline vs search).

This establishes a hard boundary: scoring does not guarantee distribution. A high-scoring tweet can still be suppressed by policy.

Closing Perspective

Reading X from the outside makes it feel unpredictable. Reading it through code reveals a layered system with explicit decision points and enforcement boundaries.

This framing is valuable not because it produces shortcuts, but because it removes noise. Once you understand where engagement is modeled, where eligibility is lost, and where visibility is overridden, organic strategy becomes less about pattern-matching and more about structural alignment.

Not with trends. With structure.