Social Algorithm Updates: X, Reddit, TikTok, Pinterest, Facebook and LinkedIn

The sixteenth commit landed at 22:37 UTC on 28th Aug. It touches 24 files and about 3,100 changed lines, the thirteenth release since the repository opened.

The ranking-side change is a new parameter, RerankerHeadTag, mirrored from X's feature-switch config with a default of zero. Every scoring request to the Phoenix ranker now carries it in the user-action sequence.

Every scored post comes back stamped with it.

The published code shows the tag traveling, not what the model does with it. The serving engine's parser and embedding tables gained handling for it in the same push.

The shape is a lever for serving different reranker variants, or model heads, to different requests. It works by flipping a config value rather than shipping code.

Nothing is flipped yet. The parameter file's only other change is its own sync timestamp, so the tag sits at zero.

The MultiRiskBlender ads logic from the previous release still had no parameter moved at this commit. It became the default on 1st Sep.

No weight in the ranking blend changed.

The bigger diff by line count is in visibility filtering. That is the layer that decides which posts get dropped, hidden or interstitialed.

The rules were refactored around a shared context module, and most rule files got shorter.

What makes that publishable rather than housekeeping is the new test material. It is a 1,039-line "golden corpus" of expected verdicts plus fixtures, compiled only for tests.

A change that alters any moderation verdict now has to edit a published expected result to pass. That makes future changes to these rules diffable in a way they were not before.

The README's only edit dates the Brazilian electoral account-list change to 27th Aug.

Commit 24c60942 was pushed at 01:00 UTC on 28th Aug. It touches 41 files for 2,071 added and 265 removed lines.

The change with the clearest advertiser consequence is a new ads blender, MultiRiskBlender. It sorts a batch of timeline posts into safe, medium-risk and high-risk buckets.

Those buckets decide how many ads the batch can carry.

The ad budget is capped at half the safe posts, on top of the existing spacing rules. When no safe slot exists, the batch carries no ads at all, with one exception.

An ad whose advertiser is marked as tolerating high brand-safety risk can still be placed beside medium-risk posts.

Every outcome is measured, including the reasons ads were withheld. The new blender is wired into the blender selector, but no parameter moved in this commit.

So which requests actually use it is not visible in the diff.

It became the default four days later, in the fifteenth release.

Second, the published schema caught up. Both copies of the protocol definition now carry reconCountAbove and reconGapAbove.

Those are the two topic-diversity fields the Rust code gained two days earlier. That closes the one-day schema lag that entry described.

Two renames ride along in the same files. Placeholder action 84 becomes CLIENT_TWEET_VIDEO_6SEC_VIEW, a named six-second video view.

An aggregation type flips from profile short dwell to profile long dwell.

Third, the reply-score ratchet from the same release got stricter in three ways. Before, the write was skipped only when the new score was higher than the stored one.

Now it is also skipped when the two are equal. The recorded reason was renamed from "higher_than_existing" to "not_lower_than_existing".

The read of the existing score also stopped failing softly. Until now a failed fetch logged a warning and the write went ahead anyway.

It now stops the write, so the ratchet fails closed.

And the Kafka publish now runs before the primary store write rather than after it. The code still gives no reason for the rule that scores may fall but not rise.

Fourth, the Brazil election filter's comment block now lists ten accounts, each with the same sentence: "We believe the account @X reported by the candidate is not the candidate's actual account, so we are not currently filtering it."

Two of the ten, @dayse and @ricar, were in the filtered set until this commit. So X is now declining, account by account and in public, to apply parts of the Electoral Court registry.

It does so where it judges the reported handle wrong.

Smaller changes: visibility filtering gained a sampled cache warmer for the base-post safety-label map. It is configured by environment variable and off by default at zero percent.

A new test pins that a muted CJK keyword matches whole tokens only. So muting one city name does not remove posts about another that contains it.

The parameter file changed by exactly one line, its own sync timestamp. Nothing X ships behind a flag moved, and the second-generation ad brand-safety verdict stays on.

The standing caveat applies as it has to the eleven releases before this one. This is read from a commit rather than from an announcement.

Code in the repository is not proof of behaviour in the live product.

Commit 45b48ba6 was pushed at 20:04 UTC on 26th Aug. It touches 36 files for 873 added and 525 removed lines.

The change that reaches ordinary users is how X describes an author to its reply-spam model. That model decides whether a reply is spam.

Until now the prompt opened with a single line combining display name and handle. It now renders the handle, the display name, and two new optional fields: User Follower Count and User Bio.

Both reply-spam classifiers, the ranking one and the simple scorer, turn the follower count on. It is rendered for every post in the thread and for the reply being judged.

The bio is rendered only for the author of the post that started the thread.

The thread renderer also gained a heading telling the model exactly whose profile it is reading: "The user profile and any signals below describe the author of the reply being evaluated (the final post of the thread)."

