This is the whole registry — every factual claim in the library, each labeled by how strong its source is and linked to the exact line of code it came from. Filter by tier, search the text, and click any citation through to the source at its pinned commit. Nothing here is asserted without one.
73 claims
ads_safe_gap_blending
CODE-CURRENT0bfc279verified 2026-06-12
Ads are blended into already-scored organic posts by a SafeGapAdsBlender: it finds 'safe gaps' between ranked posts, computes spacing, and assigns ads into those gaps — organic ranking happens first, then ads are placed into the spaces.
Ad insertion is constrained by a minimum number of posts before ads appear (MIN_POSTS_FOR_ADS), a computed minimum spacing between ads, and safe-gap selection that searches for the best eligible gap at or after each ideal position rather than forcing fixed intervals.
Every video post passes through an automatic speech recognition task: the audio is pulled from the best variant, transcribed, and attached to the post as asr_transcript. Animated GIFs are explicitly skipped because they have no audio track.
For every candidate post, the pipeline checks whether the author has blocked the viewer and hydrates an author_blocks_viewer flag from the social graph \— block relationships are read in both directions during ranking.
Within a single feed response, candidates from the same author are sorted best-first and each subsequent one is multiplied by (1 \− floor) \× decay^position + floor \— a geometric decay toward a floor, so only an author's top-scored post receives full value per feed load. The decay and floor constants are in the withheld params module.
The banger screen result does double duty: the classifier registers under both BANGER_INITIAL_SCREEN and GROK_RANKER categories — the same quality judgment feeds the ranking pathway.
The banger screen's result schema includes slop_score (an integer — the released code scores posts for slop, by that name) and has_minor_score (a child-safety screening signal), alongside quality_score, tags, and taxonomy categories.
The banger initial screen has a public numeric threshold — one of the only hard numbers in the release: a post is positive when its model-judged quality score is >= 0.4 (banger_initial_positive = score >= 0.4).
The model places notes and raters on a shared viewpoint 'factor' axis; a note's intercept only rises when raters across different factor positions agree, and the not-helpful threshold applies a negative note-factor multiplier (default -0.8) so more polarized notes must clear a harder bar. This is the bridging mechanism that resists single-viewpoint agreement.
A Community Note becomes Currently Rated Helpful (and shows publicly) when its learned note intercept clears the CRH threshold, which defaults to 0.40 in the open scoring code.
Community Notes scores notes with a matrix factorization model: it learns a note intercept (helpfulness), a note factor (viewpoint), a rater intercept and rater factor, and a global intercept, fitting all parameters to the full rating history.
Community Notes computes rater and author helpfulness from rating outcomes: author helpfulness is the mean intercept of notes a user wrote, and rater helpfulness aggregates a rater's ratings against the intercepts those notes ultimately earned.
The Community Notes scoring algorithm is open-sourced in twitter/communitynotes — a distinct repository from the xai-org/x-algorithm ranking code — and operates on public note and rating data; individual rater data is pseudonymized in the public release.
The dedup-conversation filter keeps only the highest-scoring candidate per conversation: when a second post from the same conversation appears, the lower-scoring one is removed.
The current X algorithm has eliminated every hand-engineered feature and most heuristics; the Grok-based transformer learns relevance from the user's engagement history.
Grox's base ContentClassifier takes a list of content categories and an LLM, and exposes classify(post) returning per-category results — every Grox content classifier is an LLM judging a post against named categories.
The May 2026 release includes Grox, a content-understanding service with classifiers for spam detection, post-category classification, and PTOS policy enforcement — including spam.py, safety_ptos.py, banger_initial_screen.py, post_safety_screen_deluxe.py, and reply_ranking.py.
The released spam classifier is named SpamEapiLowFollowerClassifier — low-follower accounts get a dedicated spam-screening pathway, and a positive verdict is logged as 'Spam found for low follower user'.
The spam classifier runs a Grok vision-language model (VisionSampler, ModelName.VLM_PRIMARY) at temperature 0.000001, scoring the SPAM_COMMENT content category — images are in scope, the verdict is deterministic, and replies are the screened surface.
Grox content classifiers render the post's AUTHOR into the judging prompt: UserRenderer.render(post.user) places the user's profile in the model's context alongside the post, in the PTOS, banger, and post-safety-screen classifiers alike.
The For You feed is assembled by a Home Mixer candidate pipeline: the server calls pipeline.execute(query) and serializes the selected_candidates into the timeline. The pipeline composes sources, hydrators, filters, scorers, and selectors.
The inferred-gender hydrator is gated: its enable() returns true only when the EnableInferredGenderHydration param is set or the request is shadow traffic. The released code does not show this hydrator running unconditionally on production timeline requests, nor a scorer consuming the attached label.
The May 15, 2026 release changed 187 files (+18,263/−926 lines), adding: a runnable end-to-end inference pipeline (phoenix/run_pipeline.py), pre-trained mini Phoenix model artifacts, the Grox content-understanding service, an ads blending module (home-mixer/ads/), and new query hydrators, candidate hydrators, and candidate sources.
The multimodal post embedder appends a video's transcript directly to the post text, then assembles that text together with the post's images into a single document embedded by one model — text, images, and spoken-word transcript share one representation.
The MutedKeywordFilter tokenizes each post and removes it if its text matches any keyword the viewer has muted — a text match against the viewer's muted_keywords, independent of the post's quality.
The May 15, 2026 release contains a complete mutual-follow similarity subsystem in home-mixer: a query hydrator fetches a MinHash signature (minimum 256 hashes) for the viewer, a candidate hydrator fetches each post author's signature and computes their Jaccard similarity into a per-candidate mutual_follow_jaccard score (0 to 1), and a side effect logs score-distribution metrics — all wired into the Phoenix candidate pipeline and all gated by EnableMutualFollowJaccardHydration, a parameter defined in the withheld params module.
At the May 15, 2026 release, no scorer, filter, or feature-mapping in the published home-mixer reads mutual_follow_jaccard by name: its only named consumers are the hydrators that set it and a metrics side effect that measures its distribution.
The model explicitly predicts negative actions — not interested, block author, mute author, report — and these carry negative weights in the final score, pushing down content a user would likely dislike.
The released ranking pipeline contains no link-penalty, URL-deboost, or external-link downranking mechanism. The only link-related signal is click_score in the weighted scorer, which is a positive term. Claim is scoped to the open release at the pinned commit.
Out-of-network candidates have their score multiplied by an OON_WEIGHT_FACTOR, with the code comment stating the intent: 'Prioritize in-network candidates over out-of-network candidates.' The factor's value is in the withheld params module.
In the ranking transformer, candidates cannot attend to each other during inference — a deliberate design choice ensuring a candidate's score does not depend on which other candidates are in the batch. Candidates still attend to the user and the user's history.
The ranking model predicts multiple engagement types simultaneously per candidate (output shape [B, num_candidates, num_actions]); the mini config declares 19 action types, and the README decodes part of the proto ActionName enum: 1=favorite, 4=reply, 5=quote, 6=repost, 11=dwell, 13=video quality view.
Phoenix applies a new-user history threshold in both retrieval and ranking: when the configured threshold is positive, the system checks the length of the user's interaction sequence (action_count) and handles low-history (new) users via a separate path. This is cold-start handling, not a penalty, and resolves as a user accrues history.
The Phoenix source is the out-of-network retrieval path: its enable() requires that the request is not in_network_only, so it contributes candidates from beyond the viewer's follow graph.
Phoenix, a Grok-based transformer, predicts per-post probabilities for many engagement types; the final ranking score is a weighted combination of those predicted engagements.
Phoenix operates in two stages: retrieval narrows millions of candidates to hundreds via approximate-nearest-neighbor similarity search (a two-tower model), then a more expressive transformer ranks the retrieved set.
The post safety screen is an annotator, not a judge: it runs a critical-tier vision model (VLM_PRIMARY_CRITICAL) and returns only boolean metadata, with the verdict hardcoded to positive=False and score=0.0 — it attaches safety facts for downstream systems rather than flagging posts itself.
Before scoring, Home Mixer removes: duplicates, posts that failed metadata hydration, posts older than a threshold, your own posts, repost duplicates, paywalled content you can't access, posts you've already seen or been served, posts containing your muted keywords, and posts from authors you've blocked or muted.
The PreviouslySeenPostsFilter removes candidates the viewer has already seen, using both the seen_ids sent by the client and bloom filters; matching posts are partitioned into 'removed'.
In 'deluxe' mode, the two most consequential policy categories — AdultContent and ViolentMedia (DELUXE_4_2_CATEGORIES) — are routed to a dedicated reasoning model, with fallback to the standard vision model on failure.
The released safety_ptos.py carries visible redaction seams: the _THINKING_RESTRICTION_LINES set contains only empty strings (L40–L43), and a boolean condition is missing its first operand (L241–L244: "if ( / and self.deluxe / and …") — clauses were removed from the file before publication.
The PTOS safety enforcement taxonomy is named in the released code: seven policy categories — ViolentMedia, AdultContent, Spam, IllegalAndRegulatedBehaviors, HateOrAbuse, ViolentSpeech, SuicideOrSelfHarm — defined as the SUPPORTED_POLICY_CATEGORIES set.
PTOS enforcement is a two-stage pipeline on two model tiers: SafetyPtosCategoryClassifier (VLM_SAFETY) detects whether a post violates anything, then SafetyPtosPolicyClassifier (VLM_PRIMARY_CRITICAL) re-judges it against the specific detected policy — both vision models at temperature 0.000001.
The home mixer includes a family of query hydrators that load viewer context before ranking: followed/blocked/muted/subscribed user IDs, muted keywords, impressed and served history, mutual-follow overlap, IP/country, and (gated) demographics and inferred gender.
Thunder is the in-network source: it fetches posts via get_in_network_posts, keyed on the viewer's followed_user_ids — i.e. content from the accounts the viewer follows.
For You candidates come from two sources: Thunder (in-network — posts from accounts you follow) and Phoenix Retrieval (out-of-network — ML-based similarity search across a global corpus). Both are ranked together by Phoenix.
Candidates are gathered by multiple sources, including Thunder (in-network posts from accounts the viewer follows) and Phoenix (out-of-network retrieval), plus a Who-To-Follow source for account recommendations.
A query hydrator exists that fetches a viewer's demographics and attaches them to the ranking query. It is gated: its enable() returns true only when the EnableContextFeatures param is set or the request is shadow traffic — it does not run unconditionally on production requests in the released code.
A query hydrator can attach a discrete InferredGenderLabel plus a prediction_score to the ranking query. The label is read from a store; for same-day-created accounts with no stored value, a gRPC gender-prediction service is called to predict one live.
The per-viewer feature struct consumed by ranking contains six fields: muted_keywords, blocked_user_ids, muted_user_ids, followed_user_ids, subscribed_user_ids, and follower_count \— the viewer's muted keywords and block/mute lists are first-class ranking inputs.
The video quality view weight is applied only when a post's video exceeds a minimum duration threshold; shorter videos receive zero weight for that signal.
On July 14, 2026, Bier stated in a reply that user groups which misused Following as account promotion (naming crypto) with no intent to engage with the accounts they followed now have timelines "destroyed beyond all recognition" as a result of the mutuals change.
On July 13, 2026, X Head of Product Nikita Bier announced that posts now receive a visibility boost to mutuals (accounts you follow that follow you back), stating the mutual-follow data "was missing from the algo" and that its absence made friends appear less in replies.
X has publicly stated that posts with a Currently Rated Helpful note receive reduced reach and that authors lose revenue-sharing eligibility on those posts. This is stated platform policy, not a mechanism present in the open Community Notes scoring code.
Phoenix's transformer is ported from the Grok-1 open-source release, adapted for recommendation with custom input embeddings and attention masking; the release states it is representative of the model used internally except for specific scaling optimizations.
The released Phoenix is a mini model (128-dim, 4-layer) and a frozen checkpoint; the README states production Phoenix uses a larger model with more layers and wider embeddings and is trained continuously on real-time data.
The specific 2023 engagement-weight multipliers (e.g. replies weighted far above likes, large negative weights for reports/'show less often') were published in X's 2023 engineering blog post about the release, rather than as a single readable constant table in the open code. The model producing the predictions is open; the exact combining weights are best cited as officially stated.
In January 2026, X Engineering open-sourced its production For You feed algorithm at xai-org/x-algorithm, built on the same transformer architecture as xAI's Grok model.
The 2023 open-source release included RealGraph, a user-to-user graph measuring relationship strength between accounts from interaction counts (favorites, replies, retweets, clicks) and follow, mute, and block state, with its aggregated interaction-graph output exported as ranking features for timelines.
The initial January 20, 2026 release (commit aaa167b) contained Home Mixer, Thunder, Phoenix, and the candidate-pipeline framework; the Grox content-understanding service and the home-mixer/ads module were not yet included, and the weighted scorer's numeric parameters were absent from the very first commit.
The 2023 'For You' Heavy Ranker (open-sourced in twitter/the-algorithm-ml, projects/home/recap) was a neural model that predicted probabilities of multiple engagement outcomes (favorite, reply, reply-engaged-by-author, retweet, video view, dwell, profile click, and negative actions); the final tweet score combined these predictions with weights.
The 2023 twitter/the-algorithm release describes a system that has been substantially replaced by the 2026 Grok-based release. Claims about 2023 specifics (weights, TweepCred, visibilitylib) are historical and are not evidence about how X ranks content in 2026.
In March 2023, Twitter first open-sourced its recommendation algorithm at twitter/the-algorithm: a large Scala/Python stack covering candidate sourcing, a heavy-ranker model, heuristics, and a visibility-filtering rule engine. This is the historical predecessor to the 2026 xai-org/x-algorithm release.
The 2023 VisibilityFiltering library (visibilitylib) was a centralized rule engine that altered content display at read time — supporting hard-filtering (Drop), soft-filtering (labels, interstitials), and coarse-grained downranking — via SafetyLevels, Features, Conditions, Policies, and a RuleEngine. Its README stated part of the code had been removed and comments sanitized before release.
The 2023 heavy ranker also combined predicted engagement probabilities into a weighted sum — the same structural idea the 2026 system retains, with different models producing the probabilities and different (unpublished) weights.
In the 2023 open-source release, the heavy ranker's published weights (dated April 5, 2023 in the source) were: favorite 0.5, retweet 1.0, reply 13.5, good profile click 12.0, video playback (50%) 0.005, reply engaged by author 75.0, good click 11.0, good click v2 10.0, negative feedback v2 −74.0, report −369.0.
The numeric values of the current weights are not included in the open-source release: weighted_scorer.rs references a params module (e.g. p::FAVORITE_WEIGHT, p::REPLY_WEIGHT) whose values are not present anywhere in the published repository.
The actual spam criteria are withheld: spam.py imports its system prompt (SpamSystemLowFollower) from grox.prompts.template, and the entire grox/prompts/ module is absent from the public release — the classifier machinery is open, the rules it enforces are not.