Why Your Post Gets Early Reach Then Dies

1. Early Reach Can Come From Strong Initial Relevance

When a post is first considered for users whose interests align closely with it, the model may predict strong engagement opportunities. Phoenix uses engagement history to build user context and retrieve potentially relevant candidates. (GitHub) If many of the initial viewers are highly interested in the topic, the post can gain strong early distribution.

2. The First Audience Isn't the Entire Audience

As recommendations expand, the system can encounter users with different interests (First audience: AI enthusiasts, developers, tech creators → Strong relevance; Later audience: general users, different interests → Lower topic relevance). The same post can therefore have different recommendation potential for different viewers. The retrieval system uses user engagement history to create a user representation and searches for candidates that match that representation. (GitHub) Strong performance with one audience doesn't guarantee equally strong performance with the next audience.

3. X Predicts Multiple User Actions

Phoenix doesn't simply ask whether someone will like the post. The open-source ranking model predicts multiple actions, including Like, Reply, Repost, Quote, Click, Profile click, Share, Dwell, Follow, Not Interested, Block, Mute, Report, and Dwell time. (GitHub) These predictions contribute directly to ranking.

4. Existing Likes Don't Guarantee Future Reach

Suppose your post gets 5,000 likes. That is evidence of what happened, but the ranking model is concerned with predicted behavior for candidates and users. The open-source implementation produces separate probabilities for many actions rather than using one accumulated engagement number. (GitHub) Therefore, 5,000 existing likes ≠ guaranteed future recommendations. A post can have impressive historical engagement while becoming less competitive for additional users.

5. The Candidate Pool Keeps Changing

Your post is competing with other candidates. Initially, your post ranks at 0.80 against Post B (0.74) and Post C (0.70). Later, new competitive candidates arrive (Post B: 0.89, Post C: 0.86, Post D: 0.84), while your post remains at 0.80. Your post didn't necessarily get worse; the competitive environment changed. The open-source pipeline retrieves candidates, ranks them, and selects the top candidates. (GitHub)

6. Ranking Is Based on Predicted Actions

The public repository's ranking model produces action probabilities and ranks candidates based on predicted engagement. (GitHub) The runnable example demonstrates a weighted ranking calculation using predicted actions minus negative feedback. The exact weights and production behavior should not be treated as a universal creator-facing formula.

7. Negative Feedback Can Change the Outcome

The model also predicts negative actions such as Not Interested, Block author, Mute author, and Report, which are explicitly identified as negative-feedback indices in the open-source code. (GitHub) Positive predicted actions minus negative predicted actions form score pressure. So a post doesn't need to stop receiving likes for its recommendation potential to decline; its predicted overall value for new viewers can change.

8. Some Users Have Already Seen the Post

The candidate pipeline includes filters for previously seen posts and previously served posts. (GitHub) Early reach may consume many of the easiest recommendation opportunities (User A, B, C, D see it and are no longer fresh opportunities). The post may still be eligible for other users, but the pool of new viewers is changing.

9. The Post Can Reach a Natural Audience Boundary

Imagine your post is about a very specific programming problem. It might quickly reach developers, ML engineers, and AI researchers. But once the system moves toward broader audiences (general technology users, general users), the probability that a random viewer will find the topic useful may decrease. This doesn't mean the post became worse; it means its potentially relevant audience may be narrower than the total platform audience.

10. Out-of-Network Reach Can Expand Quickly Then Slow

Phoenix Retrieval can discover posts outside the viewer's existing network through similarity-based retrieval (Your followers → initial engagement → out-of-network retrieval → relevant non-followers → more recommendations). But that doesn't mean unlimited expansion: eventually, fewer suitable users may remain, competing posts may rank higher, the post may become less relevant to additional users, or filtering/selection may reduce opportunities. Out-of-network discovery can create an early spike without guaranteeing a long tail.

11. Author Diversity Can Affect Continued Distribution

The open-source system contains an Author Diversity Scorer designed to diversify authors within a feed response. (GitHub) If a user has several strong candidates from you (Post #1, #2, #3, #4), the system doesn't necessarily want the feed to become dominated by one creator. Author diversity can therefore attenuate repeated-author scores, meaning a strong post doesn't automatically get unlimited feed space.

12. Age Is Part of Candidate Filtering

The candidate pipeline includes an AgeFilter. (GitHub) That establishes that post age is considered during candidate filtering. However, the existence of an age filter does not prove a universal rule such as “Every post dies after exactly 6 hours.” The public architecture doesn't give creators a universal lifetime for recommendation.

13. A Post Can Be Retrieved but Not Selected

The Phoenix pipeline first retrieves candidates and then ranks them (Retrieval → top-K candidates → ranking → display selection). (GitHub) A post can remain a candidate while no longer being strong enough to make the final selection. Therefore, “X considered my post” and “X showed my post” are not the same thing.

14. The Ranking Model Uses Candidate Isolation

The open-source architecture has an interesting design detail: during transformer inference, candidates cannot attend to other candidates; they attend to the user context and themselves. (GitHub) This means the model's individual candidate prediction isn't simply “This post is ranked below that post because that post was in the same model batch.” Instead, the model predicts candidate engagement based on the user's context and the candidate itself. The candidates still compete during the subsequent ranking and selection process.

15. The Post May Stop Being a Strong Retrieval Candidate

There are actually two opportunities to lose distribution: Retrieval (the system needs to retrieve the post as potentially relevant) and Ranking (the post needs to rank strongly enough after retrieval). The open-source pipeline separates these stages. (GitHub) A post can lose recommendation opportunities at either stage.

16. Early Engagement Is a Signal, Not a Contract

If your post receives 1,000 likes in the first hour, that tells the system something about observed user behavior. But it doesn't create a contract saying “This post must now receive another 100,000 impressions.” The public architecture doesn't document such a guarantee; instead, the recommendation system continues evaluating candidates through retrieval, prediction, ranking and selection.

17. Why the Graph Can Look Like a “Kill”

A sharp change in reach (strong initial relevance → strong candidate score → many selections → more users exposed → different users / stronger competition → fewer selections → reach plateaus) can feel like a kill switch. But nothing in that sequence requires a manual stop decision.

19. What You Shouldn't Claim

The open-source code does not establish:

• ❌ Every post gets exactly 15 minutes of testing.
• ❌ Every post gets exactly 100 initial impressions.
• ❌ X gives a “second boost” after a specific engagement threshold.
• ❌ A post is automatically killed after a fixed number of hours.
• ❌ 100 likes unlock a specific reach tier.
• ❌ Replying to your own post automatically restarts distribution.
• ❌ Reposting your post automatically resets its recommendation lifecycle.

20. A Better Way to Understand the Early Spike

Instead of assuming X tested your post, liked it, and stopped it, use: Candidate retrieval → strong user relevance → strong predicted actions → high ranking → many selections → new audience → changing relevance & competition → fewer selections → reach plateaus. This model is much closer to the architecture X has made public. (GitHub)

21. What Creators Can Actually Learn

You can't control the exact moment a post stops receiving recommendations, but you can improve the probability of continued relevance:

• Make the audience clear: The system uses user behavior to find relevant candidates.
• Create content worth consuming: Dwell and dwell time are explicitly modeled. (GitHub)
• Give people reasons to interact: Likes, replies, reposts, clicks, shares and follows are modeled actions. (GitHub)
• Make content worth sharing: Sharing and reposting are separately represented.
• Avoid unnecessary negative reactions: Not Interested, mute, block and report are modeled as negative feedback. (GitHub)
• Don't depend on one engagement metric: The model predicts many actions rather than a single universal engagement value.