Read that against the last fortnight and the direction is consistent. The eighth and ninth releases moved the follower boundary, first to 80,000 and then to 100,000.

That boundary decides whether a reply goes to reply ranking or to spam detection.

Follower count was already deciding which system judged a reply. It is now also visible to the model doing the judging.

That is a different thing, and one the code states plainly.

What the diff does not show is what the model does with it. So treat any claim that a small account is now scored worse as unproven by this release.

The second change is narrower and easier to describe. When a reply ranking score is published, the writer now fetches the existing score first.

It skips the write when the new score is higher than the stored one, recording the reason as "higher_than_existing".

A stored score can therefore fall or stay put, but not rise. A score of zero is what applies the reply-spam label.

The code gives no reason for the rule.

Three smaller changes. Visibility filtering lost its media fallback cache entirely, a million-entry cache plus both of its environment flags.

So during an outage of the post-entity service, media features no longer come from a stale copy. The author-lookup fallback cache stays.

Dark-traffic mirroring now refuses to run unless it can read a workload name. It never runs on hosts whose name ends in "-canary".

The ranking model also gained three ad prediction targets, including a combined long-dwell-and-conversion action. Requests can now carry the identifiers of conversion assets a user has been shown.

On the diversity work from earlier in the cluster, the home-mixer slate context gained two more fields. They are recon_count_above and recon_gap_above.

At this release, both published copies of the protocol definition still stopped at reconCosMilli. The Rust side had gained that field a day earlier.

So the published schema was running about a day behind the code that fills it. The next commit added both fields to the schema.

Finally, the parameter file changed by exactly one line, its own sync timestamp. Nothing X ships behind a flag moved today.

So the second-generation ad brand-safety verdict switched on yesterday stays on. No weight in the ranking blend changed.

Commit 0d3cdd80 landed at 23:20 UTC on 25th Aug. It is +5,850/-586 across 47 files, the tenth release since 13th Aug.

It is also the first since 14th Aug to touch the README. The README renames its "Latest Updates" heading to "Notable Updates" and adds one line to the Brazil section: "(Account list updated August 25, 2026.)"

The advertising change comes first, because it reverses what the code said yesterday.

EnableAdsBrandSafetyVerdictV2 now defaults to true. That switch had defaulted to false since the second-generation verdict was published on 13th Aug.

The parameter file records its own sync from the live config as 25th Aug at 16:20 UTC.

What that turns on is narrower than the name suggests, and the fallback is the reason.

The v2 function hands straight back to the original whenever a post carries none of Grok's four second-generation labels. So for every post that classifier has not scored, nothing about the verdict changes.

Where those labels do exist, they now decide it. The six high-risk labels added in yesterday's release are identical in both generations.

So the most severe category is unaffected either way.

The medium-risk list is where the two differ. The v2 list reads Grok's second-generation "not safe for advertising" label plus an expanded version of it.

It leaves out NSFA at high precision, which forces a medium-risk verdict under the original.

The test for whether Grok has scored a post at all moved to the v2 labels too. So a post the second-generation classifier has touched is now judged entirely on that generation's evidence.

Second, the Brazilian electoral filter grew from 665 accounts to 2,328. The file went from 1,573 lines to 4,947.

The mechanism is unchanged: a hardcoded set of user IDs, each annotated with its username. The author of every candidate post is checked against it.

The post is dropped unless the viewer follows that account.

The source file now also names its legal basis and its data source, which it did not before. They are Article 28 paragraph 1-A of Electoral Resolution No. 23.610, and the Electoral Court's public 2026 candidate dataset.

Forty-seven of the newly listed usernames carry a comment saying no live account was found for them. So the list tracks the candidate registry rather than accounts X has verified one by one.

Third, four ranking weights and two related defaults moved, and one of them is a first.

Dwell weight goes from 0.0 to 0.05, so predicted dwell now carries weight in the score at all. Video quality view weight goes the other way, from 0.05 to 0.0.

Video open weight rises from 0.05 to 0.07.

The Phoenix aggregation default also switches from short dwell to long dwell. That points the same way as the dwell weight.

Fourth, and this one matters for anyone reading their own view counts. The code adds a separate view_count_on_home alongside the existing total view count.

Author cold start is the mechanism that gives newer authors a chance in the feed. It now reads that home-timeline figure instead of the total, for both its sampling and its eligibility threshold.

So views a post earns from search, a profile or a notification no longer count against its cold-start eligibility. The number of cold-start candidates considered also drops from five to two.

Fifth, ads on the Following timeline get their own reporting identity. Ad events are now tagged following_promoted or ranked_following_promoted rather than sharing the For You label.

Each ad entry now carries its impression id.

Sixth, and the diff invites the wrong reading here. The topic-diversity work from 17th and 18th Aug has not been removed.

Home mixer stops computing the semantic-ID repetition counts and rank gaps for itself. It uses the ones already attached to each candidate instead, and the structure carrying them gains a new field.

