X Cold-Start Playbook

The single most important thing to know when starting from zero: the algorithm hands new accounts a subsidy, but it is time-limited. This is not "beginner protection period" marketing talk — it is a piece of logic in the source code called author_cold_start, on by default, with conditions written very tightly.

What it does: on every feed request, out of all "original posts from small accounts" it picks the single highest-scoring one and lifts that post's score up to the 16th-highest score in that batch of candidates.

Note two things — only one post is picked per request, and the boost lands at the 16th-highest score in that batch, not at the top spot. This is not a "make you go viral" mechanism; it is a "give you a mid-pack position where you can be seen" mechanism.

1. The specification of that window

Cold start eligibility — all of the following must hold at once

1. It must be an original post —— replies do not count, retweets do not count (in_reply_to_tweet_id.is_none() and retweeted_tweet_id.is_none())

1. Author follower count ≤ 1000 —— exactly 1000 still qualifies; you only lose it above that

1. That post's impressions < 1000 —— strictly less than. Once it passes 1000 it drops out of the pool

1. Its rank position has not yet fallen into the bottom 15% (position < 0.85 × number of valid candidates)

1. The post is not from a Phoenix retrieval MoE source (an extra condition under the default bucket)

The exact algorithm for the landing point (many people get this wrong)

The code sorts candidate scores from high to low, then takes ranked[random_range(lo..hi)] as the target score, where lo = min(ColdStartSlotMin, hi) and hi = min(ColdStartSlotMax, candidate count).

The defaults are Min=15 and Max=16, so random_range(15..16) is always exactly 15 —— "random within a range" has no randomness at all under the default values, and the landing point is fixed at the 16th-highest score.

And when the candidate count is ≤ 15, lo >= hi and the function returns None outright —— cold start does not fire at all. To get this subsidy, that batch needs at least 16 valid candidates.

A widely misreported condition: 24 hours. The code does contain ColdStartMaxPostAgeSecs = 86400 (24 hours), but that line only takes effect in the experiment's Treatment bucket —— cold_start_freshness_eligible() returns true outright for non-Treatment buckets. And both bucket switches (PhoenixMoeCodivertViewerIsTreatment / ...IsControl) are false by default, which means the default path runs the Holdout bucket. So on the default path, cold start has no 24-hour limit. The real hard wall is the global 48-hour AgeFilter — past that a post is cut outright, not decayed gradually.

I got this one wrong myself at first. The source pack I dispatched wrote the 24 hours as a general condition, and the outside agents' drafts copied it straight through as a general rule. Only when I went back and read author_cold_start.rs:149-154 did I find it wrapped inside a bucket gate. Recorded here as a reminder: with anything conditional, look at what it is wrapped in.

Two properties that are easy to overlook

One: it does not rescue bad posts. Eligibility condition 4 is "its rank position has not yet fallen into the bottom 15%". What cold start does is lift a post that was already not bad from mid-pack to 16th place; it does not revive one sitting at the bottom. Content quality is still the ticket in.

Two: it is an argmax contest. Among all eligible small-account posts it "picks only the single highest-scoring one" —— a contest like that rewards being "extremely useful to one narrow group", not being "average for everybody". Average content never comes first under argmax. So the topic has to be narrow enough to state in one sentence.

2. Three operating rules derived from six conditions

Rule one

Keep only "one" flagship original live at a time

Because each feed request picks only one. If you publish three originals at once, they do not get three slots — they fight each other for the same one.

Basis: apply_cold_start uses max_by(scores) to take a single index, then applies the score boost to that one post only.

Rule two

The second post "taxes" the first

The harsher problem is ordering. On the default path, the code executes in this order:

Cold-start boost  →  same-author decay  →  unfollow discount ×0.75

Meaning: even if your post does get lifted by cold start, if you have another post ranked ahead of it, same-author decay then multiplies it by 0.625, and after that comes the 0.75 out-of-network discount. The boost happens first; the deductions happen after.

Basis: the ordering author_cold_start.apply() → apply_author_diversity() → after_diversity × effective_oon in ranking_scorer.rs (machine-verified).

Rule three

