Speech recognition runs locally. LLM-assisted cleanup and analysis are optional, with provenance recorded in the output. The project is not a permanent knowledge base, voice lab, final video renderer, or publishing system.

Boundaries

• Inputs may be local videos or public links.
• Outputs include transcripts, subtitles, structured knowledge, and downstream briefs.
• Original media and private instances stay local by default.

The code does not answer with an engagement scoreboard. What the new system actually does is predict, based on a given user’s past behavior, which actions they might take after seeing a post — and then combine those predictions into a score.

Which means the thing a creator optimizes is not one kind of engagement count, but this: whether the content reaches the right people, and whether those people take a real action that matches it.

This note is based on commit b089ce64 of X’s official repository, dated 2026-08-17. The public code will keep changing and production carries experiment parameters, so what follows is a source snapshot you can check again — not a permanent set of platform rules.

How does a post reach the For You feed?

The published architecture splits candidates into two main sources:

1. In-Network: accounts you already follow, served recent content by Thunder.
2. Out-of-Network: accounts you do not follow yet, surfaced mainly through Phoenix Retrieval and SimClusters.

Those candidates enter Home Mixer, where they pass through filtering, feature hydration, and Phoenix ranking. Based on the viewer’s recent interaction history, Phoenix predicts probabilities for each candidate across many actions: favorite, reply, retweet, share, dwell, follow the author — and also not-interested, block, mute, and report.

The official README states the core calculation as:

Final Score = Σ (weight_i × P(action_i))

After ranking, the system still applies author diversity decay, an out-of-network discount, new-author exploration, and further reordering. Duplicates, already-seen posts, content past an age threshold, and anything caught by visibility rules can also be filtered at various stages. The full pipeline can be checked against the official System Architecture and Scoring and Ranking sections.

The older system read more like an engineering stack of many candidate services, large aggregated feature sets, and layered rankers. The new one keeps its filters and tunable parameters, but Phoenix moves “understand the user’s behavior sequence and predict the next action” much closer to the center.

Weights are not an exchange rate for engagement

Among the current published defaults, a few parameters draw attention:

These values come from home-mixer/params/param.rs at the pinned commit.

Putting a few of them back into the source makes it easier to see that they are simply defaults of configurable parameters:

param!(FavoriteWeight, f64, "rust_home_mixer_favorite_weight", 0.5);
param!(ReplyWeight, f64, "rust_home_mixer_reply_weight", 5.0);
param!(
    BidirectionalFollowReplyWeightBoost,
    f64,
    "rust_home_mixer_bidirectional_follow_reply_weight_boost",
    15.0
);
param!(RetweetWeight, f64, "rust_home_mixer_retweet_weight", 1.0);
param!(
    ShareViaCopyLinkWeight,
    f64,
    "rust_home_mixer_share_via_copy_link_weight",
    20.0
);
param!(ReportWeight, f64, "rust_home_mixer_report_weight", -234.0);

The easiest misreading is to treat 20, 5, and 0.5 as an exchange rate for real engagement. Comments in the source reject that interpretation explicitly: a weight multiplies a probability or continuous value the model predicts for the current viewer, not an interaction that already occurred. Reports are much rarer than likes, so that prediction needs a far larger absolute weight before it can affect the final score at all. The calculation itself can be checked in ranking_scorer.rs.

The mutual-follow reply boost deserves the same care. The current code adds reply-prediction weight for original posts from authors you mutually follow, but X’s own change log also documents that the parameter went through A/B testing and several adjustments. It proves real relationships are part of ranking. It does not prove that bulk mutual-following buys reliable distribution.

The boost applies only to original posts from mutually followed authors; replies and retweets never enter that branch:

fn bidirectional_boost_eligible(candidate: &PostCandidate) -> bool {
    candidate.in_reply_to_tweet_id.is_none()
        && candidate.retweeted_tweet_id.is_none()
        && candidate.is_mutual_follow_author == Some(true)
}