What went is a local calculation, not the signal.

The multiplicative scoring path added earlier in the month did go, along with two of the ranker's configuration switches.

Two changes outside ranking complete the release. The Following timeline gains a check through the social graph.

It asks whether the author of a reposted or quoted post blocks the viewer.

And the abuse-enforcement rules gain a route for acting on penalties requested by an upstream scoring platform. They also gain a new spam label that triggers a temporary suspension under the platform-manipulation policy.

The standing caveat applies as it has to the nine releases before this one. This is read from a commit rather than from an announcement.

Code in the repository is not proof of behaviour in the live product.

Commit d011592a landed at 18:51 UTC on 24th Aug. It is +1,418/-117 across 19 files.

It is the ninth release since 13th Aug and the first after a three-day gap.

The root README is untouched for the ninth consecutive release. So the code is again the only account of what changed.

The advertising change is the substantive one.

X's brand-safety verdict has carried four values since it was published: unspecified, safe, low risk and medium risk. This release adds a fifth, high risk, and moves six labels into it.

They are NSFW at high precision and at high recall, and gore and violence at high precision. The others are PDNA, egregious NSFW and soft NSFW.

Five of those six sat in the medium-risk list until this commit. Soft NSFW appears in the file for the first time.

Nothing about where an ad can go changed today, and that is deliberate. The helper deciding which timeline gaps an ad may fill is has_avoid.

It was rewritten in the same commit to match medium risk or high risk. So a post carrying any of those six labels still blocks the slots on either side of it.

What the release buys is a severity distinction the ad system can act on later. It applies in both label generations too.

The high-risk check runs first in the original verdict function. It runs again in the v2 function that reads Grok's second-generation labels.

That v2 path shipped off at this release. Its parameter defaults to false under the key rust_home_mixer_ads_bs_v2_exp_enabled.

It was switched on the next day.

Every ads-injection log line now records which bucket of that experiment a request fell into. That is the change you make when an experiment starts running rather than when it is written.

Second, the follower threshold from our 21st Aug entry moved again, from 80,000 to 100,000. That is three days after it went from 60,000 to 80,000.

The mechanics are unchanged. A reply is eligible for reply ranking only when one of two accounts is above the threshold.

Those are the account replied to and the account that started the thread. It is eligible for spam detection only when both are at or below it.

So accounts between roughly 80,000 and 100,000 followers move out of reply ranking and into spam detection. Coordinated spam keeps its own separate threshold of 1,000 followers, untouched.

Third, an 812-line new file adds a shadow comparison to visibility filtering. It is the most revealing part of the release.

When an environment flag is set, each filter request also goes to the legacy visibility-filtering client. The two sets of verdicts are compared post by post and counted as exact matches or differences.

The reference call has a 1.5-second timeout.

The harness refuses to run in production. Setting the flag with APP_ENV=prod returns the error "VF_DUAL_CALL_HARNESS_ENABLED is set but APP_ENV=prod; the reference comparator is staging-only".

That confirms in code something the repository has never stated in prose. The published visibility-filtering service is a rewrite being checked against an older implementation that is not published.

Two smaller changes complete the release. Four of Grok's second-generation safety labels and a "PTOS reviewed" marker now pass through to the home mixer.

So downstream ranking can see them.

And the safety-policy flow gained a cross-validator that second-checks child-safety classifications, now extended to violent-media violations.

The standing caveat applies as it has to the eight releases before this one. This is read from a commit rather than from an announcement.

Code in the repository is not proof of behaviour in the live product.

Commit 28e414f5 landed at 19:10 UTC on 21st Aug. It is +856/-152 across 35 files, the eighth release in nine days.

The repository's root README is untouched for the eighth consecutive release. So once again the changes are documented only by the code.

The change with the clearest reader consequence is a single number moved twice.

In grox/flows/reply_spam/task_filter.py, two follower thresholds go from 60,000 to 80,000. Reading the file rather than the diff shows what they do: they are the same boundary, used in opposite directions.

A reply is eligible for reply ranking only when one of two accounts is above the threshold. Those are the account replied to and the account that started the thread.

Below that, both are skipped with the reason "low_blast_radius".

A reply is eligible for reply spam detection only when both of those accounts are at or below it. Above, it is skipped with the reason "reply_ranking_target".

So the number decides which of two systems reads the replies under your posts.

Moving it to 80,000 shifts accounts between roughly 60,000 and 80,000 followers. They leave reply ranking and enter spam detection.

A third filter, coordinated spam, keeps its own separate threshold of 1,000 followers. It still exempts high-PageRank and grey-badge accounts.

The bulk of the release is advertising.

Twenty new action types enter the ranking protocol. They are all conversions the old set could not express.

The first group is purchases, add-to-carts, sign-ups, tutorial completions and level-achieved events attributed inside a mobile app. Each has a paired view-through variant.