When to swap in the next post: watch two numbers

There are two signals that a flagship post is "used up": impressions pass 1000 (it drops out of the cold start pool), or 48 hours since publishing (AgeFilter cuts it outright). Whichever happens first, swap in the next one.

Basis: ColdStartImpressionThreshold = 1000, MAX_POST_AGE = 172800 seconds. The source code contains no "best time to post" and no "how many posts per day"; the numbers other people quote are not in this codebase.

Think of it as one slot: only ever one flagship original live at a time; once it passes 1000 impressions or reaches 48 hours, the next one goes in.

A pit the system will not block for you: topic fatigue

The seen-already filters (3 of them) work at the post level, not the topic level. The same person can see three different posts of yours within one week that all say the same thing —— the system will not stop it at all.

And topic fatigue is exactly where "mute" (−58.8) comes from. So this is something you have to manage yourself: a minimum 48-hour gap before revisiting the same topic (wait for the original post to be cut by AgeFilter so you are not competing with yourself), which in practice means a 7-day rotation schedule.

One corollary: rewriting older content from a different angle and republishing it after 48 hours costs nothing mechanically —— the original post is already outside AgeFilter and stopped getting traffic long ago. This is the workhorse of the whole approach.

3. 1000 followers is not a ceiling, it is a time-limited ticket

Once you pass 1000 followers, the only thing you lose is this: the chance for an original post to be picked out and lifted to the 16th-highest score. There is no extra penalty anywhere in the code for "more than 1000 followers" — normal scoring, candidate generation, and filtering are exactly the same.

So the right way to see it is not "better to stay under 1000", but:

Before 1000 followers, you have a time-limited free testing ground. What to do with that window is find out "what content can survive on its normal score alone" —— because past 1000 the subsidy is gone and everything else rests on the content itself.

A practical test: if your posts only get impressions when cold start lifts them, that means the content's own predicted score is not enough, and you will fall off a cliff past 1000. Conversely, if a post's impressions run far beyond 1000 (still going long after it left the cold start pool), that is the evidence that "the content moves on its own".

4. What to write: the price list determines the content form

Score = the predicted probability of each action × the weight of that action. The weights are prices hard-coded in the config file:

So the goal for the content is not "worth liking", it is "worth taking away". One question is enough: would anyone copy this link and paste it into a group chat, or DM it to a friend?

In the from-zero phase you can prioritize content units that can be carried off on their own: a curated list, a comparison table, a set of steps, a number whose source can be checked, a judgment stated clearly. These are forms designed for the 20.0 and 5.0 items — but to be clear: this is content design; it does not mean those actions will actually happen.

5. Mutual follows: the only mechanism in the code that adds points for a relationship

In the entire weight table there is exactly one place that adds points for a "person-to-person relationship": when you and the author follow each other, the weight of a reply goes from 5.0 to 20.0. There is no second one. Follower count itself adds nothing, and a one-way follow adds nothing.

And there is a combination here that matters especially for someone starting from zero:

Two tracks that do not conflict

• Main post track: original posts → go through cold start, one at a time

• Reply track: replies are not eligible for cold start (the first condition rules them out), so replies never occupy or dilute your main post's slot —— and under a mutual follow, a reply is worth 20.0

In other words: replying more does not hurt your main post. The two tracks are separate at the code level. The practical approach from zero is this — one flagship original per day through cold start, with the rest of your effort going into building real mutual follows and replying seriously under those people's posts.

But an "empty-shell mutual follow" is worth zero — not a little, zero

The key is that the +15.0 bonus is multiplied by the probability that "the model predicts they will reply to you". If the other person never replies to you, p(reply) ≈ 0, so 15.0 × ≈0 ≈ 0.

At the same time, every mutual follow adds +1 to your follower count —— and passing 1000 followers permanently loses you cold start eligibility.

This is the sharpest tension in the whole strategy: you have only 1000 follower slots, and each mutual follow spends one of them. Every empty-shell mutual follow spends part of your subsidy quota to buy something worth 0.

So there is only one criterion for following: will this person actually reply to me. Observable tests (visible before you follow them):

