Your posts compete with each other.

Each For You request runs one pipeline. Candidates are gathered and filtered, a model predicts what this viewer will do with each, the predictions become one value per post, the multipliers apply, a fixed number are selected, and ads are blended in.

The order matters more than any single constant. The repository’s README draws one ranking stage that applies the weighted sum, the author decay, the network discount and a new-author boost. In the code, that work is split between the home-mixer and a separate ranking service, and the diagram follows the code.

Two details carry most of what follows. The same-author rank k is computed on the base value, before the network multiplier. And every multiplier acts before the first cut, at 50.

Some paths skip the multipliers entirely. If the call to the ranking service fails, if a post is missing from its answer, or if the service has no configuration for the request, the served score is the home-mixer’s own, with no author diversity and no network multiplier. How often that happens cannot be known from the repository.

Inside one request, the ranking service sorts each author’s candidates by base value and multiplies the post in position k by

The author’s best candidate keeps its full score, D(0) = 1. The second is multiplied by 0.625, the third by 0.4375, the fourth by 0.34375, the fifth by 0.296875, and the curve flattens toward the floor of 0.25.

D(0) = 1 is all the protection the best candidate gets. It can still be discounted as out-of-network, removed by a filter, or miss the cut.

The decay and the floor are read at runtime through feature switches, with per-datacenter overlays that are not in the repository, and no first-party statement of their live values was found. They are repository defaults, and so is every number on this page drawn from them.

Take an older post, A, that is currently your strongest candidate for some viewer. It gets D(0) = 1. Now publish B.

• —If B scores lower for that viewer, B takes k = 1. A stays at k = 0, and its score does not change.
• —If B scores higher, B takes k = 0 and A drops to k = 1. A’s multiplier falls from 1 to 0.625.

That is the cleanest form of cannibalization in this code: a new post takes an older post’s rank, for the viewers who have both as candidates. Nothing in it runs on a clock.

“Stronger” means a higher base value for that viewer, a weighted sum of predicted probabilities, not quality in any global sense. Base values are computed per viewer, so the same two posts can rank one way for one follower and the other way for the next.

A lower score only costs A something if it moves A across a cut. Call τ the score of the last candidate that still makes this viewer’s top 50, and take the simplest case: both posts carry the same network multiplier, and competing scores are dense around the cut.

So A is pushed below the cut exactly when

This does not say the new post must be 1.6 times better. It says which older posts are exposed: those whose base value sits between the cut and 1.6 times the cut. Posts well above that survive the demotion, and posts below the cut were not being selected anyway.

In the example above, A falls from 0.80 to 0.50, so it is pushed out for any cut from 0.50 up to, but not including, 0.80.

D(k) never falls below 0.25, so author diversity never takes a score to zero. An early draft of this research read that as: every extra post adds some reach. It does not follow.

A post earns something from a request only if it is retrieved, survives nineteen filters, lands in the top 50 against every other author’s candidates (after being picked by the DPP stage, if that runs), survives visibility filtering and conversation deduplication, and is still among the 35 highest-scoring posts that remain. When ads are placed, they take some of those 35 places.

Where the cut falls is set by the competing candidates for that viewer, and nothing in the repository describes their scores. So whether another post adds reach is an empirical question.

The cut also makes the discount nonlinear. The same 37.5% score cut, from k = 0 to k = 1, costs little when the cut is easy and nearly everything when it is hard. Under an assumed lognormal spread of one author’s post quality:

A 37.5% cut in score becomes anything from a 30% to a 98% cut in the chance of clearing the cut. Authors whose posts are uniform in quality are hit harder than authors whose posts vary widely, because the discount is large against their natural variation.

Hold the simplest version of the mechanism: pure Top-50 selection, all of an author’s candidates carrying the same network multiplier, and the small-account lift held fixed. Add one more post, of any strength. The number of that author’s posts selected for the request either stays the same or rises by one.

The proof is short. Inserting one value into a sorted list interlaces the order statistics, so the author’s new scores are at least the old ones at every rank. A stronger post can still replace a particular older one, which is the band in 04, but it takes that place rather than removing one.

Two related results hold in the same setting. An author’s selected posts are always their top-ranked ones, with no gaps. And whether the author’s single best post is selected does not involve D(k) at all: it depends only on its own score and the competitors’.

A simulation agrees. Across five competitor scenarios, author set sizes from 1 to 50 and 20,000 trials each, adding a post never lowered the author’s count. Synthetic

Where the simple case breaks

Your retweets and replies. For a follower, your originals carry a network multiplier of 1 and your retweets and replies 0.75, and k is ranked before that multiplier applies. A retweet with a higher base value takes k = 0 and demotes your original to 0.625, while its own score is cut to 0.75. Both can land under the cut. With dense competitor scores the count falls from 1 to 0 whenever

The ordering and the multipliers are read from the code. That a retweet counts toward the retweeter’s own rank is an inference from how the in-network source fills the author field. A retweet is only removed as a duplicate when its source post is already a candidate earlier in the list.