The second group is view-through versions of the purchase, add-to-cart, checkout-initiated, sign-up, site-visit, session, landing-page-view and upper-funnel conversions.

Supporting machinery arrives with them. There is a train_view_through_heads switch and a weight for in-app conversion loss.

There is also a flag for splitting head training by source, and a delayed-feedback marker plus a keep-mask. Those let conversions which arrive long after the impression be handled rather than treated as absences.

An advertiser cannot act on this yet, and all three switches default to off, but the direction is legible. X is building a ranker that can be trained on conversions nobody clicked.

Two smaller additions matter here. A new engagement signal, ClientTweetSearchQueryReformulated, joins the existing "not relevant to search" signal.

That means the model can now be trained on the fact that a searcher rephrased the query. It is the closest thing X's search has to a documented dissatisfaction signal.

And the slate context the 18th Aug release added to the request now comes back in the model's response. So the ranker can reuse what Phoenix scored with instead of recomputing it.

What the model actually does with those context signals is still not in the repository. That is four releases after we first said so.

One disclosure changed too, in xAI's favour. The Phoenix README used to say the export ships standard AdamW in the dense-optimizer slot rather than "production's tuned internal variant".

It now says "the flagship ranking configs and the nano twin train the production Muon recipe, which ships in full". AdamW is confined to the retrieval, gen-recs and legacy ranking presets.

The repository's central question is whether the released code is the code that runs. That is a narrowing of the gap, stated in the repository rather than announced anywhere.

The child-safety flow separately dropped its Grok 4.5 path and the 30% traffic dial that fed 4.6. That leaves 4.6 as the only cross-model validator.

X pushed a seventh release in eight days to the public algorithm repository at 20:22 UTC on 20th Aug. It is 479 lines added and 200 removed across 14 files.

The README is untouched for the seventh consecutive release. So the code is again the only account of what changed.

The substantive addition is a new hydrator, AiTrendFeedbackContextHydrator. It works on a whole timeline response rather than on one post.

It takes the candidates that qualify as standalone original posts. That means not a reply, not a repost, and no reply-thread parents.

It then asks a service which AI-generated trend each belongs to.

It then counts how often each trend appears across those candidates and keeps the two most frequent. It picks one post at random from each, and those two posts get the trend's name attached.

What a reader sees is a context label above the post, the same slot that already carries topic labels. The marshalling code makes topic labels win where both exist, so the trend label is the fallback.

One difference is visible and new: a topic label has never carried a link, and this one does. The trend name renders as an external link to x.com/i/trending/<id>.

So tapping the label leaves the post for the trend page.

The underlying structure is still X's topic-feedback type, which is the plumbing behind "show me less of this". So the label is a feedback prompt as much as a badge.

For a brand account, this is a small, random distribution lottery rather than a lever. The post chosen for a trend is a random pick among the candidates that share it.

So there is nothing to optimize toward and no way to tell after the fact.

What it does say is that X is now clustering posts into machine-generated trends inside the ranking pipeline. It is surfacing that clustering to readers by name.

That is a route out of your post and into a topic page. That page did not exist in the timeline before.

The rest of the release continues the slate-context work from the 18th Aug and 17th Aug releases. The Phoenix model now returns the slate context it actually scored with.

The ranker can use that in place of recomputing the values or reading stored ones.

That closes part of the question our 17th Aug entry left open. The diversity signals now travel back from the model as well as into it.

What the model does with them is still not in the repository.

Two caveats belong on this, and the second is stronger than the standing one. As always, code in the repository is not proof of behaviour in the live product.

And in this case both changes are explicitly gated. The trend-label hydrator sits behind a flag that defaults to off in the published code.

So does the served-slate-context switch. What has shipped here, then, is the capability rather than a confirmed rollout.

X pushed its sixth release in seven days to the public algorithm repository at 21:25 UTC on 19th Aug. It is 3,303 lines added and 651 removed across 82 files, much of it training and GPU work.

The README is untouched for the sixth time, so the code is again the only account of it. One change in it affects who sees a brand's posts.

Muted keywords now filter the Following timeline. That feed's pipeline previously ran two filters, one for deduplicating reposts and one for self-reply chains.

A muted word had no effect on it.

This release adds a dedicated keyword filter to it. So a term a user has muted now suppresses posts in the reverse-chronological feed of accounts they deliberately follow.

The new filter is also broader than the one on For You. The difference is in the code rather than in any announcement.

It tests three pieces of text against the muted list. The first two are the post's own text and the text of the post it quotes.

The third is the texts of the parent posts above it in a reply thread.

Two new pieces of plumbing exist to make that possible. One is a hydrator that fetches the quoted post's text.

The other is an addition to the ancestor hydrator that keeps the parents' text.

The For You filter was renamed in the same commit from MutedKeywordFilter to ViewerMutedKeywordFilter. It still matches the post's own text and nothing else.

For anyone running a brand account, that is a distribution ceiling that has just moved and that nobody can measure. Consider a user who has muted your product name, a competitor's, or a term your posts habitually quote.

