2026-10-10

1The ranking request gains feed-request context fields, and H100 packing improves — X

• Two fields carrying the context of the feed request and the cursor direction were added to Phoenix's inference request message verified — phoenix/python/common/xai-proto/proto/recsys.proto:27-50, 175-176.

  • The message is named PredictNextActionsRequest, and the fields are feed_request_context (number 25) and feed_cursor_direction (number 26).

    FeedRequestContext feed_request_context = 25;
    FeedCursorDirection feed_cursor_direction = 26;
  

  — recsys.proto (code), 2026-10-09

• The request-context enum distinguishes 14 ways a feed request can arise verified.

  • The enum is named FeedRequestContext.
  • It includes app launch (LAUNCH), return to foreground (FOREGROUND, FOREGROUND_TRUNCATE), pull to refresh (PULL_TO_REFRESH), manual refresh (MANUAL_REFRESH), and screen navigation (NAVIGATE).
  • It also includes viewport-based refresh, polling, background fetch, filling a timeline gap (GAP), right after sign-up (SIGNUP), viewing one's own thread, AUTO, and other.

• The cursor-direction enum distinguishes the first request, fetching new posts at the top, scrolling down to fetch more, and a gap verified.

  • The enum is named FeedCursorDirection, and its four values are INITIAL, TOP, BOTTOM, and GAP, in that order.

• Both enums had been defined in the proto file since a previous commit but were not used in any message. This diff added only two field lines verified.

• As of this commit, no code that reads or fills these values exists anywhere in the public tree verified.

  • A grep over the whole repository finds the two names only in two copies of the proto (one for Python, one for the Rust serving crate).

• The default home ranker preset is built by merging H100 overrides into a base configuration verified — phoenix/xrex/configs/xrecsys.py:324-345, 427-432.
  • The preset is named home_direct_packed. It merges _H100_OVERRIDES into the base configuration _home_direct_packed_base().
• The per-device batch rose from 256 to 512, and a setting that splits the batch into 2 microbatches was added. The unit computed at once is the same 256 users, but the number of users per gradient step doubled verified.
  • The settings are named bs_per_device and num_microbatch=2.
  • A microbatch approach splits the batch of one step into several pieces, computes them in order, and then sums the gradients. It allows a large batch within the memory limit.
• Expert parallelism was reduced from 256 to 128 verified.
  • The setting is named ep.
  • Expert parallelism is a sharding approach that places the experts of an MoE model across several devices.
• Four options were turned on verified.
  • Asynchronous embedding lookup (use_async_emb)
  • Overlapping host work (overlap_step_host_work)
  • Removing empty candidate slots (seqpack_drop_empty_candidates)
  • An H100-specific recomputation policy (SAVE_H100_QKV_ATTN_FFN)
    • A recomputation policy (remat policy) decides which intermediate values to save during backpropagation and which to recompute.
• The learning rate of 7.1e-4 and the Muon optimizer settings are mostly unchanged, and only one option was added that shards the Newton-Schulz computation in units of 8 verified.
  • The option is named muon_ns_shard_group_size=8.
  • The Newton-Schulz computation is the iterative calculation Muon uses to approximately orthogonalize the gradient momentum.
• The GB300 preset did not change verified.

Sequence packing is a training technique that concatenates the sequences of several users with different lengths into one long array to reduce padding waste.

• The old packing reserved a fixed number of candidate slots per user, so the empty slots of users with few candidates also entered the attention computation. The new layout gathers only the candidates actually filled, rounded up to a multiple of 16, into a "candidate region" at the end of the sequence verified — phoenix/xrex/data/recsys/sequence_packing.py:171-203, 579-754.

• The candidate token budget per user has two levels, 32 and 128, and the needed level is chosen at each step verified — phoenix/xrex/train/trainer_recsys.py:172-195, 291-292, 404-470.

  • The setting is named seqpack_candidate_tokens_per_user.
  • The whole training process agrees on the maximum needed at each step through a distributed KV store and then uses the smallest level that exceeds that value.
  • To keep the total length constant, the mean of the history-length distribution (default 510) is reduced by as much as the budget grew.

• If even 128 is not enough, candidates in the later slots within a user are left out of that batch's training verified.

  • The number left out is logged as train/seqpack_dropped_candidate_slots.

• A new FlashAttention kernel dedicated to the candidate region was added. Each candidate token attends only to its own user's history span, and the kernel runs only on H100 (SM90) verified — phoenix/xrex/cutedsl/ranker_candidate_attention_fa4.py:31, 295.

  • The kernel is named ranker_candidate_attention_fa4. It is 369 lines of code written in CuTe DSL.

  if arch != 90:
      raise NotImplementedError("ranker candidate attention: only SM90 (H100) is supported")
  

  — ranker_candidate_attention_fa4.py (code), 2026-10-09

• The cron mirror of home-mixer (the service that assembles the For You feed) changed only its sync time, and no parameter values changed verified.
  • The cron mirror is a file that syncs and publishes production parameter values every day, and here it is home-mixer/params/param.rs.
  • The new sync time is 2026-10-08T16:00:35Z.
• A field for the list of mentioned users was added to the post type of grox (the content classification service). No classifier reads this field yet verified — grox/core/data_loaders/data_types.py:711, 862-866.
  • The type is named Post, and the field is mentioned_users.

• The probability of a reaction differs for the same user right after opening the app versus after scrolling deep into the feed, so these values are likely to be used as context features in a later stage inferred. The only evidence is that the fields were added to the request message.
• B and C are training-efficiency changes that do not alter the model structure or loss, so we infer they have no direct effect on serving results inferred.
• However, in batches that exceed the budget some candidates are left out of training, so the training data distribution may differ slightly inferred.

What to check next

Source check notes

Apart from the one X commit, there was no new source to fold in.

• X: since 2026-10-09 there is 1 commit, cb45b55, and no release.
• Meta: the latest post on engineering.fb.com is still "NTS: Authenticated Time at Meta" from 2026-10-06, which is unrelated to feeds. The latest post on ai.meta.com/blog is from 2026-07, so nothing is new. The Threads following-first re-tuning and Dear Algo, which came up in the WebSearch cross-check, are already in services/threads.md.
• Netflix: the latest post in the netflixtechblog.com RSS is from 2026-09-25, so nothing is new. The recommendation page on research.netflix.com did not render its list, so I opened the publications archive instead, and it has no items after 2026-10-09.
• arXiv cs.IR: 30 papers were parsed, and 0 passed the acceptance criteria. Two came close.
  • 2610.10920 is an offline LM-based evaluation of where to place recommendation modules on an e-commerce search page. No affiliation is listed, and there is no deployment claim.
  • 2610.10441 (CrossWeave) is a bridging system that shows posts from other communities in a panel beside the feed. It is an academic prototype.