What is Thunder vs Phoenix retrieval?
They are the two services that find candidate posts for your feed, and they cover opposite territory. Thunder retrieves in-network posts — content from the accounts you actually follow, fetched by your following list. Phoenix retrieves out-of-network posts — relevant content from people you don't follow, found by similarity. Thunder is how you see your follows; Phoenix is how you discover, and how you get discovered by strangers. They run as separate sources in the pipeline, and which one surfaces your post determines the rules it then competes under.
Both feed the same pipeline, but they answer different questions. Thunder asks "what did the people you follow post?" Phoenix asks "what, from the whole network, would this person engage with?" Understanding which one carries your post explains a lot about who sees it.
Thunder: your follow graph
Thunder is the in-network source. It takes your following list and fetches posts from exactly those accounts:
32let following_list = &query.user_features.followed_user_ids; ... 37following_user_ids: following_list.iter().map(|&id| id as u64).collect(), ... 46.get_in_network_posts(request)
Thunder is the in-network source: it fetches posts via get_in_network_posts, keyed on the viewer's followed_user_ids — i.e. content from the accounts the viewer follows.
The method name says it: get_in_network_posts, keyed on
followed_user_ids. If someone follows you, Thunder is the path your post takes to
reach them. This is the reliable channel — your true followers, served your content directly.
Phoenix: the wider network
Phoenix is the out-of-network source. Critically, it only runs when the request is not restricted to in-network:
63fn enable(&self, query: &ScoredPostsQuery) -> bool { ... 66 && !query.in_network_only 67 && !query.has_cached_posts }
The Phoenix source is the out-of-network retrieval path: its enable() requires that the request is not in_network_only, so it contributes candidates from beyond the viewer's follow graph.
Phoenix is the Grok-based ranker's retrieval half — the two-tower model that narrows millions of posts to a relevant few. It's how your post reaches people who don't follow you, and it's where the out-of-network handicap applies. Discovery flows through Phoenix; it's also where the climb is steepest.
Signal by signal
| service | territory | what it means for you |
|---|---|---|
| Thunder | In-network — your follows | Your reliable reach. Followers are served your posts directly through this path. |
| Phoenix | Out-of-network — discovery | How strangers find you. Higher ceiling, steeper climb (the OON multiplier applies here). |
What the code doesn't say
The blend ratio. How many in-network vs out-of-network candidates end up in a given feed, and
how that mix is tuned, depends on parameters and selectors not fully exposed in the release. We
can show the two sources exist and what each retrieves; the exact proportion in your timeline is
not a number this code provides.
The numeric values of the current weights are not included in the open-source release: weighted_scorer.rs references a params module (e.g. p::FAVORITE_WEIGHT, p::REPLY_WEIGHT) whose values are not present anywhere in the published repository.
What to do with this
Grow both channels deliberately. Thunder reach scales with real followers who want your posts — so follower quality matters, not just count. Phoenix reach scales with making content relevant and engaging enough to clear out-of-network retrieval and survive the handicap. The two strategies are different, and knowing which channel a post is winning or losing in is exactly what xDoctor's reach diagnostics surface.