They will now lose your Following-timeline posts that merely quote a post containing it.

There is no reporting surface for muted-keyword suppression on any platform. So the only visible symptom is reach that does not add up.

The rest of the release is machinery. A new module computes an adult-content prior and the safety classification flows around it were reworked.

The visibility-filtering service gains a dark-traffic harness for replaying requests. The training stack gains two optimizers and a large amount of attention-kernel work.

None of that states a ranking rule. One smaller behaviour change also lands here.

When the Following pipeline fails to expand a reply's ancestors, it now keeps the post. It keeps the ancestors it already had, where before the failure dropped the candidate.

The standing caveat applies as it did to the five releases before this one. This is read from a commit, not from an announcement.

Code in the repository is not proof of behaviour in the live product.

X pushed another release to its public algorithm repository at 18:57 UTC on 18th Aug. It is 208 lines added and 70 removed across 14 files.

It is a much smaller change than the four before it. The README is again untouched, and the code is the only account of it.

The first change closes a gap we flagged in the 17th Aug release. That one gave the For You slate builder repetition counts and ranking gaps for each candidate's semantic ID.

It did so at three levels of a topic hierarchy. But it stopped there: nothing in the diff showed the signals reaching the model.

They do now. The slate context sent to Phoenix with every candidate carries sid_known.

It also carries three levels of semantic-ID repetition count and three levels of gap. Those sit next to the author-level counts that were already there.

The second change is for advertisers, and it makes the newer brand-safety path less blunt. Yesterday's release added a second-generation verdict, at that point behind a flag that defaulted to off.

That verdict rated a post medium risk whenever Grok had not scored it.

It now checks first whether any of Grok's four second-generation labels exist on the post at all. If none do, it hands the post to the original verdict function instead of failing closed.

A test shipped with it is named for the behaviour: v2 defers to v1 when v2 has not ruled.

Two first-generation labels also leave the v2 risk lists, one from medium risk and one from low risk. The helper that used to strip first-generation labels written by Grok is deleted.

The effect is that the two generations no longer mix inside one verdict. The v2 function rules on posts it has labelled, and everything else is judged by v1.

The original function keeps its own rule of rating a post medium risk when Grok has not scored it.

The Following timeline also gets its own visibility filtering. The reverse-chronological pipeline previously shared the For You hydrator and now uses a dedicated one.

That hydrator asks the visibility service about each candidate plus its ancestors, its quoted post and its reposted post. It does so before the feed is built.

As with the previous four releases, this is read from the commit rather than from an announcement. A change to the code is not proof of a change to the live feed.

The brand-safety path in particular was gated at this release by a flag that shipped off. That flag was switched on a week later.

X pushed a fourth release to its public algorithm repository at 20:20 UTC on 17th Aug. It is 751 lines added and 162 removed across 34 files.

The top-level README that carried the 13th Aug and 14th Aug announcements is untouched. So the code is the only account of it.

The change most likely to reach a posting strategy is topic diversity. The For You slate builder already counted how many candidates shared an author.

It also counted how far apart in the ranking they sat. It now keeps the same counts and gaps for each candidate's semantic ID, at three levels of a topic hierarchy.

In plain terms, a repeated subject within one feed refresh is now measured. A repeated author already was.

The commit adds the signals and passes them on with each candidate. What the ranking model does with them is not in the diff.

Two author signals also start reaching Phoenix, the neural ranker. A post's author follower count is now filled in on the request for anything that is not a repost.

That field was previously left empty. A separate NSFW-author bit is set from the user service's own flags and labels.

The Following feed gets bigger. Its maximum result size moves from 100 to 110 with the ads slot count unchanged at nine.

So a refresh can return ten more posts than it could before.

Advertisers get a second brand-safety verdict path, and it shipped switched off. EnableAdsBrandSafetyVerdictV2 defaulted to false at this release.

Enabled, it reads a second generation of Grok-written safety labels and adds an expanded medium-risk tier. It fails closed, rating a post medium risk when Grok has not scored it.

The same applies when a review label is missing.

A disabled flag is not a live change to anything. So treat that as a signal of direction rather than a fact about today's feed.

It is the same shape as the cold-start sampling flag that arrived on the 14th and is still off.

One thing moved away from openness. The bot-detection module's README now records that its minimum-actions enforcement gate is redacted as well.

It ships as an impossible 999999 sentinel. The stated reason is that publishing it would reveal "the account-size floor below which scoring never fires".

A day after publishing its ranking weights, X added a second dated update to the repo's README. The larger half of it is a country-specific change to who gets recommended.

From 16th Aug, Brazilian electoral law requires providers that run recommendation systems to exclude certain accounts from their recommendations. Those are the official accounts of candidates registered with the Electoral Court, and those accounts' posts.

X says it is complying, and For You now runs a filter named Brazil2026ElectionFilter.

