Contradicted by the source
“Ein Repost ist 20 Mal so viel wert wie ein Like.”
RetweetWeight ist 1.0 und FavoriteWeight ist 0.5, daher hat ein Repost das doppelte Gewicht eines Likes — nicht das zwanzigfache.
Woher es kommt: Keine veröffentlichte Version des Algorithmus verwendete jemals 20. Der 2023er Heavy Ranker gewichtete Retweets ebenfalls mit 1.0 gegenüber Favoriten mit 0.5.
Was true, of an older version
“Eine Antwort ist 27 Mal so viel wert wie ein Like (oder 13.5 Mal).”
ReplyWeight ist 5.0 gegenüber FavoriteWeight 0.5, also zehnmal — und vierzigmal zwischen gegenseitigen Follows, da BidirectionalFollowReplyWeightBoost 15.0 zum Antwortgewicht für Originalbeiträge zwischen sich gegenseitig folgenden Konten hinzufügt.
Woher es kommt: Beide Zahlen waren real für ein Modell, das nicht mehr existiert: Der 2023er Heavy Ranker veröffentlichte am 31.03.2023 27, dann am 05.04.2023 13.5. Sie beschreiben eine Scala-Pipeline, die durch die aktuelle Rust-Pipeline ersetzt wurde.
Was true, of an older version
“Klicks auf Ihr Profil sind 12 Mal so viel wert wie ein Like.”
ProfileClickWeight ist 0.0. Ein Profilklick trägt nichts zur gewichteten Punktzahl bei.
Woher es kommt: 12.0 war das 2023er Gewicht für `good_profile_click` — ein anderes, zusammengesetztes Signal (ein Profil öffnen UND dann liken oder antworten). Das aktuelle Modell hat einen einfachen Profilklick-Kopf, der mit Null gewichtet ist.
No such parameter exists
“Ein Lesezeichen ist 10 Likes wert — Lesezeichen sind das stärkste Signal.”
Es gibt kein Lesezeichen-Gewicht in param.rs, daher fließen Lesezeichen überhaupt nicht in die gewichtete Punktzahl ein. Sie sind jedoch nicht unsichtbar: bookmark_count wird jedem Kandidaten als Modellmerkmal hinzugefügt, und ClientTweetBookmark zählt als positive Interaktion in der Historie des Zuschauers. Gelesen, aber ungewichtet.
Woher es kommt: Die 2025er Scala-Aktualisierung deklarierte einen home_mixer_model_weight_bookmark-Parameter — mit einem Standardwert von 0.0. Keine veröffentlichte Version gewichtete ihn jemals mit 10.
Was wir im festgepinnten Commit gesucht haben
Es gibt kein Lesezeichen-Gewicht in param.rs
bookmark · 2 Dateien · 0 Treffer
bookmark_count wird jedem Kandidaten als Modellmerkmal hinzugefügt
bookmark_count · 1 Datei · 5 Treffer
ClientTweetBookmark zählt als positive Interaktion in der Historie des Zuschauers
ClientTweetBookmark · 1 Datei · 1 Treffer
Right numbers, wrong reading
“Ein Report annulliert 468 Likes (−234.0 ÷ 0.5).”
Die Arithmetik ist korrekt, aber die Schlussfolgerung ist immer noch falsch. Gewichte multiplizieren eine VORHERGESAGTE WAHRSCHEINLICHKEIT, nicht eine Anzahl von Aktionen. X gibt an, dass die Basiswahrscheinlichkeit eines Reports mehr als tausendmal niedriger ist als die eines Likes, daher ergibt die Division eines Gewichts durch ein anderes keinen Wechselkurs zwischen Aktionen.
Woher es kommt: Dieser ist nicht veraltet — es ist eine Fehlinterpretation korrekter Zahlen, und er erscheint sogar auf Seiten, die die richtige Tabelle veröffentlichen. X fügte am 14.08.2026 eine explizite Warnung dazu in sein eigenes README ein.
No such parameter exists
“Engagement-Geschwindigkeit zählt 1000×, Autorenautorität 50×, Aktualität 22×.”
In param.rs existiert kein Parameter für Geschwindigkeit, Autorität oder Aktualität. Das Alter ist überhaupt kein Gewicht – es ist ein harter Schnitt: AgeFilter verwirft jeden Beitrag, der älter als MAX_POST_AGE ist, eine kompilierte Konstante von 48 Stunden. Nichts multipliziert die Punktzahl eines Beitrags mit seiner Frische.
Was wir im festgepinnten Commit gesucht haben
Es existiert kein Parameter für Geschwindigkeit, Autorität oder Aktualität in param.rs
velocity|authority|recency · 1 Datei · 0 Treffer
AgeFilter verwirft alle Beiträge, die älter als MAX_POST_AGE sind
AgeFilter::new\(.*MAX_POST_AGE · 1 Datei · 1 Treffer
Contradicted by the source
“Eine koordinierte Gruppe kann Ihren Beitrag durch Massenmeldungen oder Massenblockierungen vergraben.”
X geht darauf direkt in den Kommentaren von param.rs ein, und der beschriebene Mechanismus ist überprüfbar: Das Modell prognostiziert IHRE Wahrscheinlichkeit einer Aktion, daher sind Empfehlungen personalisiert – Meldungen einer Brigade beeinflussen hauptsächlich, was Personen empfohlen wird, die dieser Brigade ähneln. Und ein Engagement zählt nur, wenn es auf einem Beitrag in der Home-Timeline stattfindet: Das direkte Navigieren zu einem Beitrag, zum Beispiel aus einem Gruppenchat, hat keinen Ranking-Einfluss.
Woher es kommt: Eine vernünftige Schlussfolgerung aus den sehr großen negativen Gewichten, die die Gewichte allein nicht stützen.
Was wir im festgepinnten Commit gesucht haben
Was true, of an older version
“X veröffentlichte den Code, hielt aber die Ranking-Gewichte aus Sicherheitsgründen zurück.”
Zutreffend für die Veröffentlichung im Januar 2026, falsch seit dem 13.08.2026. Die numerischen Standardwerte befinden sich jetzt in param.rs, und X gibt an, dass Cron-Skripte sie den primären Produktionswerten gleichhalten.
Woher es kommt: Genaue Berichterstattung über den Rückgang im Januar 2026, nach August nie aktualisiert.
Was wir im festgepinnten Commit gesucht haben
X gibt an, dass Cron-Skripte sie den primären Produktionswerten gleichhalten
cron scripts that set the defaults · 1 Datei · 1 Treffer
Contradicted by the source
“Beiträge mit externen Links werden herabgestuft.”
Im veröffentlichten Ranking-Code ist OpenLinkWeight POSITIV bei 0,2 und wird bedingungslos angewendet – das Öffnen eines Links wird belohnt. Links werden nur durch Sicherheitskennzeichnungen wie MALICIOUS_URL und DO_NOT_AMPLIFY bestraft, die sich auf das Ziel beziehen, nicht auf das Verlinken.
Was wir im festgepinnten Commit gesucht haben
Links werden nur durch Sicherheitskennzeichnungen wie MALICIOUS_URL bestraft
MALICIOUS_URL · 7 Dateien · 1 Treffer
… und DO_NOT_AMPLIFY
DO_NOT_AMPLIFY · 7 Dateien · 1 Treffer
Contradicted by the source
“Ein bezahltes Häkchen kauft einen Ranking-Boost.”
In param.rs existiert kein Premium-, verifizierter oder Abonnement-Multiplikator, und kein solcher Rescorer erscheint in den veröffentlichten Scorern. Der Code von 2023 enthielt einen – Multiplikatoren von 4,0 im Netzwerk und 2,0 außerhalb des Netzwerks für Blue Verified-Autoren – und er ist aus dem aktuellen Baum verschwunden. Ehrliche Grenze: Phoenix ist ein gelerntes Modell, dessen Gewichte nicht veröffentlicht werden, daher kann eine gelernte Korrelation durch das Lesen des Codes nicht ausgeschlossen werden.
Woher es kommt: Die Scala-Pipeline von 2023 hat tatsächlich einen 4,0 / 2,0 Blue Verified-Multiplikator angewendet.
Was wir im festgepinnten Commit gesucht haben
Es existiert kein Premium-, verifizierter oder Abonnement-Multiplikator in param.rs
premium|verified|subscription · 1 Datei · 0 Treffer
Ein solcher Rescorer erscheint nicht in den veröffentlichten Scorern
premium|verified|subscription · 8 Dateien · 0 Treffer
Contradicted by the source
“X veröffentlicht jetzt behördliche Entfernungsanfragen in seinem Open-Source-Repository, und Brasilien ist das einzige aufgeführte Land.”
Das Repository veröffentlicht den Durchsetzungs-MECHANISMUS, niemals eine Anfrage. Die Regeln, die einen Beitrag für Betrachter in einem zurückgehaltenen Land entfernen – LegalTakedown und LocalLawsTakedown – lesen einen Grund, der den Ländercode enthält, aber dieser Grund wird zur Laufzeit von einem unveröffentlichten Dienst abgerufen, und der Typ, der ihn enthält (TakedownReason), ist in einem im Repository fehlenden Crate definiert. X veröffentlicht auch die Infrastruktur um diesen Typ herum in Scala: einen Gizmoduck-Lesefilter, der nicht durchgesetzte Entfernungen vor der Rückgabe eines Lesevorgangs entfernt, eine Tweet Entity Service-Spalte und -Transformation, die die Entfernungsgründe eines Beitrags abrufen, und die internen Jobs, die diese Gründe in die Labels umwandeln, die einem Konto über sich selbst angezeigt werden. Die Thrift-Strukturen, die dies tragen – Takedowns { country_codes, takedown_country_reasons } – werden also von veröffentlichtem Code in 3 Dateien gelesen: `takedowns/gizmoduck/RedactUnenforcedTakedownsFilter.scala`, `takedowns/tweet-entity-service/TakedownReasonsTransform.scala`, `under-the-hood/scalding/UthPctdAccountTakedownEventsJob.scala`. Was das hinzufügt, ist mehr MECHANISMUS, nicht eine Anfrage: Beim festgelegten Commit ist kein einziger Ländercode neben einem Entnahmegrund außerhalb von Test-Fixtures geschrieben – die einzigen zweistelligen Codes, die der Entnahmecode enthält, sind `xx`, `xy`, die weltweiten Sentinels, die die Quelle selbst benennt, was überall bedeutet und das Gegenteil eines Landes ist. Und die Methode, die den Tweet Entity Service unter ihrem eigenen Namen nach diesen Codes fragen würde, get_takedown_country_codes, erscheint überhaupt nirgendwo im Repository. Brasilien ist etwas ganz anderes: eine fest codierte Liste von 2795 Konten, die dem Wahlgericht gemeldet wurden, aus dem öffentlichen Kandidatendatensatz stammen und für jeden Betrachter weltweit aus „Für dich“ entfernt werden, es sei denn, sie folgen dem Konto – ganz ohne Länderbedingung, was das Gegenteil davon ist, wie eine rechtliche Entfernung hier funktioniert. Ehrliche Einschränkung: Ein Repository ohne fest codiertes Land ist keine Plattform ohne länderbezogene Entfernungen. Die Anfragen existieren; sie leben außerhalb des Repositorys, aggregiert, im Transparenzzentrum und im DSA-Bericht.
Woher es kommt: X's eigener Beitrag vom 14. August kündigte zwei Dinge an: die Ranking-Gewichtungen und den Brasilien-Wahlfilter. Musk zitierte ihn am nächsten Tag in 61 Zeichen – „Jede von Regierungen geforderte Zensur ist jetzt klar sichtbar“ – und nannte dabei weder das Repository, noch Anfragen, noch Länder; die Presse verband es mit einer benutzerorientierten Mitteilung, die angekündigt, aber nicht ausgeliefert wurde. Die Wörter „Anfragen“ und „im Open-Source-Algorithmus“ erscheinen erstmals zusammen auf einem Aggregator-Konto.
Was wir im festgepinnten Commit gesucht haben
Die veröffentlichte Scala-Infrastruktur liest die Thrift-Löschstrukturen – Takedowns { country_codes, takedown_country_reasons }
\bTakedowns\b|\btakedownCountryReasons\b · 43 Dateien · 15 Treffer
Contradicted by the source
“Das Stummschalten eines Keywords verbirgt jeden Beitrag, der es enthält.”
Ein stummgeschaltetes Schlüsselwort ist keine einzelne Regel. Der veröffentlichte Timeline-Dienst wendet es mit 2 Filtern an, die nicht denselben Text lesen: ViewerMutedKeywordFilter, registriert in phoenix_candidate_pipeline.rs, vergleicht es mit tweet_text; FollowingViewerMutedKeywordFilter, registriert in reverse_chron_posts_pipeline.rs, vergleicht es mit ancestor_texts, quoted_tweet_text und tweet_text. Die Felder, die nur einige von ihnen lesen – ancestor_texts und quoted_tweet_text – werden von conversation_gap_ancestor_hydrator.rs, quote_hydrator.rs und quoted_post_text_hydrator.rs geschrieben, registriert in phoenix_candidate_pipeline.rs, phoenix_scores_pipeline.rs und reverse_chron_posts_pipeline.rs. Eine Pipeline, die diese Hydratoren nicht ausführt, füllt sie niemals: Dort ist der Text eines zitierten oder übergeordneten Beitrags nicht nur ungelesen, er ist abwesend. Jenseits der Timeline trägt die Regel-Engine zur Sichtbarkeitsfilterung – die Schicht, die einen Beitrag überall dort ausblenden kann, wo er erscheint – ViewerMutesAuthor (Mutes) und ViewerMutesRetweets (MuteRetweets), und keine Regel, deren Entscheidung ein Schlüsselwort liest. Das einzige Ergebnis für stummgeschaltete Schlüsselwörter, das dieses Repository benennt, MatchesMutedKeyword, erscheint genau 1 Mal – in graphql_results.rs – und nur auf der linken Seite eines Match-Arms, der es einem Zwischen-Label zuordnet. Nichts hier entscheidet darüber; was auch immer es tut, wird nicht veröffentlicht. Zwei ehrliche Einschränkungen. Dieses Repository ist der Dienst, der eine Timeline erstellt: Was das Stummschalten in Benachrichtigungen oder bei der Suche bewirkt, wird an anderer Stelle entschieden, in Code, den X nicht veröffentlicht, und eine Abwesenheit hier ist eine Abwesenheit aus dem Repository, nicht vom Produkt. Und wir sagen Ihnen nicht, welche Registerkarte jede Pipeline bedient – diese Verkabelung läuft durch mehrere Schichten, und eine Zuordnung, die wir nicht sauber extrahieren können, ist eine Zuordnung, die wir nicht veröffentlichen.
Woher es kommt: Stummschalten ist eine einzelne Einstellung im Produkt, daher wird es als eine einzige Regel gelesen, die überall gilt. Der veröffentlichte Code zeigt etwas Engeres: Ein stummgeschaltetes Keyword wird angewendet, während eine Timeline zusammengestellt wird, und die Filter, die es anwenden, lesen nicht alle denselben Text – so kann ein Beitrag das Wort an einer Stelle enthalten, die kein Filter auf diesem Pfad jemals betrachtet.