- Sources read: 3
- Canon files updated: 1
- Radar entries: 1
Other changes reviewed today:
- In the same commit, X began testing in shadow traffic a feature that puts the list of user IDs who engaged with a candidate post into the ranker request.
- In earlier X commits, the popular posts source was separated from the Phoenix retrieval label, and the share weight of the immersive page re-ranker dropped from 40 to 4.
- Spotify published a blog post on how it reduced the inference cost of podcast LLM recommendation together with NVIDIA.
1The popular posts source now has its own label, separate from Phoenix retrieval — X
Source xai-org/x-algorithm@bc3948b — xAI public repository, commit of 2026-10-16 19:02 UTC, code. These notes number X commits after the Gen4 release in sequence, and this commit is Gen4+43. It was not yet in the GitHub API list in the 2026-10-17 batch, so it is covered here for the first time.
Background X gathers For You candidates from several sources, and the popular posts source, introduced in the 2026-10-03 commit (Gen4+35), pre-selects fast-growing-view posts from top authors by follower count. Until now, candidates from this source went out under the same label as Phoenix two-tower retrieval. Phoenix is X's Transformer model ported from Grok-1, and two-tower retrieval finds candidates by the dot product of a user vector and a post vector. This commit separates that label and changes the default weights of page_rl, the re-ranker for the immersive video surface, and also fixes carousel dedup, the visibility-filtering lookups and a training label.
What we learnedA. Popular posts candidates carry their own label
- The served type of popular posts candidates (the source label attached to a candidate) changed from
ForYouPhoenixRetrievalto its own valueForYouPopularPostsverified —home-mixer/sources/popular_posts_source.rs:13.- The code name of this source is
PopularPostsSource.
- The code name of this source is
What we learnedB. The default weights of page_rl changed, and weights can now be sent per request
page_rl is the re-ranker for the immersive vertical video surface released in the 2026-10-14 commit (Gen4+41). It cuts the candidate pool by the weighted sum of ranker head probabilities (behavior score), and the decoder picks one slot at a time. The softmax of this score serves as the reference policy that RL training should not drift away from.
The default weights of the page_rl behavior score changed verified —
phoenix/xrex/models/page_rl.py:69-70.- Video quality view (VQV, a view of a video watched for at least a set duration) goes from 0.5 → 1.0, and share goes from 40.0 → 4.0 verified.
- The decoder serving switch is still off by default.
- vqv_weight: float = 0.5 - share_weight: float = 40.0 + vqv_weight: float = 1.0 + share_weight: float = 4.0The caller can now send behavior score weights per request verified —
page_rl.py:319-324.RankingScoreWeights(13 fields) was added toPageDecodeParamsin the ranking request verified.- If a value is NaN, the config default is used verified.
- Another evidence location is
recsys.proto:198-214.
What we learnedC. Embedding-based dedup was added to the video carousel, off by default
- A video is skipped if its cosine similarity to an already selected video is 0.72 or higher; quote posts are an exception verified —
home-mixer/util/video_carousel.rs:72-105.- Embeddings are read from Manhattan's
tweet_multimodal_embeddings, versionv8_search_1(1024 dimensions), with a 100ms timeout verified —clients/post_v8_search_embedding_client.rs:12-17. - This is the first code in which home-mixer (the service that assembles the For You feed) reads this multimodal post embedding.
- Embeddings are read from Manhattan's
What we learnedD. visibility-filtering tolerates failures in 13 auxiliary lookups
visibility-filtering is a service that decides, post by post, whether "this viewer may see it".
- 13 lookups, including follow and block relationships, conversation controls and viewer country, became best-effort. If there is no response within 300ms, the verdict uses the default and the result counts as complete verified —
visibility-filtering/hydration/plan.rs:375-409.- Another evidence location is
rules/registry.rs:167-175. - A test states the cost explicitly. If the follow lookup fails, posts from private accounts can be dropped even for real followers verified —
rules/rule_spec/laws.rs:262-293.
- Another evidence location is
What we learnedOther changes
- A training label
IsBrandEngagementwas introduced. It treats 10 actions as positive and does not include video watch or dwell verified —brand_engagement.rs:5-19.- The 10 actions are like, reply, retweet, author follow, click, link open, profile click, photo expand and carousel swipe verified.
- No head uses this label yet.
Canon update In services/x.md, wrote a new "Gen4+43" section in the change log under the ranking section. Also fixed the label sentence in the PopularPostsSource row of the candidate source table, the corresponding statement in the Gen4+35 section, and the page_rl weight bullet in the Gen4+41 section.
Why it matters ⚠ Claim changed: the canon said popular posts candidates are mixed in under the Phoenix retrieval label and cannot be told apart in later stages, but they now carry a separate label verified. The page_rl reference policy now weights video quality views more heavily than shares verified (values).
2Dedup for the video carousel is now on by default — X
Source xai-org/x-algorithm@862a123 — xAI public repository, commit of 2026-10-17 00:44 UTC, code. In these notes' numbering, this is Gen4+44. The sync time of the cron mirror (a file that syncs and publishes production config values daily) is 2026-10-16T16:00:32Z.
Background Since the 2026-10-08 commit (Gen4+38), X has kept a carousel module that bundles 3–5 vertical videos in the sixth slot of For You, off by default. Dedup rules that stop the same author or similar videos from crowding into one carousel were added, still off, in the 2026-10-13 commit (Gen4+40) and the 2026-10-16 commit (Gen4+43). Who-to-Follow (WTF) is an in-feed module that recommends accounts to follow; meanwhile, until now the ranker received a post's engagement only as aggregate counts. This commit turns dedup on by default, keeps WTF and the carousel from appearing in one response, and adds an engager list feature.
What we learnedA. Three carousel dedup rules are now on by default, and the carousel itself is still off
- The defaults of three carousel dedup rules changed verified —
home-mixer/params/param.rs:1095-1112.EnableVideoCarouselAuthorDedupegoes false → true,VideoCarouselSemanticIdDedupeLevelsgoes 0 → 3, andEnableVideoCarouselEmbeddingDedupegoes false → true verified.- SID (Semantic ID, an identifier that quantizes an item embedding into a hierarchical code sequence): of the videos that share the first 3 levels of the SID, only one stays in a carousel.
- The carousel itself is still off by default.
What we learnedB. If the same response has a Who-to-Follow module, the carousel is not inserted
If the same response has a WTF module, the carousel is not inserted. This is an unconditional rule with no parameter verified —
selectors/blender_selector.rs:50, 156-161.video_carousel.filter(|_| wtf_modules.is_empty())
What we learnedC. A feature that puts the list of users who engaged with a candidate post into the ranker request was introduced
- A feature was introduced that puts the IDs of users who engaged with a candidate post into a new field of the ranking request verified —
util/post_engagers.rs:7-8, 48-73.- The feature is named
PostEngagers, and the new field isTweetInfo.postEngagers. - There are up to 32 positive and up to 8 negative users, and each entry carries an action bit and the seconds elapsed since the engagement.
- The viewer themselves and engagements after the serving time are excluded.
- The switch
EnablePostEngagersis off by default but is always on in shadow traffic (requests replicated for testing and not used in user responses) verified —candidate_hydrators/post_engagers_hydrator.rs:43-45. - No model code that reads this field is in this diff.
- The feature is named
What we learnedOther changes
- The new filter
ZeroFavCodivertFilter(off by default) keeps a candidate that reached a treatment viewer only through the ZeroFav retrieval channel only when its author is also in the treatment bucket verified —filters/zero_fav_codivert_filter.rs:44-80.- The ZeroFav retrieval channel is a channel that finds posts that have no likes yet.
- We infer this is a two-sided experiment device that splits viewers and authors together inferred. The evidence is the per-author-bucket counters.
- Two-tower retrieval training shares the candidate pool across several microbatches, and each user uses the whole pool as in-batch negatives verified —
phoenix/xrex/models/recsys_two_tower_model.py:556-618.- In-batch negatives are a method that uses other users' positives in the same batch as wrong answers.
- No preset uses this yet.
- The visibility-filtering and abuse-enforcement changes are renames and metrics, and we did not find any place where what the feed filters changed inferred. We did not read every hunk line by line.
Canon update Wrote a new "Gen4+44" section in the change log of services/x.md, and added default-on dedup and the WTF-first rule to the carousel item in the feed surface section. Added four items to the open questions, including the model that consumes postEngagers, and raised the reference commit in ## Sources to 862a123.
Why it matters The carousel is still off, but the dedup and the conflict rule with other modules were settled as defaults first verified (values). PostEngagers is a feature that passes "who reacted" to the ranker with identity and action type instead of an engagement count, so we infer it is an experiment to feed social graph signals directly into ranker input inferred. The evidence is the proto structure and the always-on shadow traffic.
3TensorRT LLM reduced the inference cost of podcast LLM recommendation — Spotify (radar)
Source Advancing Generative Recommendation Inference: our collaboration with NVIDIA on TensorRT LLM — Spotify Engineering, 2026-10-16, blog post. Written by seven engineers from Spotify and NVIDIA.
Background Spotify has used an LLM for podcast recommendation since 2026-01 verified. Because the LLM generates Semantic ID token sequences and converts them into catalog items, beam search (decoding that explores several high-probability token sequences at once) has to run on the serving path. This post covers how that cost was reduced with TensorRT LLM (NVIDIA's LLM inference engine).
What we learnedA. Serving splits into two workloads, SID generation and candidate scoring, and personalization uses a single soft token
There are two workloads: generating top SID sequences with beam search, and scoring several candidates in one request with candidate masking verified.
"these top sequences constitute semantic IDs that are then translated to catalog items to serve recommendations" — Advancing Generative Recommendation Inference, 2026-10-16 (blog)
Personalization works by projecting the existing user embedding into the LLM embedding space as a single soft token verified.
"learn a projection from an existing embedding space into an LLM's embedding space as a single soft token. The LLM is fine tuned using a subset of the weights to be able to use this soft token to personalize recommendation outputs." — same post (blog)
What we learnedB. The cost reduction was published, and multi-sequence beam search and more were contributed to TensorRT LLM itself
On Qwen3 1.7B, the cost reduction is up to 54% for beam search and up to 7% for scoring verified. The post is not clear about what the comparison baseline is.
"up to 54% cost reduction for beam search workloads and up to 7% cost reduction for scoring workloads" — same post (blog)
Contributed multi-sequence-return beam search, a multi-item scoring Python API and more to TensorRT LLM itself verified.
Canon update Spotify is not a tracked service, so nothing was folded into the canon. Added one evidence line to the "Spread of LLM-native ranking" thread in radar.md.
Why it matters If Spotify GLIDE (2026-08-03) in the same thread was a statement that "an LLM candidate generator on the serving path wins in A/B", this post is a statement about how to reduce its operating cost inferred. Both posts cover the SID generation model for the podcast surface, but neither states explicitly that it is the same model.
What to check next
- Whether the Phoenix model code that reads
TweetInfo.postEngagersis released — which encoder writes the engager ID list is the crux of this feature. - The home-mixer caller that fills
RankingScoreWeights— we need to confirm whether the page_rl weights are meant to vary per experiment arm. - The day
EnableVideoCarouselflips to on by default — until then, every statement about the carousel concerns an off-by-default feature.
Lookup status
- X:
xai-org/x-algorithmhad two new commits (bc3948b,862a123). There is no release. - Meta: the latest posts on engineering.fb.com are three dated 2026-10-15, already checked in the 2026-10-17 batch. The latest post on ai.meta.com/blog is from 2026-07. transparency.meta.com was not checked this time.
- Netflix: RSS had one new post (Ontology-Driven Observability, 2026-10-16), but it was an observability infrastructure post, so it was skipped. research.netflix.com/publications was not checked.
- arXiv cs.IR: 30 items were parsed. The latest submission is 2026-10-15, the same window as the 2026-10-17 batch, so nothing new passed. AdCoEvo, seen for the first time, was dropped because it concerns ads operations automation.
- Monday industry blogs: Google Research, Pinterest and LinkedIn had no new recommendation posts. One 2026-10-16 Spotify Engineering post was added to the radar. WebSearch cross-checks found no new announcement with a primary source.