One word in the English README needs care. It describes accounts "reported to Brazil's Electoral Court", which means declared to it in the candidate registry, not reported by users for misconduct.

X's own Portuguese announcement is the clearer statement: these are the official accounts of registered candidates. The measure is compliance with Resolution 23.610/2019 rather than a sanction or a change to X's own rules.

The code names every account. A hardcoded list of 665 user IDs is checked against the author of every candidate post.

Each ID is annotated with its username. A post is dropped unless the viewer explicitly follows that account.

The filter also catches reposts and quotes of a listed account, and replies whose conversation thread reaches one.

X is explicit that the accounts are not suspended and their content stays on their profiles. It is equally explicit that the change will affect the visibility and reach of those profiles and their posts.

The legal text quoted in the code carries one exclusion that marketers should note. It applies "except in cases of paid boosting".

The second half of the update answers something that happened to X within a day of the weights going public. A reading spread quickly that a report cancels out a fixed number of likes.

X has now written the rebuttal into the code itself.

The weights multiply predicted probabilities, not engagement tallies. As the new comment in the scoring code puts it, "the weights do not multiply raw engagement counts".

So treating the ratio between two weights as a count equivalence is wrong.

The README is blunter about the specific claim, calling "1 report cancels out 468 likes" incorrect. It adds that the weights are "a multiple on your own predicted probability of Liking, Reporting, etc, which is substantially driven by your own behavior".

The comment also explains why the report weight is large in the first place: "the baseline probability of a Report is more than 1000x lower than a Like". So it has to be weighted up before the prediction can move the ranking at all.

That leads into the claim most likely to matter to anyone managing an account. It is that coordinated mass reporting or blocking can bury reach.

X gives two reasons it does not work that way. Recommendations are personalised, so "reports from bad actors will primarily affect recommendations for users who are similar to the bad actors" rather than suppressing the post for everyone.

The second reason is narrower and more concrete. An action only counts in the recommendation system if it happens on a post the Home Timeline served.

So "directly navigating to a post (i.e., coordinating via groupchat) has no ranking impact". A group cannot reliably make a target post appear in their own timelines to begin with.

X says it added the comments "so that LLMs or people reading it are more likely to understand it correctly". That is a fair description of what open-sourcing a ranking system now costs it.

On the Brazil filter it makes the opposite point in its favour: "A benefit of open-source is that you can see that changes like this exist, and exactly how they work".

The repo's own README, dated 13th Aug 2026, lists three additions. The first is the configuration parameters that blend predicted action values into a score.

The second is the code for systems that decide whether a post is filtered out of the For You feed.

The third is real Phoenix training code, in place of the old demonstration model. It comes with synthetic data generation so a proof-of-concept training run can be done.

The new systems are the ones that decide visibility rather than order. Visibility filtering determines whether to show a post, drop it, or show it behind an interstitial.

The release also opens the machinery feeding it. Those are label rule engines, account-scoring models, image and video models, and an enforcement service.

If you post on X, the scoring detail is the useful part. Phoenix predicts a probability for each action a viewer might take.

Those actions span engagement, clicks, attention, following the author, and negative signals such as mute, block and report.

Those probabilities are summed using the now-published weights, positive for positive actions and negative for negative ones. Three adjustments follow.

The first is a decay applied to each post after an author's first. The second is a discount for accounts the viewer does not follow.

That discount also hits replies and reposts from accounts they do follow. The third is a boost for authors whose impressions sit below a threshold.

The filters are equally concrete. Posts older than 48 hours are dropped before scoring, along with posts the viewer has already been shown.

So are their own posts, and reposts and replies from accounts they do not follow.

X's VP of Product Keith Coleman told TechCrunch that "You'll get the core ranking code that pulls posts and ranks them for any given user and assembles the feed", adding "This is the kind of thing that I think people will be fairly shocked that we are releasing".

The code is Apache v2 licensed, and TechCrunch puts the expansion at roughly 10 to 15 times the previous size.

The paired transparency tool sits on an "Under the Hood" page in the app's settings. Accounts that posted 10 or more times in the past month can download aggregate statistics as a JSON file.

It shows which visibility-affecting labels were applied to the account and its posts.

What is held back is stated openly: the Grox prompt files and some botmaker rules. The grounds are that "people could use it to try to game the system".

Engadget adds that ads code and systems outside the For You timeline stay unreleased.

So this does not meet Musk's stated goal that "every line of code touching the X system will be open source and third-party audited" in August. X says third-party recommender-system experts pressure-tested the release beforehand.

It does not say how they were chosen or whether their findings will be published.

The paper, from eight Pinterest researchers, describes vision-language-model relevance judging deployed at Pinterest Search to evaluate A/B experiments. It says "VLMs can provide reliable relevance measurement for experiments while greatly improving the evaluation efficiency".

The approach cuts the minimum detectable effects in online experiments.

