X ranking predictions: history, probabilities and time | Gyo
How X predicts what you will do
X’s prediction model turns reader history and candidate features into action estimates and time-valued outputs. Here is how those estimates reach the ranking formula.
Gyo
The ranking weights leave out the hardest part of the calculation: estimating what you will do. A copy-link coefficient can be large while the chance of you copying a particular link is tiny.
For each candidate, Phoenix can return several predicted actions and continuous values. Those outputs become inputs to the value model. They describe a possible response by a particular reader in context; they are not the post’s accumulated likes or a universal quality rating.
The previous article followed posts into the candidate pool. The filtering article covered the checks before this scoring stage. Now we can fill in the missing half of the weight calculation: where its predictions come from, what the public training code teaches the model to estimate, and what remains unknown without the deployed model and data.
The same post, a different reader
Think about a post explaining a camera setting. One reader follows the author and often opens photography links. Another scrolls past most camera discussions. The public like count is identical for both readers, but the ranking request is not.
The scoring-sequence query hydrator requests an aggregated action sequence for the viewer, using a ranking-specific model type and configured aggregation and length settings. It stores the returned sequence and columnar representation in the query.
This is separate from the retrieval sequence in part three. Both involve history, but the code makes different requests for different jobs. We should not assume that the history used to find a post is identical to the history used to score it.
The prediction-request builder assembles candidate records alongside viewer, client and device context. Its final assembly step attaches the scoring sequence and available columnar bytes. PhoenixScorer also chooses a product surface according to whether the request is in-network-only.
That gives the earlier camera example a concrete basis. The model can receive different history and relationship context for the same post. We cannot infer either reader’s exact probability from those fields alone, but we can see why a single global post score would leave out much of the request.
What the candidate brings with it
A candidate is more than its text and public like count. The conversion to includes post and author identity, quote and reply relationships, follow status, available engagement counts, language, media flags, video duration, semantic IDs and content features. Some absent values become zero or false; others remain optional.
FAQ
Does X rank posts by their total likes?
Public engagement counts can be candidate features, but the ranking coefficients examined in this series apply to predicted actions or continuous values, rather than directly multiplying accumulated likes. The viewer’s history and request context are separate inputs.
Do the predicted action probabilities add up to 100%?
Not necessarily. The published action-loss helper uses multi-label binary targets. A reader can take several actions on one post, so these outputs are not one mutually exclusive probability distribution over all actions.
Is predicted dwell time a probability?
A time-valued prediction has units and a configured target and restoration process. Some normalized continuous heads use sigmoid, so a number between zero and one does not by itself establish that the output is an event probability.
Can the open-source model reproduce my live X predictions?
The public code exposes model and training behavior, but the training guide does not include a pretrained production checkpoint. Reproducing a live prediction would also require the relevant reader inputs, feature data and serving configuration.
TweetInfo
For a repost, this conversion uses the original post and author IDs while carrying reposting information in separate fields. A quote has its own related IDs and quoted-content features. These relationships survive into the request rather than being reduced to one generic “post” label.
There are two distinct claims to keep apart here. Public interaction counts can be input features. The final value model, however, does not simply multiply those counts by the action coefficients from the first article. It combines predictions produced farther down the path. Counts may inform a prediction without being the quantity that the coefficient directly multiplies.
Nor does a request field disclose its importance. Finding follower count or a language field in a structure does not establish a fixed bonus, a penalty, or a percentage of the final score. That would require following its actual use through the deployed feature and model configuration.
History becomes a model representation
The repository includes the ranking model itself, not just a client that calls an inaccessible service. In the model’s embedding construction, history actions are converted into embeddings alongside history post and author representations. Candidate representations and contextual features are prepared for the transformer as well. The implementation has multiple configuration-dependent paths, including optional multimodal inputs and packed layouts.
An embedding is a numerical representation the model can learn to use. The useful idea is that an interaction has both an object and an action: which post was involved, who wrote it, and what the viewer did. The model does not have to treat every occurrence of a post in history as the same kind of evidence.
That is enough to explain the role of history without inventing a rule such as “three photography likes classify you as a photographer.” The code does not expose a little checklist of interests with thresholds that simple. It prepares representations, processes them through learned layers, and produces outputs.
The learned parameters matter. Reading the architecture tells us which calculations are possible and how information is arranged. It does not reveal the response of the model serving a particular request unless we also have the relevant checkpoint, input data and configuration.
A like and a reply are separate predictions
The value-model score structure has separate fields for actions such as favorite, reply, repost, copy-link share, follow, not-interested, mute, block and report. It also has fields for time-valued outputs.
These are not mutually exclusive choices. A reader can open a post, stay with it, like it and reply. The training code reflects that distinction: its multi-label action loss applies sigmoid binary cross-entropy to the action logits, with masks and optional example weights. It is not one softmax distributing a single unit of probability across “like,” “reply,” “repost” and all the other actions.
In plain terms, a target can mark more than one action. The model is trained against the relevant binary targets, and invalid or excluded positions can be masked out. Different actions share a model, but the outputs do not have to sum to 100%.
A sigmoid turns a real-valued logit into a number between zero and one. For example, a logit of zero maps to 0.5; approximately −2.197 maps to 0.1. Those are mathematical examples, not probabilities measured from X. The model’s probability-and-label helper uses sigmoid outputs and groups action indices for metrics.
Training against an action target is different from guaranteeing that action. If a prediction were well calibrated at 10%, we would expect the action in roughly one tenth of comparable opportunities over many cases. It would not mean the system knew which single reader would be the one to act. Whether the deployed model achieves that calibration needs evaluation data; the existence of a probability output does not prove it.
Time spent is a different sort of output
“Will this person like the post?” has a yes-or-no target. “How much time will they spend?” has units. Mixing the two makes a score table much harder to interpret.
The model’s continuous-action configuration supports several loss types and activation choices. The basic continuous-loss helper clamps and normalizes the target, computes an error, and restores a prediction to its original scale. Other helpers handle thresholded binary targets and more elaborate continuous-value objectives.
The important distinction is the target, not just the activation function. A sigmoid can appear in a normalized continuous head as well as in an action-probability calculation. A value between zero and one is therefore not sufficient evidence that the output means “chance of an event.” The configuration, restoration step and units matter.
The public code also includes a threshold-based continuous estimator. It combines classification across thresholds with a restoration objective. We do not need to treat every loss option as active to see the point: the implementation can learn more than one kind of target, and reading all returned numbers as interchangeable probabilities would be wrong.
This is why the first article kept time-related terms separate from a table of action coefficients. A coefficient applied to predicted time is operating on a different quantity from one applied to a probability of sharing.
Candidates can share history without reading one another
One detail of the base ranker is easy to miss. Several candidates can be sent in the same request, but that does not mean they all attend to each other inside the prediction transformer.
The model distinguishes history, candidate and padding positions in its attention segment IDs. In the published variable-length attention kernel, the relevant mask allows attention to history keys or the token’s own position, rather than to arbitrary other candidate positions. Padding and other constraints are applied too.
For the candidate-isolated attention pattern, adding another candidate does not give the first one a new candidate to read. Both can use the reader’s history while their candidate representations stay separated in that attention calculation.
That is a property of this prediction mechanism, not a promise that the final feed is independent of its alternatives. A selector still compares candidates. Later value-model adjustments, optional page-level processing and limits can depend on the set being considered. The feed-assembly article follows those steps.
The returned prediction still has to become a score
PhoenixScorer builds the request, dispatches it, and maps returned outputs back to candidates using their original post IDs. It stores Phoenix scores, available backbone and slate-context values, request metadata and optional page-decode information. Those fields are not all the same score.
Its execution is conditional. Cached requests skip this scorer, and a kill switch can disable it. If the scoring sequence is absent, the method returns default update records instead of making the prediction call. A failed call produces error results. None of those branches is evidence that the reader genuinely has a zero probability of every action.
The later VMRanker prepares local weighted values and a ranking request, with fallback behavior if that service call fails. The distinction between a prediction, a weighted value and the score eventually used for selection remains important even after the model returns.
Here is a deliberately incomplete calculation using two coefficients from part one. Suppose all other contributions are set aside:
Invented candidate
Like probability
Copy-link probability
A
12%
0.1%
B
8%
0.4%
With a like coefficient of 0.66 and a copy-link coefficient of 20, A contributes 0.12 × 0.66 + 0.001 × 20 = 0.0992. B contributes 0.08 × 0.66 + 0.004 × 20 = 0.1328.
B comes out higher in this two-term example despite the lower like probability. No one has actually liked or copied either post in the example. We are comparing predicted responses before the outcome, and we have intentionally omitted the other terms and adjustments. This is the arithmetic the coefficient table was meant to illuminate.
What an author can learn from the prediction layer
There is a temptation to turn a list of model inputs into a list of tricks: increase this count, trigger that action, include this feature. The missing step is whether the change improves the relevant predictions for the readers who might receive the post, without creating costs elsewhere in the system.
The code supports a more grounded reading. Retrieval and ranking use reader context. Ranking distinguishes multiple possible actions and continuous values. Public counts can be features without being directly exchanged for weighted score. And the final result depends on both the model’s predictions and the serving path that consumes them.
That explains why one visible engagement number is a poor summary of the calculation. It does not establish a reliable posting tactic on its own. To test such a tactic, we would need actual outcomes under a design that separates its effect from changes in audience, retrieval and distribution.
We now have both sides of the weighting step: estimated actions and the coefficients applied to them. The feed-assembly article follows what happens after that—why a scored, selected candidate can still fail to become an item the reader sees.
Source and verification notes
Source-checked on November 3, 2026, against revision b220448, then upstream HEAD. The earlier articles pin their original snapshot and describe their comparisons separately. This article links the model, training helpers and serving callers at the newer revision so those different layers can be inspected together.
The training guide explains the synthetic-data workflow and the absence of a bundled pretrained production checkpoint. It explicitly separates a working training rehearsal from a production-quality claim. This review does not train or evaluate Phoenix, obtain private reader histories, or reproduce production probabilities.
The sigmoid values and two-term weighted example were recalculated independently. The attention discussion follows the cited segment construction and kernel mask; it is not a numerical equivalence test of every attention backend or configuration.
