How to grow on X, from the published engagement weights

Q: Are likes the main For You signal in the 2026 open-source code?

Not in this tree. favorite is 0.5. The “likes are the primary sort key” sentence belonged to a demo script that is no longer in the repo. Reply’s coefficient is 10× favorite’s, and 40× on a mutual’s original (20 / 0.5). That ratio is not “one reply equals ten likes,” because both numbers scale probabilities.

Q: Do negative actions wipe out a post?

notinterested is −47.52, muteauthor is −58.8, blockauthor is −31.2, and report is −234. The code’s own comment is that those coefficients are large because the baseline probabilities are tiny. Coordinated reports from people who are not served the post in Home do not enter this prediction. The playbook does not support a fixed “one report cancels N likes” rule.

“How to grow on X” is answerable from this tree only as a list of heads with large published coefficients. These are default weights, not a ranking of what gets the most reach, and not a promise of impressions. Each one multiplies a predicted probability, or a predicted duration, for a specific viewer. The table is from X_ALGORITHM_BOOST_PLAYBOOK.md, copied from home-mixer/params/param.rs in xai-org/x-algorithm at commit cb45b55. The file’s sync stamp is 2026-10-08T16:00:35Z.

The writing consequences the playbook draws from the same table: an original to mutual followers (reply weight 20, and no 0.75 reply discount), a line worth copying (weight 20), quoting (5), or sending in a DM (5), a reason to follow (4), and one post per conversation because dedup and author diversity (second post ×0.625) both shrink a burst. A like is 0.5. None of those ratios is “one reply equals N likes.” A single draft can be scored in the browser at tweetfactory.sh/score; that page is a heuristic, and this table is the ranker.

Home-mixer asks vm-ranker to recompute the sum (compute_value_model: true). The same literals live in vm-ranker/params.rs, except PostUnexploredWeight, which is 0.015 in home-mixer and 0.02 in vm-ranker. When vm-ranker’s feature-switch config resolves, that copy produces the served score. If vm-ranker has no ranking config, or the RPC fails, home-mixer serves its in-process sum instead, and that path turns author diversity and the in-network reply/repost discount off.

Published default weights

Head	Default	Kind
`share_via_copy_link`	20.0	probability
`reply`	5.0	probability. +15.0 on an original post from a mutual follow
`share_via_dm`	5.0	probability
`quote`	5.0	probability
`follow_author`	4.0	probability
`share`	2.0	probability
`retweet`	1.0	probability
`favorite`	0.5	probability
`click`	0.3	probability
`open_link`	0.2	probability
`video_open`	0.07	probability
`photo_expand`	0.05	probability
`dwell`	0.05	probability. The bidirectional dwell boost shipped at 0.0
`quoted_click`	0.05	probability
`post_unexplored`	0.015	probability. In-network only, unless `PostUnexploredIncludeOutOfNetwork` (default false)
`click_dwell_time`	0.4	continuous, predicted seconds-class value
`dwell_time`	0.004	continuous
`profile_click`	0.0	off
`vqv`	0.0	off. Also gated: video longer than 10 seconds and a viewer with fewer than 10,000 followers
`quoted_vqv`	0.0	off
`video_continuation`	0.0	off
`user_video_continuation`	0.0	off
`profile_visit_secs`	0.0	off
`not_interested`	−47.52	probability
`block_author`	−31.2	probability
`mute_author`	−58.8	probability
`report`	−234.0	probability
`not_dwelled`	−0.02	probability

There is no bookmark head in xai-value-model/phoenix_scores.rs.

favorite at 0.5 is a real but small term. The older “likes are the primary sort key” line came from a demo file, phoenix/run_pipeline.py, that is not in this tree. The August 13, 2026 release replaced that demonstration model with training code and these published weights.

After the sum

Author diversity (diversity_multiplier in xai-value-model/scoring.rs). Posts from one author are ordered by score. The k-th extra post is multiplied by (1 − floor) × decay^k + floor. vm-ranker/params.rs defaults: enabled, decay = 0.5, floor = 0.25.