It extends the system Pinterest documented in December 2025, where fine-tuned open-source LLMs score query-and-Pin relevance on a five-level scale. Those scores match human labels exactly 73.7% of the time and within one level 91.7% of the time.

For marketers: on Pinterest, "the algorithm" is unusually inspectable. The engineering blog has documented how search relevance is modeled.

It has documented what feed ranking consumes (up to 16,000 lifelong actions per user). Now it has documented how quality itself is measured.

The Pinterest section collects the trail.

Reddit's Q2 2026 shareholder letter reported its eighth consecutive quarter above 60% revenue growth. Revenue was $804.9 million, with net income of $253 million.

Daily uniques were up 18%. Logged-out daily uniques, the search-exposed cohort, were up 27%.

The sentence that moved the market: "Search referrals were choppy in the quarter, and traffic was more volatile later in the quarter". Shares sank roughly 11% in after-hours trading despite above-consensus guidance.

Huffman's framing leaned into independence: "While our visibility in referral traffic remains low, we're not building for drive-by traffic. We're building a daily destination."

One omission: this is the first letter in six quarters without a weekly-search-user or Reddit Answers figure. That breaks the series that ran 60, 70, 75 and 80+ million.

The quarter's other Google story compounds the dependence question. A week earlier, Reddit had discussed cutting off Google's AI access to its content.

That was per Wall Street Journal reporting carried by CNBC. The roughly $60-million-a-year data deal nears its end, with renewal talks under way.

The stock slid 8% on that report alone.

Tom Alison's post, "Connecting Real People on Facebook", announced a test that opens the app directly into full-screen video. It promises that "Classic Feed will always be available as the second tab in the app, just one click away", plus an opt-out to remain Feed-first.

Rollout is staged: testing starts later this year in video-heavy international markets. US exploration is planned for the following year.

The same post bundled Facebook Verified (a free selfie-verification badge). It also bundled a Seller app for Marketplace and a Forum app for Groups.

Distribution-wise, this is the biggest Facebook change since the December 2025 redesign, which moved search results to an immersive grid. The app's default entry surface becomes a ranked video feed.

Note the dating: much trade coverage describes an "August 2026 redesign". Meta's own posts date the announcement to 9th Dec 2025 and this test to 24th Jul 2026.

No August feed post exists on the newsroom.

The second open-source release landed in xai-org/x-algorithm as a 187-file commit adding 18,263 lines. It holds a runnable end-to-end inference pipeline and a pre-trained mini Phoenix model (256-dimension embeddings, roughly 3GB).

It also holds the new Grox content-understanding service for spam detection and policy enforcement. An ads-blending module sits inside the home-mixer.

That last part is significant: the first public documentation of ads blended inside the For You ranking pipeline itself.

The commit history tells the other story. Musk had committed in January to re-releases "every 4 weeks, with comprehensive developer notes".

The GitHub record shows zero public commits between 20th Jan and this release. There were three commits total before the August release.

The gap is not a criticism we infer. It is the repo's own verifiable state, and claims that the cadence "was maintained" are false.

TikTok announced TikTok GO on 12th May. It is a way to discover and book hotels, attractions and tours inside the app.

It is for users in the United States aged 18 or over.

The commerce story is the obvious one and it is not the reason this page carries it.

The reason is one sentence in the announcement about where the inventory appears: TikTok GO "surfaces lodging and things to do across the ways people already discover content on TikTok, through videos, search, and location pages".

Skift, which saw the feature at launch, puts the same point negatively: TikTok GO "is not a dedicated tab or section inside the app".

So this is a change to what a TikTok search result and a location page can contain. It is not a new destination bolted onto the side.

That is the same direction as the Search Hubs announced at TikTok World the following day. It is the second commercial layer to reach TikTok search inside two days.

The booking partners are Booking.com, Expedia, Viator, GetYourGuide, Tiqets and Trip.com. TikTok describes the app it is built into as one "more than 200 million Americans use".

That is its own figure and not an audited one.

For creators there is a direct incentive attached. Those who feature hotels, attractions and local services can earn commissions and take part in creator campaigns tied to bookings.

The announcement carries the note "Below is today's news made by TikTok USDS Joint Venture LLC" and quotes Adam Presser, the joint venture's CEO. So this is a product shipped by the American entity whose governance terms closed in January.

One correction to the natural reading, because the US newsroom post describes only the US. TikTok GO is not a US-only travel feature.

TechNode reported on 14th May that TikTok launched TikTok GO as a lifestyle-services brand in Indonesia, the US and Japan. It appeared in Indonesia first in late April, and its scope covers dining as well as travel.

We have not found a first-party TikTok post covering the Indonesian or Japanese launches. So those two markets rest on that reporting alone, and we have not verified what the feature does in either.

The standing caution for this platform applies here as everywhere on it. TikTok has said nothing about how, or whether, any of this affects For You ranking.

No ranking claim should be read into a booking product.