The DPP stage, if it runs. A selection that penalises similarity can lower the count outright; see 15.

The repository does not support the rule as stated.

If your successful post is still your highest-scoring candidate for a viewer, a weaker new original cannot demote it through D(k). Its multiplier stays at 1, and under pure Top-K selection whether it is selected does not depend on how many other posts of yours are in that request.

A new post can cost the older one something only for viewers where all four of these hold:

1. 01Both posts are candidates in the same request.
2. 02The new post has the higher base value for that viewer.
3. 03The viewer has not already seen the older post. Seen posts are excluded at retrieval, so the effect can only reach the older post’s not-yet-reached audience.
4. 04The drop from 1 to 0.625 actually moves the older post across the cut.

So “never post while a tweet is going viral” is much too strong. The worry is most plausible when the next post is comparably strong and much of the older post’s audience has not seen it yet. Even then, in the simple model, the author’s number of selected posts does not fall: one post replaces the other.

One exception runs the other way: a strong retweet or reply of yours in that window can demote the original for your followers (06). None of this turns into a better universal rule. It turns into a measurement, hypothesis H1 in the experiment below.

Nothing here supports 30 minutes, 60, 90, two hours, three hours, or any other interval as a universal optimum. Spacing does not appear in D(k): k is a rank within one request, and the multiplier has no time term.

Spacing can still matter indirectly, because it changes which of your posts are candidates at the same time. For a follower, a post is retrieved in-network only while all of these hold:

• —It is under 48 hours old.
• —The viewer has not seen it. Seen posts are excluded before anything is counted.
• —It is among your 50 newest unseen originals.
• —Fewer than about 1,200 newer unseen posts have arrived from everyone the viewer follows. Retrieval is newest first.

Call λ_j the rate at which the accounts viewer j follows produce eligible posts. The window in which an older post can still share a request with a newer one is then roughly

Take two hypothetical viewers. One follows 50 quiet accounts: 1,200 newer posts may never arrive within 48 hours, so your two posts can meet for most of the window. The other follows 2,000 hyperactive accounts: your older post can fall out of retrieval within hours. Same posts, same spacing, different candidate sets.

So spacing does not change D(k). It changes how much of the older post’s not-yet-reached audience a newer post can meet while both are candidates, and viewers who already saw the older post cannot be affected at all. For viewers outside your network, retrieval is embedding-based and learned, and no window can be derived. No single spacing number can come out of repository constants.

Higher cadence pulls two ways at once.

If quality held steady as you posted more, the expected best of five posts would be about 2.14 times a single post, and of ten about 2.80 times, at a spread of σ = 0.8. That is the exploration effect, the one force author diversity cannot reach. Nothing in the repository says whether quality does hold steady.

Written out, the trade-off is

Three of the five terms are unknown. That is why there is no universal answer.

The repository cannot produce “post 4 times a day”, “maximum 6 a day” or “10 a day suppresses you”. A documented search of the ranking and safety code, 23 terms across 14 directories, found no explicit daily threshold and no author post-rate feature. That is a statement about the inspected open-source paths, not about all of X.

What the code does contain, none of it a daily number:

• —A per-author cap in in-network retrieval: 50 originals and 30 replies or retweets. Compile-time constants.
• —A fixed number of places: the top 50, then the top 35 posts, which placed ads share.
• —Author diversity, D(k).
• —Seen state: posts a viewer has seen are not retrieved again.
• —A 48-hour age cutoff, and post age as a learned model input.
• —A behavioural-authenticity model that represents burstiness and mechanical cadence.

Add the two things the code cannot supply, how an author’s quality moves with cadence and how selective each viewer’s feed is, and the optimum is not identified. In a synthetic sweep of the per-request model, where every setting is consistent with the repository, the number of co-present posts that maximised selections ranged from 1 to 50, the whole range tested.

That sweep is per request, and public evidence does not link a request to a day either. The defensible conclusion is narrow: N*, the best number of posts per day, has to be measured, account by account.

The repository’s safety code includes BDSM, a transformer that reads an account’s recent actions as a sequence. Its position encoding is driven by action timestamps, so, in its README’s words, the model represents “inter-action timing (burstiness, mechanical cadence)”. Its task heads include TweetSpamBot, ReplySpamBot, EngagementAmplifier and MultiActionBot.

That establishes that timing patterns can be represented. It does not expose any rule that turns a cadence into a penalty, and it does not support claims like “posting every hour gets you penalised”. What the model does with timing is unknown.

There is a hard cutoff: candidates older than 48 hours are removed before scoring, by a compile-time constant. Inside that window the scoring code has no hand-written decay multiplier.

But post age is also an input feature of the ranking model, in hourly buckets across 80 hours. The model can learn how predicted value moves with age, so there is no basis for saying a score stays constant for 48 hours. The learned curve cannot be recovered from the repository.

The same feature list includes the viewer’s local hour of day and day of week. “Best time to post” has a real mechanism; what the model learned from it is unknown.

