2026-08-22

Other changes reviewed today:

• X added a path in the same commit that attaches an AI trend label to original posts in For You. It is off by default.
• In the same commit, the share of child-safety cross-model validation and deluxe 4.3 category reclassification calls sent to Grok 4.6 rose from 0.1 to 0.3.
• The Xiaohongshu OneModel paper, which unifies three surfaces (organic recommendation, ads, and store) into one ranker, was added to the radar with production A/B results.

1For You ranking can receive slate context from Phoenix serving — X

• What Gen4+4 prepared: the new SlateContext.sid* fields in the Phoenix (X For You's ranking model) proto, the new RewardOutputs, and the xrecsys_search config.
• This commit is the first place in the code where SlateContext is confirmed to flow along the Phoenix prediction response into home-mixer (the service that assembles the For You feed).

Three concepts are new in this commit:

• AI trend is an item that appears on X's "Trending" surface (events many people are talking about).
  • Before this commit, the home-mixer pipeline had no logic that attached an "AI trend" label to tweets.
  • Strato is the internal system that X code goes through to look up or store data.
  • An upstream pipeline in which Grok looks at a tweet, decides which AI trend it belongs to, and stores the result in Strato likely existed (the batch_get_tweet_ai_trend API), but that pipeline is outside this repository inferred.
• SlateContext is the context vector that each slot holds in a DPP (a diversity technique that selects items as a set so that the score drops when similar items are picked together) re-ranking slate.
  • k is the slot index, pool_rank is the rank in the original score ordering, and pool_rank_gap is the pool rank difference from the slot above.
  • fatigue, pre_diversity_score, and sid_known are added to these.
  • sid_k_l1/l2/l3 hold the slot index for each of the three SID (semantic ID, a token sequence that represents an item as hierarchical codes) layers.
  • sid_gap_l1/l2/l3 hold the inter-slot gap for each SID layer.
  • It is the same field set as when seven SID fields were added to VMRanker (the service that handles DPP slate reordering) in the 8/18 commit, Gen4+3.
• The served slate context is a schema field in which the Phoenix serving response returns, for each candidate, the material used for re-ranking.
  • The material is the pool rank, fatigue, pre-diversity score, three SID layers, and three SID gap layers.
  • In the Gen4+4 proto it was only defined; this commit connected the consumption path.

A hydrator that attaches AI trend labels to original posts in For You was added

This commit adds a new stage that selects standalone original posts among For You candidates and attaches AI trend labels verified. At most 2 labels are attached per page, and the gate that turns on this stage is false by default verified.

• A hydrator that fills AI trend information into candidate posts was added as a new 157-line file verified — home-mixer/candidate_hydrators/ai_trend_feedback_context_hydrator.rs.

  • The pipeline wiring is at phoenix_candidate_pipeline.rs:424-428.
  • It was added right after the existing TopicFeedbackContextHydrator, side by side. Topic feedback context is a context label used to infer the user's topics of interest.

  Box::new(TopicFeedbackContextHydrator { strato_client: strato_client.clone() }),
  Box::new(AiTrendFeedbackContextHydrator { strato_client: strato_client.clone() }),
  

• This hydrator runs only when all three gate conditions are met verified — ai_trend_feedback_context_hydrator.rs:59-63.

  • The gate parameter rust_home_mixer_enable_ai_trend_feedback_context must be on. It is false by default.
  • The request must not be a topic request (so that it does not overlap the topic surface).
  • The request must not be for the Following surface (requests that receive only posts from followed accounts). This condition applies per request and does not check whether a candidate is from a followed account.
  • The hydrate loop (L65-75) also filters only by the original-post condition below, so candidates from followed accounts that are mixed into a For You request are also targets.
  • It is not wired into the Following pipeline.

  query.params.get(EnableAiTrendFeedbackContext)
      && !query.is_topic_request()
      && !query.in_network_only
  

• Candidates pass a four-part condition that keeps only the "standalone original post" verified — ai_trend_feedback_context_hydrator.rs:19-24.

  • A candidate is dropped if it is a reply, is a retweet, has a conversation ancestor, or is a post that a followed user replied to. Meeting any one of the four drops it.
  • In effect, AI trend labels can be attached only to original posts that are not replies, reposts, posts with conversation ancestors, or posts that followed users replied to. Whether a post is a quote post is not checked.

  fn is_eligible_original_post(candidate: &PostCandidate) -> bool {
      candidate.in_reply_to_tweet_id.is_none()
          && candidate.retweeted_tweet_id.is_none()
          && candidate.ancestors.is_empty()
          && candidate.following_replied_user_ids.is_empty()
  }
  

• The Top-2 trends are chosen by candidate frequency, and one candidate is picked at random per trend to receive the label verified — ai_trend_feedback_context_hydrator.rs:24-52.

  • The procedure has five steps.
    1. For each candidate that meets the conditions, look up the trend_id with Strato batch_get_tweet_ai_trend.
    2. Build a frequency histogram of the candidates' trend_ids.
    3. Pick the top 2 trends. On a tie, the smaller trend_id takes priority.
    4. For each trend, pick one candidate at random.
    5. Look up the display name of that trend with Strato batch_get_ai_trend_name.
  • In effect, at most 2 AI trend labels are attached per page, and each trend's label goes on only one candidate.
  • It is a suppression mechanism that prevents the same label from being attached repeatedly to multiple candidates in the same trend.

  const TOP_TREND_COUNT: usize = 2;
  
  fn select_feedback_targets(candidate_trends: &[(usize, i64)]) -> HashMap<usize, i64> {
      let mut frequency: HashMap<i64, usize> = HashMap::new();
      for (_, trend_id) in candidate_trends {
          *frequency.entry(*trend_id).or_default() += 1;
      }
      let mut ranked: Vec<(i64, usize)> = frequency.into_iter().collect();
      ranked.sort_by(|a, b| b.1.cmp(&a.1).then_with(|| a.0.cmp(&b.0)));
      ranked.truncate(TOP_TREND_COUNT);
  
      let mut rng = rand::rng();
      let mut selected: HashMap<usize, i64> = HashMap::new();
      let mut used_indices = std::collections::HashSet::new();
      for (trend_id, _) in ranked {
          let candidates_for_trend: Vec<usize> = candidate_trends
              .iter()
              .filter(|(idx, id)| !used_indices.contains(idx) && *id == trend_id)
              .map(|(idx, _)| *idx)
              .collect();
          let Some(&idx) = candidates_for_trend.choose(&mut rng) else { continue };
          used_indices.insert(idx);
          selected.insert(idx, trend_id);
      }
      selected
  }
  

• On screen it goes out in the same form as a topic label, and AI trend is used only when there is no topic feedback verified — home-mixer/util/urt/post_marshaller.rs:72-110.

  • At the render stage it joins the topic path of the URT (X's response rendering schema) TweetContext as a fallback.
  • Both go out in URT as the same context type, ContextType::TOPIC.
  • The AI trend path differs from the topic path in two ways: landing_url is filled, and TopicFeedbackContext.topic_id is None.
  • So when a user taps the topic-style chip attached above this tweet, it goes to x.com/i/trending/{trend_id}, the trend surface, rather than the topic feedback page.

  if let Some(topic) = post.topic_feedback_topic.as_ref().filter(|t| !t.is_empty()) {
      return Some(TweetContext {
          context_type: ContextType::TOPIC,
          text: topic.clone(),
          landing_url: None,
          context: Some(TweetContextDetails::TopicFeedbackContext(TopicFeedbackContext {
              topic: Some(topic.clone()),
              url: None,
              topic_id: post.topic_feedback_topic_id.clone(),
          })),
          ..
      });
  }
  let trend = post.ai_trend_name.as_ref().filter(|t| !t.is_empty())?;
  let trend_id = post.ai_trend_id.as_ref().filter(|id| !id.is_empty())?;
  let landing_url = Url {
      url_type: UrlType::EXTERNAL_URL,
      url: format!("https://x.com/i/trending/{trend_id}"),
      urt_endpoint_options: None,
  };
  Some(TweetContext {
      context_type: ContextType::TOPIC,
      text: trend.clone(),
      landing_url: Some(landing_url.clone()),
      context: Some(TweetContextDetails::TopicFeedbackContext(TopicFeedbackContext {
          topic: Some(trend.clone()),
          url: Some(landing_url),
          topic_id: None,
      })),
      ..
  })
  

  "https://x.com/i/trending/{trend_id}" — post_marshaller.rs:92

The following four items are not public:

• The definition of AI trend (who creates trend ids and how, and whether tweets are clustered with Grok or curated by people)
• The upstream pipeline of batch_get_tweet_ai_trend
• Whether EnableAiTrendFeedbackContext is actually deployed
• The tuning history of TOP_TREND_COUNT = 2

Because the rust_home_mixer_ prefix in the gate name follows the same convention as other rust-migration gates in this repository, an A/B experiment may be in progress inferred.

• The observation signals widen as well. A user's reaction of tapping, dismissing, or ignoring this chip becomes a label source for judging whether this user is interested in this AI trend.
• This is a different direction from the "layer expansion of the safety pipeline" folded in from Gen4 through Gen4+4. It confirms a trend of widening the signal source upstream of ranking itself.

The ranking stage consumes the slate context that Phoenix computed at serving

The SID fields created in the Phoenix proto in the 8/19 Gen4+4 commit (three SID layers and three gap layers for each slot) were connected to an actual pipeline consumption path in this commit. The proto field name is SlateContext.sid*. Four places opened at the same time:

• The candidate struct gained one more slot for slate context, so it now has two verified — home-mixer/models/candidate.rs:26-27, 76-77.

  • The struct is named PostCandidate, and the new field is served_slate_context.
  • The existing slate_context is a value that home-mixer computed and cached.
  • The new served_slate_context is a value that Phoenix computed at serving and sent in the response.

  pub struct PostCandidate {
      pub score: Option<f64>,
      pub slate_context: Option<SlateContext>,
      #[serde(default)]
      pub served_slate_context: Option<SlateContext>,  // ← new
      ...
      pub ai_trend_name: Option<String>,   // ← new in the section above
      pub ai_trend_id: Option<String>,     // ← new in the section above
  }
  

• The conversion impl between proto and Rust renames the proto's short field names to home-mixer names verified — candidate.rs:99-118.

  • It renames the proto's sid_k1/2/3 and sid_gap1/2/3 to the home-mixer naming convention sid_k_l1/l2/l3 and sid_gap_l1/l2/l3.
  • Here "l" stands for level.

  impl From<xai_recsys_proto::SlateContext> for SlateContext {
      fn from(c: xai_recsys_proto::SlateContext) -> Self {
          Self {
              k: c.k,
              pool_rank: c.pool_rank,
              pool_rank_gap: c.pool_rank_gap,
              fatigue: c.fatigue,
              pre_diversity_score: c.pre_diversity_score,
              sid_known: c.sid_known,
              sid_k_l1: c.sid_k1,
              sid_k_l2: c.sid_k2,
              sid_k_l3: c.sid_k3,
              sid_gap_l1: c.sid_gap1,
              sid_gap_l2: c.sid_gap2,
              sid_gap_l3: c.sid_gap3,
          }
      }
  }
  

• PhoenixScorer extracts the slate context from the Phoenix prediction response and fills the new field verified — home-mixer/scorers/phoenix_scorer.rs:107-125.

  • When the Phoenix prediction response carries SlateContext alongside the 24 candidate scores (engagement probability heads), PhoenixScorer sets that value in served_slate_context and passes it down the pipeline.
  • The value is taken from candidate_slate_context() of the prediction response.

  .map(|c| PostCandidate {
      phoenix_scores: predictions.candidate_scores(&c.get_original_tweet_id()),
      served_slate_context: predictions
          .candidate_slate_context(&c.get_original_tweet_id())
          .map(Into::into),
      prediction_request_id: Some(query.prediction_id),
      last_scored_at_ms,
      ..Default::default()
  })
  

• RankingScorer decides the slate context with a three-way fallback verified — home-mixer/scorers/ranking_scorer.rs:700-710, 806-825, 875-895.

  1. If the UseServedSlateContext gate is on and Phoenix sent slate context for all candidates, that value is used as is.
  2. If the gate is off or the data is incomplete, and the Redis warming cache hits, the slate context stored for a previous request is reused.
  3. Otherwise, it is computed locally with compute_slate_contexts(candidates, weighted_scores).
  • This order applies identically to both ranking branches.

  fn served_slate_contexts(
      query: &ScoredPostsQuery,
      candidates: &[PostCandidate],
  ) -> Option<Vec<SlateContext>> {
      if !query.params.get(UseServedSlateContext) {
          return None;
      }
      candidates.iter().map(|c| c.served_slate_context).collect()
  }
  
  // ... in each of the two ranking paths (the mpn_scoring branch and the diversity branch):
  let persisted_contexts: Option<Vec<SlateContext>> =
      match Self::served_slate_contexts(query, candidates) {
          Some(served) => Some(served),
          None if query.has_cached_posts => Self::stored_slate_contexts(candidates),
          None => Some(Self::compute_slate_contexts(candidates, &weighted_scores)),
      };
  

• The gate that turns on this path came in with a default of false. Only the gate has been created, and the actual rollout is deferred to a later parameter change.

  • The gate name is UseServedSlateContext.

• That saves ranker CPU.
• The richer context that Phoenix holds can be reflected in re-ranking. For example, the three SID layers cannot be computed without Phoenix.
• The direction is for home-mixer to keep shrinking into a thin layer that handles only candidate allocation and re-ranking.
• The direction is the same as SID being connected to VMRanker in the 8/18 commit (Gen4+3). By definition SID is a Phoenix training output, so home-mixer cannot compute it locally, and this commit resolved that problem at serving time.
• The point at which a commit promotes UseServedSlateContext to true is the point at which Phoenix serving's slate context output reaches production traffic.

The core logic of the embedding table loader was separated from the Python bindings

The embedding table loader of the Phoenix serving engine was split into a Python-side wrapper and a core that does not depend on pyo3 verified.

• The core logic was split out of emb_table.rs as load_tensor_into, and the existing load_tensor was redefined as a thin wrapper around that core verified — phoenix/crates/serving/xai-recsys-engine/src/emb_table.rs.

  • The file overhaul is +189/−169, and it is essentially an equivalent refactor.
  • The existing load_tensor was tied to pyo3 types and pyo3 errors, so it could not be reused in non-Python contexts.
  • The tied types were Bound<'py, PyString>, PyReadwriteArray1<'py, u8>, and Bound<'py, PyList>, and the errors were PyValueError, PyOSError, and PyTypeError.
  • The new core does not depend on pyo3; it takes a &mut [u8] interface and returns Result<(), String>.

  pub fn load_tensor_into(
      path: &str,
      urls: &str,
      shard_sources: &[(String, String, usize, usize)],
      tensor: &mut [u8],
      row_size: usize,
      num_row_segments: usize,
  ) -> Result<(), String> { ... }
  
  #[pyfunction]
  pub fn load_tensor<'py>(
      py: Python<'py>,
      path: Bound<'py, PyString>,
      urls: Bound<'py, PyString>,
      shard_sources: Bound<'py, PyList>,
      mut tensor: PyReadwriteArray1<'py, u8>,
      row_size: usize,
      num_row_segments: usize,
  ) -> PyResult<()> {
      let mut parsed = ...;  // PyList → Vec<(String, String, usize, usize)>
      let path = path.to_string();
      let urls = urls.to_string();
      let tensor_slice = tensor.as_slice_mut()?;
      py.detach(|| {
          load_tensor_into(&path, &urls, &parsed, tensor_slice, row_size, num_row_segments)
              .map_err(PyOSError::new_err)
      })
  }
  

• Safety was also tightened.

  • Replaced the unwrap() on tokio runtime creation with map_err. The changed code is map_err(|e| format!("tokio runtime: {e}")).
  • Added a checkpoint path too short guard. The condition is prefix.len() < 3, and the message is checkpoint path too short: {path}.
  • Unified modulo checks such as row_segment_size % num_row_segments != 0 to the is_multiple_of API.

The share of calls sent to Grok 4.6 at two judge call sites rose from 0.1 to 0.3

In grox (the Grok-based nearline classifier sub-repo), the Grok 4.6 dial introduced by Gen4+4 on 2026-08-19 rose 3× in a day, from 10% to 30% verified. This dial is the probability of sending calls to 4.6 instead of Grok 4.5 at two judge call sites (child-safety cross-model validation and deluxe 4.3 category reclassification). Because the 4.6 response is used for verdicts just like 4.5's, it is a dial that splits live traffic, not a shadow that discards results verified — classifier.py:281-290@aad7179.

• What changed is one constant line verified — grox/flows/ptos/classifier.py:114.

  -_GROK_4_6_INTERNAL_DIAL = 0.1
  +_GROK_4_6_INTERNAL_DIAL = 0.3
  

• The circuit breaker configuration and the places where the dial applies are unchanged.

  • The parameters of the _EAPI_4_6_INTERNAL_BREAKER_CONFIG circuit breaker (failure rate 50%, window 600 seconds, recovery 600 seconds, half-open 5 calls) did not change.
  • The two places where the dial applies, child-safety cross-model validation and deluxe 4.3 category reclassification, are also unchanged.

• The Grok 4.5 judge layer introduced by Gen4+2 is being refined daily, and this commit is the fourth in that flow. The flow is +2 introduction → +3 finer logging → +4 4.6 dial 10% → +5 30%.
• If the next commit jumps to 50% or 100%, the full switch to 4.6 is close; if the dial drops again, a regression was observed.

Grok streaming responses can now be cut off midway when a condition is met

The grox Grok sampler gained a callback that ends a streaming response early, and it increments a counter each time it cuts one off verified.

• A stop_predicate callback was added to grox/libs/grok_sampler/llm.py verified — that file.

  • The scale is +27/−13.
  • The existing _sample_streaming kept consuming tokens from the raw stream as they arrived.
  • Now it wraps the raw stream in an explicit context with async with aclosing(...), which guarantees cleanup even on early termination. Tokens are received inside this async with aclosing block.
  • After each token is yielded, it checks stop_predicate(resp); if True, it breaks immediately and increments the counter llm.sample.early_stop.count.

  stop_predicate: Callable[[str], bool] | None = kwargs.get("stop_predicate")
  ...
  async with aclosing(self._sample_streaming_raw(request, **kwargs)) as raw_stream:
      async for tok in raw_stream:
          ...
          yield tok.text
          if stop_predicate is not None and stop_predicate(resp):
              logger.info(f"Response complete after {tokens_received} tokens, cancelling the stream")
              Metrics.counter("llm.sample.early_stop.count").add(1, attributes=attributes)
              break
  

• Safety verdict responses often arrive wrapped in a JSON tag (<json>...</json>), and once the tag closes, the tokens that follow are meaningless.
• Cutting off early with a callback such as stop_predicate=lambda r: "</json>" in r reduces token cost and also the latency after TTFT.

Grok classifiers can now reference the author's profile image

A profile image field was added to the User schema of the grox data loader verified. The field is filled when the author metadata has a profile image URL verified.

• The Grox User data loader gained a profile_image field verified.

  • The type is profile_image: Image | None.
  • The changed files are grox/core/data_loaders/data_types.py and post_mapper.py.
  • If AuthorMetadata.profileImageUrl exists, it is filled with Image(url=...).
  • Previously the User schema held only the URLs, the affiliated business, and recent posts, with no profile image.

  class User(BaseModel):
      urls: list[str] | None = None
      affiliated_business: AffiliatedBusiness | None = None
      recent_posts: list["Post"] | None = None
      profile_image: "Image | None" = None   # ← new
  

Summary of the six directions in this commit (Gen4+5, d0cef2f)

• Added a Gen4+5 (d0cef2f, 2026-08-20) row to the generation table (+479/−200, 14 files).
• Folded the following six items into the one-line summary:
  1. AI trend feedback context hydrator
  2. served_slate_context wiring starts
  3. emb_table core separation
  4. Grok 4.6 dial 0.3
  5. grok_sampler stop_predicate
  6. profile_image
• Rather than placing it under "Candidate generation", added a new subsection "AI trend feedback context — new in Gen4+5" between ranking and filters. It is positioned as a channel alongside topic feedback.
• After the Gen4+4 subsection of the "Phoenix training and index" section, created a new subsection "Gen4+5 (2026-08-20) — home-mixer starts consuming the slate context produced by Phoenix serving".
• After the Gen4+4 item in the "Grox → PtOS Adult Content Cross-Validation" section, added one line "Gen4+5 (2026-08-20) Grok 4.6 internal dial 0.1 → 0.3 (raised 3×)".
• Added a subsection "Resolved by the Gen4+5 release / New (2026-08-22)" to the open questions section. It lists 5 resolved items and 5 that need a deep dive.
• Added links to 6 files related to d0cef2f in the sources section.

• Gen4+4's SlateContext proto starting to be consumed in Gen4+5 is the third instance of this rhythm.
  • The first is Gen4+2's V2 label leading to the dual-write redesign in +3.
  • The second is Gen4+3's VMRanker SID wiring leading to the formalization of the sid* fields in the +4 proto.
  • The third is Gen4+4's SlateContext proto leading to the phoenix_scorer wiring in +5.
• The two directions are the axis that widens upstream signal sources (AI trend) and the axis along which home-mixer consumes Phoenix serving outputs in a thinner way.

↑ Contents

2OneModel unified ranking across three surfaces: organic, ads, and merchant — Xiaohongshu

• Netflix Foundation Model (FM) placed per-service heads on top of a single FM.
• Meta GEM built a backbone that unifies IG and FB within the ads domain.
• Yandex Music Gryphon-v2/Sona unified retrieval and ranking.

OneModel moves to a different angle: one backbone serves different business streams (organic, ads, merchant) at the same time.

• The abstract points out that keeping a separate ranking system per stream fragments user representations and raises engineering cost, and it proposes OneModel, which merges final ranking into one.

  "Platform-scale recommender systems often span multiple business streams such as organic recommendation, advertising, and merchant services, where user behaviors form a continuous cross-stream trajectory. Maintaining separate ranking systems fragments user representations and increases engineering cost. We propose OneModel, a unified framework for multi-stream final ranking. OneModel maps heterogeneous behaviors into shared event sequences, learns long-context user representations with an action-oriented backbone, and introduces Scenario-aware Information Modulation to balance cross-stream transfer and stream-specific specialization."

  — OneModel (arXiv 2608.18606) abstract (paper)

• There are three core architecture elements:

  • The shared event sequence unifies user behavior from the three streams (organic, ads, merchant) into one event sequence schema.
  • The action-oriented backbone is the part that learns long-context user representations. The abstract does not give the specific architecture.
  • Scenario-aware Information Modulation balances cross-stream transfer and stream-specific specialization through switching and gating. The former corresponds to sharing, the latter to dedicated handling.

• The abstract lists six optimization elements for production deployment.

  • stratified user representation
  • multi-objective training
  • feature decomposition
  • user feature prefetching
  • shared user-tower computation
  • graph-level inference optimization

• The A/B results came from the Xiaohongshu production deployment.

• The first is Netflix FM (service diversity, from foundation to head).
• The second is Meta GEM (surface diversity within the ads domain).
• The third is Xiaohongshu OneModel (business stream diversity).

↑ Contents

Corrections

None.

↑ Contents

Radar

• OneModel (Xiaohongshu, arXiv 2608.18606, 2026-08-19) is covered in section 2 above and was added to "new this month" in radar.md.

↑ Contents

What to check next

↑ Contents