• Does their timeline show a lot of "them replying to other people"? With someone who only posts and never replies, you will never collect this bonus.

• Do their topics overlap with yours? Only with overlap is there something to reply to, and only then does a reply have substance.

• Follower count does not matter. Big accounts almost never follow back, so the bonus never arrives; following them only changes what you yourself see.

The execution is unglamorous: pick a fixed few people each day, read the whole post, then reply with one sentence of real substance (not "well said" or "agreed"). The follow comes after they reply to you, not before.

One derived figure: counting the mutual-follow bonus, the total positive budget goes from 43.324 to 58.324, and the negative-to-positive ratio drops from 8.48 to 6.30. This is the only lever in the entire codebase that improves your negative-to-positive structure.

But this is not a licence for "follow-back tactics". Engagement pods, and mass mechanical replies aimed at pumping numbers, are manipulation the platform bans in writing. And from the algorithm's point of view they do not pay off either — the reasons are in the next section.

6. The worst mistake from zero: trading controversy for your first followers

First understand the number 43.324: it is the theoretical ceiling for "one reader performing every positive action to the maximum" (every probability equal to 1, impossible in reality). With that ceiling in hand, negative signals convert into something very concrete:

"Being scrolled past" and "being marked not interested" differ by 2160 times. So never write a sensational opening just to "keep from being scrolled past" —— what you save is 0.02, and the risk you take on is 43.2.

Working one post through the system's own formula

The score is simply Σ(weight × probability), so the expected contribution of each impression can be computed directly. The probabilities below are assumed in order to demonstrate the formula, not measured values —— the repo contains no probabilities.

Demonstration: a post where "20% of people like it and 3% of people mark it not interested"

Like contribution      0.20 × 0.5   = +0.100
Not-interested contribution  0.03 × 43.2  = −1.296
                          ─────────
Net value                        −1.196

A 3% "not interested" rate eats 12.96 times what a 20% like rate produces. Want to break even on likes? You would need a like rate of 259.2% —— impossible. Want to break even on copy-link shares? You would need 6.48% of people to copy your link —— extremely high, but at least a possible number.

This is the core of the whole strategy: under this pricing structure, the only positive item that can absorb negative signals is "being copied and taken away". Likes cannot.

The expected value of some common follower-growth tactics

One report is −234.0, and beyond that —— once a score comes out negative it is compressed into the extremely narrow band from 0 to 0.001, so ranking differences between negative-scoring posts go to almost nothing and the whole batch sinks to the very bottom. This is not "ranked a bit lower".

Here is the arithmetic: get 100 likes by flame-baiting (+50), and if the same post gets just 1 person to hit mute (−58.8), the trade is already negative.

This is why "controversial content grows followers fast" is negative expected value under this pricing structure: it raises the predicted probability of positive and negative actions at the same time, and the negative side is an order of magnitude more expensive. It is especially dangerous from zero — you have no content assets yet to amortize the cost against.

The veto on topic selection

Answer this one question before publishing

A stranger who does not know you at all and does not agree with your position reads this post — is their most likely reaction "boring, scroll past" or "I want to hit not interested"? Basis: −0.02 against −43.2, a difference of 2160 times. The worst case your content produces for a non-audience must be "boring", never "dislike".

To be recommended to strangers, the content has to be cleaner

The whole point of cold start is to put you in front of non-followers. But content recommended to non-followers has to clear 26 more rules than content shown to followers, and those 26 can only cut, never let through, including "high recall" spam and adult-content detection — plainly put, they would rather cut the innocent.

The non-follower path carries no prior context. Anything that needs context in order not to offend (parody, in-group jokes, sarcasm) only gets cut on this route. Borderline content can circulate inside your follower circle, but it is almost impossible to get it recommended outward.

7. How far this can be automated

It can be, and it should be — but first separate three things: what the machine should do, what the machine may do but a human must release, and what blows up the moment you touch it.

✓ Green light: fully automated by machine, legitimate and worth doing

• Publishing "already human-approved" content through the official X API

• Pulling performance data and building 24/48 hour snapshots

• Maintaining the state machine for "which post is the live flagship right now"