One mechanism favours small accounts. In each request at most one candidate is lifted, and at repository defaults a post qualifies only if all of these hold:

• —It is an original: not a reply, not a retweet.
• —Its author has at most 1,000 followers (ColdStartFollowerCap).
• —It is at most 48 hours old (ColdStartMaxPostAgeSecs).
• —It has fewer than 1,000 views on Home (ColdStartImpressionThreshold, a separate parameter that happens to share the value).
• —It already ranks in the top 85% of the request’s candidates with a nonzero score (LowImpressionsMaxPositionRatio).
• —The viewer’s experiment arm and the author’s bucket allow it.

Among qualifying posts, the highest-scoring one is lifted to at least the score of the request’s 16th-best candidate: the target rank is drawn from [15, 16), counting from zero. The viewer-level switch that enables all of this is on by default.

The lift comes before D(k) and the network multiplier. A lifted out-of-network post is then multiplied by 0.75, and a lifted post that is its author’s second candidate by 0.625. It assigns a score; it does not reserve a place, and the post still has to survive selection, filtering and blending.

So the mechanism is gated on the account first. The post’s own Home views are a second, separate condition. The earlier reading of it as simply “posts under 1,000 impressions” missed the account test.

An earlier revision of this research took its reply rules from SelfReplyChainFilter. That filter is only used in the reverse-chronological pipeline, not in For You. The For You rules are three:

1. 01Out-of-network replies and retweets are removed. A reply reaches a For You viewer only if that viewer follows the person who wrote it.
2. 02In-network, a reply to an original post is retrieved with no requirement to follow the original author. A reply to a reply is retrieved only if the viewer also follows the person being replied to. Deeper replies are not retrieved, nor is a reply whose parent is missing from the in-network store.
3. 03Only the highest-scoring post of each conversation survives a request.

So a reply to a large account does not reach that account’s audience through For You: those viewers do not follow you. Any exposure there comes from the conversation view, notifications, search or profiles, which this repository does not cover.

Threads follow from the same rules. Continuations are replies, so only the first post can travel out-of-network, at most the first post and two continuations are retrievable in-network, and a thread yields at most one post per request. But every co-present thread post still takes a same-author rank before the conversation is collapsed, so a strong continuation can demote a separate original and then be removed itself.

The ranking service also contains a determinantal point process, DPP: a selection over post embeddings. If it runs, it takes the top 150 candidates by value score, greedily picks up to 50 that are both high-scoring and unlike each other, and gives every other candidate a score of 0. It is a gate, not a reordering.

It penalises similarity in general, not only the same author twice. And its quality term compresses scores: at the switch default θ = 0.65, the whole pool’s score range maps into a factor of at most e^2α ≈ 6.4. Near the cut, a post scoring 10% more than another, both at a quarter of the pool’s top score, gains only about 4.7% in the kernel, so similarity to posts already picked can outweigh a higher score.

Whether it runs in production cannot be established:

• —The service’s --dpp-enabled flag defaults to false, and the DPP context is only built when it is set.
• —The feature switch DppEnabled defaults to true.
• —The home-mixer always asks for the model id “dpp”, and the README describes the stage as part of the system.
• —The deployment’s actual flags are not public.

The request and the README show intent, not state. So this page keeps the two paths apart and assumes neither.

If DPP runs, an author whose posts sit close together in embedding space levels off near one selected post per request, beyond anything D(k) does. And adding a post can lower the author’s count outright.

In the simulation this was rare but real: in every setting, at most 2% of added posts lowered the count. In one case a new post 10% stronger than the author’s existing best took the author from one selected post to none.

The research went through three revisions and an adversarial audit, and it was wrong in places before it was right. These are the corrections that changed a conclusion, including one to this page itself.

• WasNo time decay: a score holds for 48 hours.

  NowPost age is a model input, in hourly buckets. Its effect is learned and cannot be read.

• WasThe multiplier never reaches zero, so every extra post adds reach.

  NowA positive score is not a selection, and a selection is not an impression. Marginal reach cannot be derived.

• WasThe small-account lift means posts under 1,000 impressions.

  NowIt is gated on the author first: at most 1,000 followers, originals only. A Home-view limit is a separate condition. It lifts a score and reserves no slot.

• WasReply rules come from SelfReplyChainFilter.

  NowThat filter belongs to the reverse-chronological pipeline. For You uses the out-of-network filter and the in-network reply-depth rule.

• WasThere is no per-author cap.

  NowIn-network retrieval keeps at most 50 originals per author: MAX_ORIGINAL_POSTS_PER_AUTHOR = 50.

• WasThread continuations can travel out-of-network.

  NowOnly a thread’s first post can.

• WasTest a spacing of 45 to 90 minutes.

  NowNo spacing value has support in the code, the documentation or data. Withdrawn.

• WasThe ranking service reorders candidates.

  NowA DPP stage would remove them, and whether it runs is undetermined.

• WasThis page said X released the code on 13 August 2026.

  NowThat is the date of commit a389166, which the first notes read. The repository’s history begins on 20 January 2026.