How the X (Twitter) For You Algorithm Works in 2026 X's For You feed is a pipeline, not one ranking formula. For each request, it gathers viewer context, recalls followed and out-of-network posts in parallel, hydrates and filters them, predicts likely actions, computes value, reranks for diversity, applies viewer-specific visibility rules, and blends the final feed. This map follows the August 13, 2026 open-source release at commit a389166.
The repository shows public code and checked-in defaults, not every live experiment or private anti-abuse rule. Creator implications are informed interpretation, not a guaranteed reach formula.
Solid · execution path Data, sequence, branch, merge, control, or feedback
Dashed · conditional/secondary path Async, dependency, retry, or fallback; shown when a related node is active
Pipeline Layers
For You request
Feed request
A viewer request starts one fresh For You assembly.
Sequence → Query hydration
Detached side effects
Async feedback
Detached tasks record history, events, caches, and metrics.
⟲ Return to Query hydration · Event: served and seen history updates the next request
Content and account models
Content signals
Models score content, media, and account behavior.
Data → Rules and enforcement · model scores and events
Query hydration
Viewer context
Actions, social state, settings, and history are gathered.
Sequence → Candidate source fan-out
Dependency → Phoenix shared ranker · viewer history
Dependency → Visibility Filtering · viewer policy
Rules and enforcement
Labeling rules
Event rules and enforcement convert signals into labels.
Data → Safety label storage · apply labels
Candidate source fan-out
Parallel recall
Enabled retrieval sources launch together for lower latency.
Branch → Thunder · in-network
Branch → Phoenix retrieval source · out-of-network
Branch → SimClusters ANN · out-of-network
Safety label storage
Safety labels
Stored labels are read later by the visibility service.
Dependency → Visibility Filtering · request-time lookup
Active recall families Three active recall families Thunder
Followed posts
Recent posts from followed accounts arrive newest first.
Phoenix retrieval source
Parallel recall
A parallel source recalls posts from a vector index.
SimClusters ANN
Cluster recall
Cluster ANN feeds recalled posts to the Phoenix ranker.
Merge → Candidate merge
Dependency → Phoenix shared ranker · after merge, hydration, and filters
Candidate merge
Candidate merge
All source results concatenate before shared enrichment.
Sequence → Candidate hydration
Candidate hydration
Post hydration
Post, author, media, counts, access, and SID fields load.
Sequence → Pre-scoring filters
Pre-scoring filters
Cheap filters
Sequential rules remove cheap or clearly ineligible posts.
Sequence → Phoenix shared ranker
Phoenix shared ranker
Action scores
Scores merged candidates from every recall source.
Sequence → RankingScorer · action predictions
RankingScorer
26 weights
Combines 26 Phoenix outputs with tunable coefficients.
Sequence → VM Ranker · weighted scalar
VM Ranker
Diverse rerank
A DPP reranker trades a little score for local diversity.
Sequence → Top-K selection
Top-K selection
Top K select
The highest scores advance before final visibility checks.
Sequence → Visibility Filtering
Visibility Filtering
Visibility gate
Rules decide allow, interstitial, or drop per viewer.
Sequence → For You blending pipeline
For You blending pipeline
Feed blending
Ranked posts mix with ads, modules, prompts, and frames.
Sequence → Ranked For You timeline
Ranked For You timeline
For You output
Feed items and cursors become the returned For You timeline.
Async → Detached side effects · after response
For You request
Feed request
A viewer request starts one fresh For You assembly.
Thunder
Followed posts
Recent posts from followed accounts arrive newest first.
Safety label storage
Safety labels
Stored labels are read later by the visibility service.
Phoenix retrieval source
Parallel recall
A parallel source recalls posts from a vector index.
SimClusters ANN
Cluster recall
Cluster ANN feeds recalled posts to the Phoenix ranker.
Phoenix shared ranker
Action scores
Scores merged candidates from every recall source.
RankingScorer
26 weights
Combines 26 Phoenix outputs with tunable coefficients.
VM Ranker
Diverse rerank
A DPP reranker trades a little score for local diversity.
Content and account models
Content signals
Models score content, media, and account behavior.
Query hydration
Viewer context
Actions, social state, settings, and history are gathered.
Candidate hydration
Post hydration
Post, author, media, counts, access, and SID fields load.
Pre-scoring filters
Cheap filters
Sequential rules remove cheap or clearly ineligible posts.
Top-K selection
Top K select
The highest scores advance before final visibility checks.
Visibility Filtering
Visibility gate
Rules decide allow, interstitial, or drop per viewer.
For You blending pipeline
Feed blending
Ranked posts mix with ads, modules, prompts, and frames.
Ranked For You timeline
For You output
Feed items and cursors become the returned For You timeline.
Detached side effects
Async feedback
Detached tasks record history, events, caches, and metrics.
Candidate source fan-out
Parallel recall
Enabled retrieval sources launch together for lower latency.
Candidate merge
Candidate merge
All source results concatenate before shared enrichment.
Rules and enforcement
Labeling rules
Event rules and enforcement convert signals into labels.
← Back to system map ← Back
How to read the latest release
Follow the request lane
The solid path is the synchronous work that produces one feed response.
Trace the labeling lane
Models and rules run continuously, store labels, and meet the request only at Visibility Filtering.
Close the feedback loop
Served, seen, and engagement events become context for later requests.
The algorithm is a pipeline, not one model.
Retrieval chooses a working set; ranking orders it; visibility decides admissibility; blending composes the product. This release contains production Phoenix model, training, and Rust serving code, with synthetic public data paths. Live experiment buckets can differ from checked-in primary defaults, and some anti-gaming prompts and rules are omitted. Viewer and request context
Normalize the request
Validate the viewer, cursor, product surface, device, locale, and topic context.
Load action sequences
Build separate recent histories for retrieval and scoring, up to 1,024 events each.
Load social state
Fetch followed, blocked, muted, subscribed, and mutual-follow relationships.
Load memory
Attach seen, served, cached, and impression Bloom-filter state.
Resolve feature switches
Apply the request's experiment parameters before any gated stage runs.
Context Examples Primary consumers Context Behavior Examples recent actions, dwell, explicit and implicit signals Primary consumers Phoenix retrieval and ranking Context Eligibility Examples follows, blocks, mutes, subscriptions Primary consumers sources, filters, visibility Context Freshness Examples seen, served, cached, past requests Primary consumers deduplication and side effects Context Surface Examples device, country, topics, preview flags Primary consumers model features and policy choice
Parallel candidate recall
Evaluate source gates
Feature switches and request shape decide which source implementations are enabled.
Launch together
Enabled sources run concurrently; one slow source does not serialize the others.
Tag provenance
Every returned post keeps its source type and network status for later rules.
Concatenate results
The shared pipeline merges results before hydration and exact deduplication.
Recall family Scope Mechanism Default role Recall family Thunder Scope followed accounts Mechanism recent in-memory post store Default role fresh in-network inventory Recall family Phoenix retrieval Scope whole eligible corpus Mechanism user embedding versus checkpoint index Default role personalized out-of-network inventory Recall family SimClusters Scope engagement graph Mechanism cluster ANN from recent post signals Default role interest expansion beyond follows
The active source vector is broader than the three headline families.
The code also wires Tweet Mixer, Phoenix topic retrieval, Phoenix MoE retrieval, and cached-post reuse. Topic, MoE, cached, and experimental paths are gated; cached posts can replace live source calls. All candidates still enter the same hydration, filter, and scoring stages. Phoenix retrieval vs SimClusters ANN
Build different queries
Phoenix consumes a viewer retrieval sequence and context; SimClusters extracts several recently engaged post IDs.
Search different spaces
Phoenix searches learned user-to-post embeddings; SimClusters searches tweet neighbors in engagement-cluster space.
Keep complementary recall
Phoenix returns broad profile-based recall; SimClusters filters and interleaves separate per-seed result lists.
Join the same ranker
Both source-tagged candidate sets merge, hydrate, filter, and enter the shared Phoenix ranker.
Source Personalization input Similarity space Search pattern No input Candidate balancing Source Phoenix retrieval Personalization input retrieval sequence plus viewer context Similarity space learned user-to-post embeddings Search pattern one viewer representation searches the eligible index No input missing sequence is an error Candidate balancing model top-K Source SimClusters ANN Personalization input several explicit and implicit engaged posts Similarity space engagement-community tweet embeddings Search pattern one ANN lookup per seed post No input no post signals returns nothing Candidate balancing >0.5, per-seed budget, round-robin, 800 cap
They are complementary candidate generators, not successive ranking stages.
Phoenix asks which posts fit the viewer's overall learned profile. SimClusters asks which posts are near each recently engaged post in the engagement graph. Candidates from both then pass through the same hydration, filters, Phoenix ranking, reranking, and visibility stages. Thunder in-network retrieval
Receive followed IDs
Home Mixer sends the follow list, seen exclusions, limit, and retrieval algorithm.
Read recent stores
Thunder traverses in-memory post stores populated by publication events.
Apply input limits
The service caps oversized inputs and enforces QPS rate limits.
Return newest first
Eligible followed-account posts are sorted by recency and tagged in-network.
Thunder is a freshness-oriented followed-post source, not the final ranker.
Its recency order only shapes recall; Phoenix later scores Thunder and out-of-network candidates together. Phoenix retrieval
Hydrate history identity
Recent history gains post semantic IDs and contextual profile features.
Encode the viewer
A transformer user tower converts history and profile context into a normalized vector.
Load the corpus index
Candidate-tower post embeddings are baked into each retrieval checkpoint.
Compute similarity
Dot products compare the user vector with eligible indexed posts across shards.
Return top candidates
Post and author IDs come back to Home Mixer for common hydration and ranking.
Retriever Query representation Corpus operation Place in this release Retriever Two-tower Query representation normalized viewer embedding Corpus operation dot-product top-K over checkpoint index Place in this release documented default and public quickstart Retriever Generative SID Query representation autoregressive semantic-ID prefix Corpus operation beam search then SID-to-post resolution Place in this release additional implementation in the latest tree
Production two-tower retrieval has no learned per-user ID embedding.
The viewer is represented by interaction history plus coarse profile context. Posts use six-level semantic IDs plus hashed author identity, helping unseen posts share topical structure. SimClusters active recall flow
Gate the source
Run only when SimClusters is enabled, live retrieval is allowed, and the viewer has post signals.
Choose seed posts
Merge explicit and implicit engagement signals, sort newest first, and deduplicate post IDs.
Search cluster space
Launch one cosine-similarity ANN request per seed against engagement-derived tweet embeddings.
Filter and balance lists
Keep scores above 0.5, enforce the shared budget, round-robin interleave, and deduplicate posts.
Cap and hydrate
Keep at most 800 posts, tag their source, load core post data, and remove missing authors.
Hand off to Phoenix
Merge with other recall sources; common filters and Phoenix decide the final value and order.
200 maximum ANN neighbors requested per seed
50 maximum source clusters scanned
> 0.5 post-ANN score retained by Home Mixer
800 final SimClusters candidate cap
Score Input What it means What it decides Score SimClusters ANN Input one recently engaged seed post What it means shared engagement-cluster profile What it decides whether a post enters the candidate pool Score Phoenix final score Input viewer history plus hydrated candidate What it means predicted weighted viewer actions What it decides the post's eventual rank after adjustments
SimClusters widens recall; it does not choose the final feed order.
The viewer enters indirectly through recent engaged posts, which act as multiple retrieval seeds. Round-robin interleaving stops one seed from monopolizing the candidate set. Every retained result still passes common hydration, filters, Phoenix scoring, reranking, and visibility. What cluster similarity means
Learn engagement communities
Offline graph jobs group accounts by overlapping follow and engagement behavior.
Embed the seed post
Represent the seed as sparse weights over communities whose members engage with it.
Read cluster postings
Use the seed's strongest clusters to fetch recent candidate posts associated with those communities.
Approximate cosine similarity
Accumulate overlap in shared cluster dimensions and normalize for vector magnitude.
Return audience neighbors
Emit recent posts with similar engagement-community profiles, not a final preference score.
LOCKED
similarity(seed, candidate) = cosine(cluster_weights_seed, cluster_weights_candidate)
= Σc seed[c] × candidate[c] / (‖seed‖ × ‖candidate‖)
Representation Built from Best interpretation Representation Cluster dimension Built from shared follow and engagement behavior Best interpretation a learned audience community, not a manual topic label Representation Tweet embedding Built from weighted audience communities around a post Best interpretation who tends to engage with this post Representation Cosine neighbor Built from overlap between two tweet embeddings Best interpretation posts attracting similar communities Representation Viewer relevance Built from full viewer history and candidate features Best interpretation a later Phoenix prediction, not the ANN score
Cluster similarity is audience similarity more than literal text similarity.
Two posts can be neighbors because overlapping communities engage with both, even when their wording differs. The current Home Mixer query uses cosine similarity over the 20M-user, 145K-cluster 2020 model version. The source post uses a longest-L2 log-favorite embedding; candidates use log-favorite tweet embeddings. Shared candidate hydration
Mark network position
Resolve in-network and bidirectional-follow state for source-independent scoring.
Load core content
Fetch the post, author, quoted post, language, and media metadata.
Load access state
Attach subscriptions, blocks, mutes, and filtered-topic context.
Load activity
Attach engagement counts used by eligibility and ranking behavior.
Load semantic IDs
Give Phoenix content-aware codes for history and candidate feature preparation.
Hydration normalizes unlike sources into one candidate shape.
That shared shape lets all recall families pass through the same filters and ranking model. Independent hydrators run concurrently and merge only the fields they own. Pre-scoring eligibility filters
Remove broken duplicates
Drop duplicate IDs, missing core data, and duplicate reposts.
Apply basic eligibility
Remove posts older than 48 hours and the viewer's own posts.
Constrain OON shapes
Reject disallowed out-of-network replies, reposts, and NSFW SimClusters results.
Apply access and memory
Remove inaccessible subscriptions and posts already seen or served.
Apply viewer choices
Honor muted keywords, blocked or muted authors, video, and topic filters.
Apply inventory policy
Enforce new-user engagement floors and deterministic holdout inventory.
Filter phase When Why Filter phase Pre-scoring When before Phoenix inference Why avoid spending model work on obvious rejects Filter phase Post-selection When after top-K ordering Why apply expensive viewer-specific visibility and thread rules
Phoenix multi-action ranking
Build the scoring request
Home Mixer sends viewer history and hydrated candidate features, capped at 2,800 posts.
Prepare feature streams
Encode user-prefix, history, and candidate tokens from IDs, SIDs, actions, time, and context.
Apply isolated attention
Each candidate sees viewer context but not other candidates; open this concept for the mask.
Run the transformer
Shared layers model the viewer's sequence and each candidate-conditioned outcome.
Predict action heads
Emit logits for engagement, clicks, attention, author actions, and negative feedback.
Attach predictions
Return discrete action scores and continuous dwell outputs to every candidate.
64 discrete action slots in production configs
8 continuous dwell-output slots
2,800 Home Mixer scoring-request cap
Phoenix predicts actions; it does not directly emit the final business score.
RankingScorer performs the explicit value trade-off in the next stage. The same Phoenix ranking model scores candidates from every recall source. Why candidates cannot see each other
Share viewer context
User and history tokens attend within the viewer-context block.
Expose context to candidates
Every candidate can attend to the same user and history representation.
Keep self-attention
A candidate can attend to its own position and features.
Block cross-candidate edges
Candidate i cannot attend to candidate j when their positions differ.
LOCKED
context ↔ context: allowed
candidateᵢ → context: allowed
candidateᵢ → candidateᵢ: allowed
candidateᵢ → candidateⱼ: blocked when i ≠ j
A post's Phoenix score is invariant to its batch companions.
That makes scores stable across candidate batch composition and safer to cache or compare. From action probabilities to value
Read Phoenix predictions
Collect positive, negative, click, attention, dwell, and author-action estimates.
Apply explicit weights
Multiply each prediction by its configured value and sum the terms.
Decay repeat authors
Later posts from the same author receive a bounded multiplicative penalty.
Adjust network and cold start
Discount eligible OON shapes and lift qualifying low-impression authors toward a target.
Emit one scalar
The resulting final score becomes the input to VM Ranker and top-K selection.
LOCKED
base_score(post) = Σᵢ weightᵢ × P(actionᵢ | viewer, post)
final_score = adjust(base_score, author_diversity, network, cold_start)
Adjustment Purpose Shape Adjustment Action weights Purpose express product value Shape positive and negative additive terms Adjustment Author diversity Purpose reduce repeated authors Shape decay with a configured floor Adjustment OON weighting Purpose calibrate unfamiliar inventory Shape multiplicative discount Adjustment Cold-start policy Purpose create room for qualifying new authors Shape score lift toward a target position
Where Phoenix ranking weights live
Learn model parameters
Phoenix training learns transformer, embedding, and action-head matrices stored in a checkpoint.
Predict an action vector
The RPC boundary returns discrete action log-probabilities and separate continuous outputs for each candidate.
Load product weights
Home Mixer reads per-action values from request parameters populated by feature switches and experiments.
Multiply and sum
The default weighted mode combines positive and negative action terms; an optional dwell-regret mode can replace this sum.
Apply later adjustments
Score offsets, author diversity, out-of-network scaling, cold-start rules, and VM reranking can change the order again.
Weight layer Set by Examples Input → output Update cadence Weight layer Learned Phoenix parameters Set by model training Examples transformer, embeddings, action-head matrices Input → output viewer and candidate features → action predictions Update cadence checkpoint rollout Weight layer Home Mixer action weights Set by feature switches and experiments Examples favorite, reply, share, dwell, report, block, mute Input → output action predictions → one scalar Update cadence request-time configuration
+0.5 favorite default before overrides
+5.0 reply default before overrides
−58.8 mute-author default before overrides
−234 report default before overrides
Yes—but Phoenix does not directly emit the final weighted score.
Phoenix contains learned neural weights and returns multiple predicted actions for each post. Home Mixer's default weighted mode applies configurable action weights; an optional dwell-regret mode can bypass that sum. Default magnitudes combine product value with typical action frequency, so they are not literal human-value ratios. Every action coefficient in weighted mode
Read Phoenix outputs
Use the discrete action scores and continuous outputs attached to each candidate.
Resolve conditional coefficients
Mutual-follow, video-duration, network, and unexplored-post rules can change whether a term applies.
Multiply every term
Each contribution is the candidate's predicted signal value times its effective coefficient; missing predictions contribute zero.
Separate positive and negative mass
Add nonnegative contributions and the absolute size of negative contributions independently.
Create the base scalar
Subtract negative from positive, apply the score offset, then pass the result to later diversity, network, and VM adjustments.
−234 report: largest raw negative default
−58.8 mute author: second-largest raw negative
−43.2 not interested: third-largest raw negative
+20 copy-link share; eligible mutual reply can also reach this
LOCKED
ACTIVE POSITIVE DEFAULT COEFFICIENTS
signal coefficient condition
share via copy link +20.000 —
reply +5.000 +15.000 for eligible mutual-follow original posts
share via DM +5.000 —
quote +5.000 —
follow author +4.000 —
share +2.000 —
retweet +1.000 —
favorite +0.500 —
click +0.400 —
open link +0.200 —
photo expand +0.050 —
video open +0.050 —
VQV +0.050 duration and viewer-follower gated
quoted click +0.050 —
post unexplored +0.020 additive and in-network only by default
continuous dwell time +0.004 per continuous-output unit
LOCKED
NEGATIVE DEFAULT COEFFICIENTS
signal coefficient
report −234.000
mute author −58.800
not interested −43.200
block author −31.200
not dwelled −0.020
ZERO / INERT BY DEFAULT
profile click 0.000
dwell action head 0.000
quoted VQV 0.000
continuous click dwell time 0.000
active-seconds residual 0.000
mutual-follow dwell boost 0.000
Raw coefficient rank is not the same as real ranking impact.
The actual contribution is prediction times effective coefficient, and rare actions can receive large coefficients. Continuous outputs use different scales, while candidate-specific gates can zero or boost individual terms. To measure empirical importance, aggregate absolute per-term contributions on real traffic before later reranking—not coefficients alone. Where the weight numbers come from
Define repository defaults
param.rs declares the baseline coefficient for every weighted action signal.
Load request-time values
ScoringWeights::from_params reads the effective values, so feature switches or experiments can override those defaults.
Map predictions to coefficients
compute_weighted_parts pairs each PhoenixScores field with its effective coefficient and multiplies them.
Build the scalar
RankingScorer combines positive and negative contribution mass, then applies the score offset.
Apply later reranking
Diversity, out-of-network scaling, cold-start policy, and VM Ranker can still change the final order.
Source What it proves Kind Authority for the table Source param.rs What it proves exact numeric defaults Kind actual code Authority for the table baseline values Source ScoringWeights::from_params What it proves defaults can be overridden per request Kind actual code Authority for the table effective values Source compute_weighted_parts What it proves signal-to-coefficient mapping and multiplication Kind actual code Authority for the table contribution logic Source README.md What it proves system architecture and pipeline stages Kind documentation Authority for the table not the numeric weights
The numeric table is code-derived, not README-derived.
The default numbers come directly from home-mixer/params/param.rs. Their runtime loading and multiplication are confirmed in home-mixer/scorers/ranking_scorer.rs. The README was used only for architectural context. VM Ranker diversity pass
Receive scalar scores
Start from RankingScorer's value-ordered candidate list.
Read candidate embeddings
Represent similarity between posts in the current slate.
Optimize a DPP objective
Balance quality against similarity so neighboring items are less redundant.
Return reranked scores
Pass the diversified order into the top-K selector.
VM Ranker can sacrifice a little relevance score to avoid a locally repetitive slate.
Selection and output budgets
Sort final scores
Order all surviving organic candidates after the sequential scorer chain.
Keep the top 50
The inner selector advances the highest-scoring posts to final hydration.
Apply visibility and thread rules
Hydrate verdicts, drop disallowed primary or ancillary posts, and dedupe conversations.
Cap organic output at 35
The inner post pipeline returns at most 35 ranked organic posts.
Reserve outer module capacity
The outer pipeline can add modules and frames up to a nominal 47 items.
50 posts entering final visibility work
35 maximum organic results
47 nominal outer feed-item maximum
Viewer-specific visibility filtering
Hydrate the viewer
Load country, settings, follows, blocks, mutes, subscriptions, and safety preferences.
Hydrate content and labels
Load post, author, account state, safety labels, and ancillary conversation objects.
Choose the safety level
Followed posts use TimelineHome; OON posts use stricter recommendation policy.
Evaluate ordered base rules
Apply universal user, relationship, access, label, and interstitial rules.
Apply OON-only drops
Recommendations add high-recall spam, NSFW, malicious URL, abuse, and do-not-amplify rules.
Filter primary and ancestors
Drop rejected posts and posts whose parent, quote, or repost context is rejected.
Verdict Feed behavior Meaning Verdict ALLOW Feed behavior keep normally Meaning all applicable rules permit display Verdict INTERSTITIAL Feed behavior keep with safety action Meaning client can place content behind a warning Verdict DROP Feed behavior remove after ranking Meaning primary or ancillary policy forbids display
Ranking and visibility are intentionally separate decisions.
Phoenix estimates likely behavior and order; visibility answers whether this viewer may see the post. An interstitial verdict remains in the feed; rendering the warning is outside this repository. The asynchronous labeling path
Score content and accounts
Models continuously analyze text, media, engagement reactions, and account behavior.
Consume events
Grox and event processors turn publication or behavior events into plan and rule inputs.
Evaluate labeling rules
Scarecrow embeds BotMaker rules; abuse enforcement maps model outputs to actions.
Write labels
Post and account labels persist outside the synchronous feed request.
Read at visibility time
Visibility Filtering hydrates those labels only for the selected viewer and post.
Aggregate transparency
Under the Hood jobs summarize visibility-impacting labels for account reports.
Subsystem Signal Role Subsystem Grox and media models Signal text, image, video, embeddings Role content understanding and labels Subsystem Agatha, BDSM, User Cred Signal reactions, action sequences, graph mass Role account-level model scores Subsystem Scarecrow and BotMaker Signal events plus declarative rules Role real-time label application Subsystem Abuse Enforcement Signal account model results Role labels, challenges, or suspension actions
These systems influence the request through labels; they are not inline ranking stages.
No Grox, BDSM, or BotMaker client appears in the active PhoenixCandidatePipeline constructor. Their stored outputs become request-time inputs only when Visibility Filtering hydrates policy state. Final feed composition
Load outer history
Hydrate served history and past request timestamps for final composition.
Source feed item types
Run scored posts, ads, Who to Follow, prompts, push-to-home, frames, and survey concurrently.
Deduplicate push items
Prevent a push-to-home item from repeating an organic result.
Blend ads around posts
Apply the configured ad strategy and brand-safety adjacency constraints.
Insert fixed modules
Place prompts, Who to Follow, push items, frames, and surveys at configured slots.
Finalize feed items
Apply post-selection ad adjacency checks and return the composed sequence.
Item type Origin Placement logic Item type Organic posts Origin ranked inner pipeline Placement logic base sequence after visibility Item type Ads Origin ad index Placement logic interleaved with safety and spacing rules Item type Prompts and Who to Follow Origin dedicated services Placement logic configured fixed positions Item type Push, frames, survey Origin reply, Strato, local source Placement logic gated special modules
Detached feedback and observability
Finish the response path
Selection and serialization complete before detached work is scheduled.
Spawn enabled effects
The pipeline launches all enabled side effects together in a background task.
Persist feed memory
Update served ads, seen IDs, served candidates, request timestamps, and served history.
Publish learning signals
Emit client, ranking, experiment, cache, and response-stat events for later systems.
Side-effect failures do not block the primary feed response.
The response stays latency-isolated while future requests still gain served and seen history. User engagements enter upstream action systems and later become Phoenix context and training data.
What the code shows
Candidate sources retrieve recent posts from followed accounts and out-of-network recommendations.
The Phoenix ranker predicts how each viewer may respond to each candidate.
RankingScorer converts those predictions into a value score, then the VM ranker adds diversity before Top-K selection.
Visibility rules remove or restrict ineligible posts before the feed is blended with other timeline items.
What this means for creators
The code does not reveal a guaranteed recipe for reach. It does show that X ranks for predicted viewer actions, filters negative and safety outcomes, and preserves some diversity in the final feed. The practical response is to publish specific posts for a real audience, earn useful interactions, and avoid spam-shaped behavior.
Turn the research into a repeatable X workflow
ThreadWave helps you find timely ideas and reply opportunities, draft in your voice, and keep important actions reviewable.
Set up ThreadWave