• Threshold alerts: impressions past 1000, 48 hours since publishing, followers crossing 1000, schedule conflicts, API errors

• The source library, version history, topic hypotheses and experiment records

• Duplicate content detection (so you do not collide with yourself)

▲ Yellow light: machine drafts, human releases

• LLM generating post drafts, rewriting, and tidying up formatting

• LLM compiling feedback and producing the next round's topic brief

• Candidate drafts for replies and DMs — but a human must read them before they go out

• Local eligibility checks (original / not a reply / not a retweet / followers / impressions)

✕ Red light: do not do these — they are manipulation the platform bans in writing

• Fake accounts and multi-account coordination to fabricate engagement signals

• Like-and-follow-back rings (engagement pods)

• Automated mass replies and automated mass DMs

• Poll manipulation

• Rule-breaking scraping at scale

Why the red-light items "do not pay off even if you are never caught"

This is not only a question of rules; it also follows from the algorithm's mechanics:

• Mechanical engagement cannot reach the valuable actions. The top of the price list is "copy-link share", "DM share" and "quote" —— things a real person does only when they think the content is worth carrying off. Automation can farm likes (0.5); it cannot farm 20.0.

• Pushing content at people it does not fit is buying negative points. Impressions bought through manipulation land on an uninterested audience and raise the predicted probability of NotInterested / Mute / Report — that side is 8.48 times more expensive.

• Mass production dilutes you instead. Cold start picks only one post per request, and same-author decay applies after the boost. Automated high-volume publishing only makes your own posts fight for the slot and tax each other.

What the toolchain looks like

Topic hypothesis/material library
      │
      ▼
LLM drafting and formatting
      │
      ▼
Machine eligibility check (locally computable part)
Original? Not a reply? Not a repost? Followers ≤1000? Is there already a featured post on the board?
      │
      ▼
╔══════════════════════════════════╗
║  Human gate: facts/tone/risk/signoff  ║   ← Cannot be skipped
╚══════════════════════════════════╝
      │ Approved
      ▼
Publishing queue ──► official X API publishing
      │
      ▼
State machine: followers/per-post impressions/post age/featured post on the board
      │
      ├─► Alert (impressions exceed 1000, reaches 48h, followers exceed 1000)─► human
      ├─► 24h / 48h performance snapshot ──────────────────► report
      └─► next-round brief ─────────────────────► LLM draft

Comments/DMs take a separate human branch:
Classification and draft (machine)─► human reads and judges context ─► person sends

One key design point: separate "computable locally" from "only the server knows"

Locally computable (can become an automated gate):
    Original and not a reply and not a repost
    and followers ≤ 1000
    and post impressions < 1000