Extra posts already ahead (k)	Multiplier
0 (first)	1.00
1	0.625
2	0.4375
3	0.34375
large k	approaches 0.25

This is one viewer’s candidate pool for one request. It is not a daily posting cap.

Out-of-network factor (oon_applies):

An account the viewer does not follow: × OonWeightFactor 0.75.
An account the viewer follows, when the post is a reply or a repost: also × 0.75, because EnableOonRescoreForInNetworkRepliesRetweets defaults true.
An original post from an account the viewer follows: × 1.
Topic-page requests use TopicOonWeightFactor 0.5.
NewUserOonWeightFactor 0.00001 applies only when account age is under NewUserAgeThresholdSecs. That threshold’s default is 0, so the path does not fire on the published default.

Mutual-follow reply boost. An original post (not a reply, not a repost) whose author the viewer mutually follows uses reply weight 5.0 + 15.0 = 20.0 (ValueModelWeights::reply_weight_for). The dwell boost parameter exists and defaults to 0. The history of that July 2026 rollout is docs/BIDIRECTIONAL_BOOST_CHANGE.md in the x-algorithm repo.

Cold start can lift a post toward slots 15–16 when it has under 200 impressions, is younger than two hours (ColdStartMaxPostAgeSecs 7200), and the author has under 50,000 followers. Thompson sampling is on. The playbook’s reading: this is a position lift for unscored inventory, not a velocity multiplier on likes.

DPP then reorders the top of the pool so near-paraphrases sit further apart, even when each post scores well alone.

Video and profile terms that are products rather than raw heads (video_continuation, user_video_continuation, profile_visit) ship at weight 0 in the vm-ranker params and in home-mixer’s in-process scorer.

What the coefficients suggest, and what they do not

The playbook’s “worth writing toward” list follows from these coefficients. It is still a prediction about a specific viewer. None of it is a guaranteed multiplier on impression count.

An original post to people who follow you back skips the 0.75 reply/repost discount, and the reply head they are scored with is 20 instead of 5. A reply you send does not receive that boost.
Quote, copy-link, and DM-share are the large positive probability heads (5, 20, and 5).
follow_author at 4.0 is eight times favorite.
A reply is aimed at people who already follow you. Out-of-network replies are filtered before scoring. See why replies stay in network.
One strong post per conversation survives dedup.
A second post from you already in that viewer’s pool is ×0.625.

There is no Tuesday-morning constant in the repo.

FAQ

How do you grow on X according to the open-source weights?

Write originals that a mutual follower can reply to, quote, copy as a link, or follow you for. Those heads are 20 (reply, on a mutual’s original), 20 (copy-link), 5 (quote), 5 (DM share), and 4 (follow). Keep one strong post per conversation. Stay inside the 48-hour age filter. The code does not publish an impression multiplier for doing any of that.

What does the X algorithm reward?

On the published defaults, the largest positive probability weights are copy-link share (20), reply (5, or 20 on an original from a mutual), DM share (5), quote (5), and follow (4). A like is 0.5. Binary dwell is 0.05. Click-dwell’s continuous weight is 0.4. Report, mute, block, and not-interested are large negative coefficients because those events are rare.

Are likes the main For You signal in the 2026 open-source code?

Not in this tree. favorite is 0.5. The “likes are the primary sort key” sentence belonged to a demo script that is no longer in the repo. Reply’s coefficient is 10× favorite’s, and 40× on a mutual’s original (20 / 0.5). That ratio is not “one reply equals ten likes,” because both numbers scale probabilities.

Do negative actions wipe out a post?

not_interested is −47.52, mute_author is −58.8, block_author is −31.2, and report is −234. The code’s own comment is that those coefficients are large because the baseline probabilities are tiny. Coordinated reports from people who are not served the post in Home do not enter this prediction. The playbook does not support a fixed “one report cancels N likes” rule.