fn reply_weight_for(&self, candidate: &PostCandidate) -> f64 {
    if self.bidirectional_follow_reply_weight_boost != 0.0
        && Self::bidirectional_boost_eligible(candidate)
    {
        return self.reply + self.bidirectional_follow_reply_weight_boost;
    }
    self.reply
}

So what is more likely to be recommended?

The code offers no viral template, but it does rule out some wrong directions and support a few sturdier judgments.

1. Make it clear — to the system and the reader — who the post is for

Phoenix uses the viewer’s behavior history to model interest, then judges whether a candidate is relevant. For a creator, consistency does not mean writing the same topic every time. It means the content keeps serving one recognizable group of people and problems.

If an account discusses AI tooling today, retweets an unrelated joke tomorrow, and jumps to an unfamiliar field the day after, individual posts may still get recommended — but the account will struggle to build continuous, legible audience feedback.

2. Offer natural high-intent actions

Replies, DM shares, copy-link shares, and following the author all enter scoring. Rather than mechanically asking for likes and retweets at the end of a post, the more useful question is: is this worth saving somewhere else, sending to a colleague, or answering with your own experience?

A tutorial can leave executable steps. A source analysis can leave accurate links and stated boundaries. An opinion piece needs to give the reader a specific judgment they can respond to. The action should follow from the value of the content, not be squeezed out by a call-to-action formula.

3. Do not treat conflict engagement as a growth shortcut

The system also predicts negative actions — not interested, block, mute, and report — and the visibility system independently handles spam, safety labels, and other restrictions.

Manufacturing arguments may produce short-term replies, but nothing in the code supports “all engagement is good engagement.” If content attracts the wrong audience, the model can just as easily learn that it tends to generate negative feedback from similar users.

4. Avoid publishing near-identical content in quick succession

The current defaults enable author diversity decay: when the same author appears repeatedly, scores for later candidates are progressively reduced, down to a floor ratio. Out-of-network content carries an additional discount, and the age filter threshold listed in the README is 48 hours.

These mechanisms support a plain judgment: important content needs timely, real feedback, but publishing several near-identical posts in a row does not simply stack impressions. The code also offers no universal “best time to post.”

How I would verify any of this

Source code explains mechanisms; it cannot replace your own account data. I would rather turn this into a two-week observation than rewrite an entire content strategy today:

1. Before publishing, settle on one primary reader question per post.
2. Mark the one action you hope follows naturally: reply, share, profile visit, or follow.
3. Record what the platform actually exposes — impressions, replies, shares, profile visits, new follows — and leave missing data unknown.
4. Separate content types: build logs, tutorials, source analysis, and opinion pieces should not be compared against each other.
5. After two weeks, compare which posts produced deeper actions, then decide whether topic, structure, or cadence needs to change.

This is not a growth guarantee. It only replaces “I heard the algorithm likes X” with “here is what the public code supports, and here is whether my own data agrees.”

Three judgments to keep

• X’s published weights describe personalized predictions, not a points table for actual engagement.
• High-weight actions are worth understanding, but matching content to audience matters more than chasing any single number.
• The public repository, production experiments, and your own account results are three different layers. Source code helps you form hypotheses; only real data settles them.

I did not come away from this with a better posting formula. If anything, I am more certain of something simpler: write for specific people, give them something worth answering and worth passing on, then check the judgment against data. The algorithm mostly makes that process more personalized.

Primary sources

• X For You Feed Algorithm
• Phoenix Recommendation System
• Home Mixer default parameters
• Ranking Scorer

Moonment is a public entry point, not another content machine that needs constant feeding. It collects work that has already happened: open-source projects, human-reviewed notes, and experiments that can be checked again.

Three editorial principles

1. Reality first. No promised outcomes and no historical data used to fill a current unknown.
2. Methods public, instances isolated. Reusable methods may enter the public record; private assets and identity configuration stay behind their boundaries.
3. Make it returnable. Notes should preserve sources, conditions, and the next move—not only the conclusion.

The site follows the same rule: real content before more structure, clarity before scale.