Server-only (don't pretend it is computable):
    The post's feed request rank < 0.85 × eligible candidate count
    Whether the post has the highest score among all eligible candidates
    Model predicted probability for each action

This boundary matters because it determines what your dashboard is allowed to claim. You can never see whether you actually got that boost. A rise in impressions may come from cold start, or from ordinary ranking, or from external sharing — do not treat correlation as causation, and do not invent an "X score" of your own to put on a dashboard and pretend it is real.

Measure the right thing

One last practical suggestion: do not use "like count" as your primary metric. A like is priced at 0.5, while shares / quotes / replies run 5.0 to 20.0. Your reports should break out the share class and the reply class separately, because those are the parts of the price list that actually drive ranking.

8. Where this strategy is most likely to fail

The biggest risk is overfitting to a single public snapshot. Cold start is on by default, but a post still has to enter the valid candidate set, clear 17 upstream filters, avoid falling into the bottom 15%, and be the highest-scoring post among all eligible candidates in that same request —— and the boost only lands at the 16th-highest score; with fewer than 16 candidates it does not fire at all. If content and audience do not match, the "one at a time" rhythm will not repair a weak predicted score; negative predictions may instead drop the post into the compressed band from 0 to 0.001. And from the account side you cannot see model probabilities, cannot see actual rank, and cannot see the full set of negative signals, so it is very easy to misread ordinary fluctuation as cold start working. There is another structural risk: once followers pass 1000, if you have not yet grown content ability that does not depend on the subsidy, this ranking support disappears outright, and the source code offers no replacement growth mechanism. But the most fundamental objection is this one: what this whole playbook proves is "how not to lose points", not "how to score points". In the formula, the positive terms and the negative terms are summed separately. Avoiding negative points does not automatically produce positive points. If I lean too hard on "avoiding landmines", what you write will be harmless to everybody and therefore useless to everybody —— and that kind of content has a positive predicted probability just as close to zero, so the score still stops near 0.001. The harder gap is this: cold start lifts only one post per request, and if the global number of eligible small accounts far exceeds the number of feed requests, the frequency with which any individual account gets that slot could be too low to mean anything at the strategy level —— and the competitor base is not in the source code, so I cannot compute this strategy's expected value. There is one more structural fragility: EnableViewerColdStart is a switch. In the same config, a parameter with force as extreme as NEW_USER_OON_WEIGHT_FACTOR = 0.00001 exists, with its threshold set to 0 and switched off — proof that X retains the ability to flip new-account distribution at any time. Any strategy that "starts up on cold start" is structurally fragile against that switch.

9. What this playbook cannot tell you

One: this is a public snapshot, not the live system. The comment at the top of param.rs states plainly that it is "mirrored from config feature-switch defaults; last sync 2026-08-12", and these values can be adjusted live at any time. The code can prove "what the public version's defaults are"; it cannot prove "what X is using at this moment". Two: pricing is not the actual score. The formula is "weight × model-predicted probability", and the probabilities are not in the repo. Every "A is worth N times B" holds only at the pricing layer, and you cannot multiply weights by interaction counts and pass the result off as an algorithm score. Three: it covers the For You line only. Another 6 filters belong to other pipelines and are not public; X has said explicitly that it did not release Grox's LLM content-safety prompt. Four: this is an operating strategy, not a performance promise. Every item above is an operational suggestion derived from publicly released mechanics, not a platform guarantee, and it guarantees neither reach nor follower growth. There is no such thing as "the best time to post" or "how many posts per day" in the source code — when someone hands you a precise number of that kind, you can ask which line they read it from.

The not-in-the-source list (things you cannot make decisions on)

Listing "I do not know" explicitly is more useful than pretending to know:

An honest internal contradiction: the core of this playbook is "avoiding safety penalties", but the prompt that decides what is safe and what is not is precisely the part X did not publish. Writing a strategy centred on avoiding safety penalties out of a snapshot that is missing the safety criteria —— that is contradictory in itself, and I cannot resolve it from inside the public material.

How this playbook was made (including one mistake of my own)

I sent the same source pack to two independent agents to write one draft each, then verified them item by item against the source code. I recomputed all the arithmetic in both drafts (23 items, all correct), and the parts I adopted are marked above.

But both drafts inherited a mistake of mine. In the source pack I wrote "24 hours" as a general cold start condition, and both agents duly derived the conclusion "space your posts 24 hours apart so the eligibility windows do not overlap". Only when I went back and read author_cold_start.rs:149-154 did I find that line wrapped inside an experiment bucket gate, not in effect on the default path at all. The conclusion "one post per day" still holds, but its basis is "only one is picked per request" + "same-author decay comes after the boost", not that nonexistent 24-hour window. What caught it was not disagreement between the agents; it was going back and reading the source code. Two independent agents handed the same wrong premise will consistently derive the same wrong conclusion —— consensus is not correctness.

One sentence to take away

Before 1000 followers, keep exactly one original worth taking away live at a time; spend the rest of your time building real mutual follows. Automate the pipeline; keep judgment human.

Sources and verification

This article is based on the X recommendation algorithm source code published by xai-org on GitHub, read on August 14, 2026.

Every mechanism and threshold value in this article is taken from the source code and reproduced item by item through machine propositions.

Limits of validity: the parameters in the source code are annotated as mirrors of feature switch defaults, and can be adjusted live at any time. This article can prove the public version's default values; it cannot prove the values the platform is actually running right now. The final score is "weight multiplied by model-predicted probability", and the probabilities are not in the public source code, so all multiple comparisons hold only at the pricing layer.