Meta's "Rewarding Original Creators on Facebook" did something platforms almost never do: published distribution results for an enforcement wave. Views and watch time of original Reels about doubled in the second half of 2025 versus a year earlier.

Over 20 million impersonating accounts were removed in 2025. Impersonation reports about large creators fell by a third.

The updated guidelines draw the line concretely. Deprioritized in Feed and Reels: reaction-only watching, and stitching clips without additions.

Also deprioritized: narrating what is on screen without meaningful contribution, and minor edits of someone else's post.

Genuinely transformed content becomes eligible for recommendation and "may benefit from increased distribution".

The consequence sentence is blunt: "Creators who are not adding substantial creative value will see their content deprioritized, and they may see their account deemed non-recommendable and demonetized."

It capped an arc that ran through 2025's spam and unoriginal-content enforcement. It rhymes with Instagram's April crackdown: originality is now an eligibility condition across Meta's surfaces.

"Engineering the next generation of LinkedIn's Feed", by Hristo Danchev, is the official reference the "LinkedIn algorithm" industry pretends exists elsewhere. Retrieval runs on an LLM-based dual encoder embedding members and posts.

Ranking runs on a transformer-based Generative Recommender. It processes more than 1,000 of a member's interactions in chronological order.

The signals it names: profile attributes (industry, experience, skills, geography) and engagement history (posts liked, commented on, dwelled on, skipped). It also names post metadata and engagement counts, device, and the interaction sequence over time.

Its learning philosophy in one sentence: "The model learns better from understanding what you chose to engage with than from the full set of what you were shown."

What it leaves out matters as much: no ranking-factor weights, no golden hour, no external-link penalty, no optimal posting cadence. There is also no mention of 360Brew, the withdrawn research preprint that guides cite as LinkedIn's "officially announced" new algorithm.

The LinkedIn section lays out the record against the myths.

A companion post in January had documented the search side. It covers LLM-judged relevance and a small-language-model reranker behind AI Job Search and People Search, with published evaluation numbers.

Reddit's Q4 2025 shareholder letter carried the search beat's best stats engine: "over 80 million people searching directly on Reddit every week in Q4, up from 60 million just one year ago".

The product news in the same letter: "significant progress in unifying our core search with Reddit Answers", ending the two-surface era. Answers was released in five new languages, and, forward-looking, Reddit is "piloting dynamic, agentic search results that include media beyond text".

The series behind the headline comes from the quarterly letters. It ran 60 million weekly searchers in Q1 2025 and 70 million in Q2.

By then Answers had 6 million weekly users, up from 1 million. Q3 brought 75 million and Q4 80-plus million.

Reddit Answers, launched December 2024, runs on Google's Gemini via Vertex AI. That makes Reddit's Google dependence two-sided: half its traffic and the model under its own AI search.

The joint venture closed on 22nd Jan as TikTok USDS Joint Venture LLC, with Adam Presser as CEO. ByteDance retains 19.9%, and Oracle, Silver Lake and MGX are managing investors on a majority-American board.

That is per CNBC's report of the company statement.

The statement said the venture "will operate under defined safeguards that protect national security through comprehensive data protections, algorithm security, content moderation, and software assurances for U.S. users".

The algorithm terms trace to the September executive order, whose accompanying fact sheet stated them verbatim: "The divestiture puts the operation of the algorithm, code, and content moderation decisions under the control of the new joint venture."

And: "it requires all recommendation models, including algorithms, that use U.S. user data to be retrained and monitored by America's trusted security partners."

Per the close reporting, the recommendation algorithm is now hosted in Oracle's American data centers. It is retrained, tested and updated on US user data.

Two disciplines for reading this event. It is a GOVERNANCE change: nothing official states any ranking behavior change.

Headlines inferring feed changes from it go beyond the documents.

And it makes TikTok the only major platform whose ranking system is, by agreement, forked and retrained per market. That is why every future "US TikTok algorithm" story will hang off this date.

Ten days after Musk committed to open-sourcing "all code used to determine what organic and advertising posts are recommended to users", the xai-org/x-algorithm repo appeared. It was 79 files, 8,816 lines, Apache 2.0, in Rust.

The architecture it documents: Home Mixer orchestrates the For You pipeline, and Thunder supplies in-network posts. Phoenix, a Grok-based transformer ported from the Grok-1 release, does retrieval and ranking by predicting probabilities across engagement types.

The final score is a weighted sum of predicted engagements, attenuated for author diversity.

The README's headline claim: "We have eliminated every single hand-engineered feature and most heuristics from the system." That matches the direction Musk had set in October 2025.

He said then that the system was moving to Grok reading every post and video, with heuristics slated for deletion.

One durable caution: this is X's second open-sourcing. The 2023 twitter/the-algorithm repo describes a different, Scala-era system, and its mechanics (boosts, heuristics) are routinely cited as current.

They are not. The 2026 repo explicitly repudiates them, and it is the only citable primary for how X ranks today.