Does X infer my demographics or gender for ranking?

This is one of the most charged questions people ask about the algorithm, and it is exactly the kind where the difference between "the code can do this" and "the code does this to you right now" matters enormously. So this page sticks tightly to what the released code actually shows — gating and all.

The demographics hydrator

A query hydrator exists that fetches a viewer's demographics and attaches them to the ranking query. The whole thing is small enough to read directly:

14fn enable(&self, query: &ScoredPostsQuery) -> bool {
15    query.params.get(EnableContextFeatures) || query.is_shadow_traffic
16}
17
18async fn hydrate(&self, query: &ScoredPostsQuery) -> Result<ScoredPostsQuery, String> {
19    let demographics = self.client.fetch(query.user_id).await?;
20    Ok(ScoredPostsQuery { user_demographics: demographics, ..Default::default() })

The first function is the one that matters most. enable returns true only when a feature parameter (EnableContextFeatures) is switched on, or when the request is shadow traffic — internal traffic used for testing and measurement that never reaches a real timeline. On an ordinary production request with that flag off, this hydrator does not run. The capability is built; whether it is active is a switch, and the released code shows it gated.

The inferred-gender hydrator

A second, more specific hydrator attaches an inferred-gender label. It reads from a store of existing predictions, and — only for brand-new accounts — calls a live prediction service:

34async fn hydrate(&self, query: &ScoredPostsQuery) -> Result<ScoredPostsQuery, String> {
35    let result = match self.mh_client.fetch(query.user_id).await? {
36        Some(r) => Some(r),
37        None if is_new_user(query.user_id) => self.grpc_client.predict(query.user_id).await?,
38        None => None,
39    };
44    user_inferred_gender: result.as_ref().and_then(|r| InferredGenderLabel::try_from(r.gender_label).ok()),
45    user_inferred_gender_score: result.and_then(|r| r.prediction_score),

The shape is precise: a discrete InferredGenderLabel plus a prediction_score — a confidence number. For an existing account the label comes from a stored prediction; for an account created the same day (is_new_user, defined as zero days since creation) the code calls a gRPC gender-prediction service to generate one on the spot. And like the demographics hydrator, it is gated — it runs only when EnableInferredGenderHydration is on, or on shadow traffic.

What this is, and what it isn't

What it is: clear evidence that X has built the infrastructure to make a viewer's demographics and an inferred gender part of the context the ranker sees, including a live predictor for new accounts. That infrastructure is in the open-source release, named plainly.

What it isn't, from this code alone: proof that your feed today is ranked using your inferred gender. Both paths sit behind feature flags and a shadow-traffic condition. The honest reading is "the capability is real and shipped, its activation is a switch, and the released code does not show that switch's production state" — not "X is secretly gendering everyone." The distinction is the whole point of how this library is sourced.

Signal by signal

What the code doesn't say

What to do with this

Mostly: know it exists, and treat confident claims in either direction with suspicion. The people insisting X definitely genders your feed and the people insisting it definitely doesn't are both reaching past the code. xDoctor's diagnostics work from signals you can actually see and change — your content, your engagement, your reputation markers — rather than from inferred traits you can't observe or control. This page is here so that when the topic comes up, you can check the source instead of the folklore.