Open Source · aus der Quelle lesen

X's Algorithmus, aus der Quelle gelesen

Am 13. August 2026 veröffentlichte X die numerischen Ranking-Gewichtungen, die es im Januar zurückgehalten hatte. Die meisten Zahlen, die über „den X-Algorithmus“ kursieren, sind falsch — meistens, weil sie sich auf das Modell von 2023 bezogen, das nicht mehr existiert. Jede Zahl auf dieser Seite ist ein Link zur Quellzeile, aus der sie stammt, fixiert auf einen Commit.

Repository xai-org/x-algorithmCommit 76843a5 (2026-10-02)Lizenz Apache-2.0Parameter synchronisiert 2026-10-01T16:00:46ZSeitendaten neu generiert 2026-10-02Täglich mit dem Repository abgeglichen

182

Live-Parameter

änderbar ohne Bereitstellung

23

kompilierte Konstanten

erfordern eine Codeänderung

135

Pipeline-Komponenten

Quellen, Filter, Scorer

12

geprüfte Behauptungen

jede gegen ihre Quellzeile

2798

Im Code genannte Konten

Aus 'Für dich' entfernt, es sei denn, Sie folgen ihnen

Einen Beitrag gegen den Code prüfen

Fügen Sie einen Link zu einem beliebigen öffentlichen Beitrag ein. Sie erhalten die Regeln, die tatsächlich darauf zutreffen – einschließlich der Länderbeschränkungen, die ihn verbergen können – gelesen aus dem angehefteten Commit.

Die Gewichtungen

Was jede Aktion tatsächlich wert ist

X states it runs cron scripts that set the defaults in the repository's code to be the primary production values, and aims for experiments running at 10% or more of traffic to be visible in the repository. The values below are those defaults, read at the pinned commit.

Dies sind die Gewichte, die der Scorer anwendet – gemessen, nicht versprochen. Vor der Bewertung multipliziert `perturbed()` 25 der 27 unten aufgeführten Gewichte mit `(sigma * perturbation_sign(salt, user_id, head)).exp()` – das Vorzeichen ist pro Betrachter und pro Head festgelegt. Die 2, die es unberührt lässt, sind die Modifikatorgewichte: BidirectionalFollowDwellWeightBoost, BidirectionalFollowReplyWeightBoost. `WeightPerturbationSigma` und `WeightPerturbationSalt` sind Feature-Switches: X kann sie ändern, ohne Code auszuliefern. Beim festgelegten Commit ist `WeightPerturbationSigma` 0.0, und die Bedingung `sigma <= 0.0` gibt sie unverändert zurück. Lesen Sie es an der Quelle

Jede Zeile enthält den Code, aus dem sie gelesen wurde – drücken SieErklärenum die tatsächlichen Rust-Codezeilen anzuzeigen, ohne die Seite zu verlassen.

AktionGewichtungvs. ein LikeQuelle
binaryMultiplies the predicted probability of a discrete action.
share via copy linkShareViaCopyLinkWeight2040×
param.rs
quoteQuoteWeight510×
param.rs
replyReplyWeight510×
param.rs
share via dmShareViaDmWeight510×
param.rs
follow authorFollowAuthorWeight48×
param.rs
shareShareWeight24×
param.rs
retweetRetweetWeight12×
param.rs
favoriteFavoriteWeight0.51×
param.rs
clickClickWeight0.30.6×
param.rs
open linkOpenLinkWeight0.20.4×
param.rs
video openVideoOpenWeight0.070.1×
param.rs
dwellDwellWeight0.050.1×
param.rs
photo expandPhotoExpandWeight0.050.1×
param.rs
quoted clickQuotedClickWeight0.050.1×
param.rs
post unexploredPostUnexploredWeight0.020×
param.rs
profile clickProfileClickWeight0—
param.rs
quoted vqvQuotedVqvWeight0—
param.rs
vqvVqvWeight0—
param.rs
not dwelledNotDwelledWeight-0.02−0×
param.rs
block authorBlockAuthorWeight-31.2−62×
param.rs
not interestedNotInterestedWeight-47.52−95×
param.rs
mute authorMuteAuthorWeight-58.8−118×
param.rs
reportReportWeight-234−468×
param.rs
continuousApplies to a quantity (watch or dwell seconds), not a probability.
cont click dwell timeContClickDwellTimeWeight0.4—
param.rs
cont dwell timeContDwellTimeWeight0.004—
param.rs
modifierNot a head weight: adds to another weight, or gates a branch.
bidirectional follow reply weight boostBidirectionalFollowReplyWeightBoost15—
param.rs
bidirectional follow dwell weight boostBidirectionalFollowDwellWeightBoost0—
param.rs

Die Einteilung in binär, kontinuierlich und Modifikator ist unsere — the weights struct and each field's use in vm-ranker/scoring/value_model.rs. X veröffentlicht diese Taxonomie nicht; wir trennen sie, weil nur die binären miteinander vergleichbar sind.

Legen Sie eine vorhergesagte Wahrscheinlichkeit für jede Aktion fest und beobachten Sie ihren Beitrag zur Punktzahl. Hier werden nur die Gewichte angeboten, die eine Wahrscheinlichkeit multiplizieren — das ist die Arithmetik, die der Code tatsächlich ausführt.

0% → 0.000
0% → 0.000
0% → 0.000
0% → 0.000
0% → 0.000
0% → 0.000
0% → 0.000
0% → 0.000
Gewichtete Summe0.000

Warum es hier kein „Gefällt-mir-Äquivalent“ gibt: Weights multiply a predicted probability, not an engagement count. Dividing one weight by another does not yield an exchange rate between actions.

Behauptungsprüfung

Zahlen, die jeder wiederholt, am Code geprüft

Das sind keine Erfindungen. Die meisten waren genaue Zahlen für den von Twitter 2023 veröffentlichten „Heavy Ranker“, eine Scala-Pipeline, die seither ersetzt wurde. Sie zirkulierten weiter, nachdem das, was sie beschrieben, nicht mehr existierte.

Jeder untenstehende Anspruch enthält die Suchanfragen, die ihn untermauern — das Muster, die Dateien, die Anzahl —, sodass Sie sie selbst gegen den festgepinnten Commit ausführen können. Sie werden hier niemals einen finden, der uns widerspricht: Wenn dies der Fall wäre, würde diese Seite nicht erstellt werden, anstatt den Satz zu veröffentlichen, den sie widerlegt.

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

  • X spricht dies direkt in den Kommentaren von param.rs an

    recommendations are personalized · 1 Datei · 1 Treffer

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.

Die Pipeline

Was mit einem Beitrag geschieht, in der richtigen Reihenfolge

Kandidatenquellen erzeugen Beiträge, Hydratoren fügen Merkmale hinzu, Filter können einen Beitrag vollständig löschen, Scorer können ihn nur verschieben. Jeder Knoten verweist auf seine Datei. Kanten deklarieren, wie wir sie abgeleitet haben – aus dem Code gelesen, durch die Verzeichnisstruktur vorgegeben oder, im schwächsten Fall, nach Namen abgeglichen.

Nach Land

Was sich ändert, je nachdem, woher Sie lesen

Zwei Länderlisten bestimmen, was sich ändert, je nachdem, woher Sie lesen, und sie bedeuten nicht dasselbe. Eine Liste hält sensible Medien von Zuschauern fern, die kein Alter angegeben haben. Die andere entscheidet lediglich, welche Länder das Modell unterscheiden darf – jedes andere Land wird zu „andere“, was keine Einschränkung, sondern nur ein blinder Fleck ist. Jede Karte unten gibt an, woher ihre eigene Liste gelesen wird: eine Konstante, die der Code anwendet, oder ein Fallback, das ein Laufzeitparameter ersetzen kann.

…

Klicken Sie auf ein Land in Rosa, um die Konten zu lesen, die dieser Code dort einzeln benennt. Im gesamten Repository hat genau ein Land eine solche Liste.

Wie dies geprüft wird: „das gesamte Repository“ wird im gesamten Repository geprüft, nicht nur in einer Sprache: Jede Datei unter dem festgelegten Commit wird gelesen, und eine Liste benannter Konten wird anhand ihrer FORM gefunden — ein @handle, das in einer Kommentarzeile geschrieben ist, unmittelbar gefolgt von der numerischen ID des Kontos. Diese Form ist nicht von Rust abhängig, sodass der Build dies meldet, wenn dieselbe Liste in einer anderen Sprache veröffentlicht wird, anstatt dass die Seite still bleibt.

2798 Konten werden direkt im Quellcode benannt, nach numerischer ID und nach Handle. Alles andere im Durchsetzungspfad agiert auf einem zur Laufzeit angehängten Label, und diese Kennzeichnung wird nicht veröffentlicht.

Brazil — 2795 Konten im Code benannt

Benutzer-IDs, die dem Wahlgericht für die Wahlen in Brasilien 2026 gemeldet wurden.

Filter für die Wahlen in Brasilien 2026. Art. 28 § 1º-A der Wahlresolution Nr. 23.610: Anwendungsanbieter, die ein Empfehlungssystem für Nutzer verwenden, müssen die Kanäle und Profile, die dem Wahlgericht gemäß § 1º dieses Artikels gemeldet wurden, aus den Ergebnissen ausschließen, und, außer in Fällen von bezahltem Boosting, die darauf veröffentlichten Inhalte. https://dadosabertos.tse.jus.br/dataset/candidatos-2026
2795
Konten, die in den Quellcode geschrieben wurden, nach ID und Handle
es sei denn, Sie folgen
ihre Beiträge, Reposts, Zitate und Thread-Vorfahren werden aus „Für dich“ entfernt – es sei denn, der Betrachter folgt dem Konto bereits
kein Ländertest
keine Länder-, Markt- oder Gebietsschema-Bedingung erscheint im Filter oder wo es registriert ist

⚠ Es erscheint keine Länder-, Markt- oder Gebietsschema-Bedingung in der Filterdatei oder um die Zeile herum, die sie registriert. Das ist eine Aussage über den veröffentlichten Code – welche Pipeline welchen Markt bedient, kann in einer Schicht entschieden werden, die X nicht veröffentlicht.

52 weitere Konten sind in dieser Datei benannt und werden NICHT gefiltert – der Code erklärt, warum jedes einzelne unberührt blieb: 44 × „@… kein aktives Konto gefunden.“; 8 × „Wir glauben, dass das vom Kandidaten gemeldete Konto @… nicht das tatsächliche Konto des Kandidaten ist, daher filtern wir es derzeit nicht.“ Somit sind hier 2847 benannte Konten erfasst, von denen 2795 tatsächlich gefiltert werden.

Registriert in der Pipeline am home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs:391

  • @madeleinelacsko
  • @nanacachen
  • @renildo
  • @VladimirAlves
  • @renatoroseno
  • @pedro_lupion
  • @erasintetica
  • @soninhafrancine
  • @AecioNeves
  • @tatyanavaleria
  • @ClariceChacon
  • @rosilenedf
  • @raulchristiano
  • @Rafael_Parente
  • @RicardoFabrizio
  • @marlonluz
  • @eduardopinheiro
  • @falcaopatos
  • @diegotavares
  • @RubinhoDivi
  • @depmariomotta
  • @depchinaglia
  • @Sen_Cristovam
  • @marcelvanhattem
  • @lgmbrasilia
  • @nilvanferreira
  • @DelioPinheiro
  • @RafaellMilas
  • @chagasvieira
  • @GabrielSouza_RS
  • @Pimenta13Br
  • @fabriziomeller
  • @rigotto
  • @gustavotutuca
  • @camasao50
  • @radiovaldo
  • @euserafimcorrea
  • @merisio
  • @rafangeli
  • @pauloteixeira13
  • @crismonteirosp
  • @ManuelaDavila
  • @tomioyano
  • @CintyaMuniz
  • @rodrigolimamdh
  • @Biango
  • @samiabomfim
  • @profsta
  • @Jfelippeneto
  • @depguibismarck

2745 weitere Konten sind in dieser Liste

Hinterlassen Sie eine E-Mail, um die vollständige Liste hier zu öffnen, und wir benachrichtigen Sie, wenn sich etwas ändert — der tägliche Watch vergleicht bereits unseren angehefteten Commit mit ihrem.

Zur Klarstellung: Diese Liste ist öffentlich. Sie befindet sich in einem Apache-2.0-Repository, und Sie können dieselbe Datei kostenlos lesen — home-mixer/filters/brazil_2026_election_filter.rs. Die E-Mail kauft hier Bequemlichkeit, nicht Zugang.

Die numerischen IDs in der Datei sind verschleiert — das Repository sagt dies selbst. Die Handles sind es nicht.

3 weitere Konten werden ohne zugehöriges Land benannt.
ThunderServiceImplthunder/thunder_service.rs:30
3
Konten, die in den Quellcode geschrieben wurden, nach ID und Handle
es sei denn, Sie folgen
ihre Beiträge, Reposts, Zitate und Thread-Vorfahren werden aus „Für dich“ entfernt – es sei denn, der Betrachter folgt dem Konto bereits
kein Ländertest
keine Länder-, Markt- oder Gebietsschema-Bedingung erscheint im Filter oder wo es registriert ist

⚠ Im Filter oder in der Zeile, die ihn registriert, sind keine Länder-, Markt- oder Gebietsschema-Bedingungen angegeben. Dies ist eine Aussage über den veröffentlichten Code – welche Pipeline welchen Markt bedient, kann in einer Schicht entschieden werden, die X nicht veröffentlicht.

Alle 3 Konten, in Quellreihenfolge

  • @grok
  • @gork
  • @products

Die numerischen IDs in der Datei sind verschleiert — das Repository sagt dies selbst. Die Handles sind es nicht.

Diese Liste wird aus einem öffentlichen Apache-2.0-Repository reproduziert, das besagt, dass die Handles zur Transparenz enthalten sind. Wir berichten, was der Code tut. Wir befürworten, überprüfen oder beurteilen die Berichte nicht, die ein Konto hier platziert haben.

Staatliche Entfernungen

Der Mechanismus ist veröffentlicht. Die Anfragen nicht.

Das Repository liefert die Regeln, die einen Beitrag vor Lesern in einem Land verbergen, das dies angefordert hat. Es liefert keine Anfrage und kein Land: Der Grund, der den Ländercode enthält, wird zur Laufzeit von einem Dienst abgerufen, den X nicht veröffentlicht.

0

Entfernungsanfragen, die im Repository veröffentlicht wurden

0

Länder, die einer solchen zugeordnet sind

2

Regeln, die auf einen Entfernungsgrund reagieren

So wird dies gezählt: Jede Datei im Repository wird zur Build-Zeit gescannt – nicht nur die Rust-Dateien, da die Lösch-Infrastruktur auch in Scala existiert, und eine Abwesenheit, die dort gemessen wird, wo die Sache nicht mehr ist, ist keine Abwesenheit. Testcode wird auf zwei Ebenen entfernt – Dateien, die ein übergeordnetes Element als `#[cfg(test)] mod …;` deklariert, werden ausgeschlossen, und im Rest wird der `#[cfg(test)]`-Körper abgeschnitten – und wonach gesucht wird, ist ein Ländercode, der neben einem Löschgrund geschrieben ist. Die zweistelligen Codes, die die Quelle selbst weltweit benennt (`xx`, `xy`), bedeuten überall und nicht ein Land: Sie werden beiseitegelegt und offen aufgeführt. Der Build schlägt fehl, wenn diese Zahl jemals aufhört, null zu sein – die obige Behauptung kann nicht von selbst veralten.

Woher das Land stammt: der Typ, der es trägt, TakedownReason, ist in keiner Datei dieses Repositorys definiert – er wird importiert aus xai_core_entities, einem Crate, das hier nicht veröffentlicht wird.

Und die Methode, die die Länder einer Entfernung abrufen würde, get_takedown_country_codes, erscheint überhaupt nirgendwo im Repository. Die Schnittstelle existiert auf X's Seite; der veröffentlichte Code ruft sie nie auf.

Verstehen Sie dies richtig: Ein Repository ohne fest codiertes Land ist keine Plattform ohne länderspezifische Entfernungen. Die Anfragen existieren – sie befinden sich außerhalb dieses Repositorys, aggregiert nach Land und Halbjahr in X's Transparenzbericht, niemals einzeln. Was hier gemessen wird, ist das, was der Code aussagt, nicht das, was das Unternehmen tut.

Methode und Grenzen

Was diese Seite Ihnen nicht sagen kann

Das Modell ist nicht der Code

Die oben genannten Gewichte werden auf Wahrscheinlichkeiten angewendet, die von Phoenix erzeugt werden, einem gelernten Transformer, dessen trainierte Parameter nicht veröffentlicht sind. Das Lesen des Codes kann eine Korrelation, die das Modell selbst gelernt hat, nicht ausschließen.

Einiges wird zurückgehalten

X gibt an, die Grox LLM Prompt-Vorlagen und einige Durchsetzungsregeln zurückzuhalten, um Manipulationen zu reduzieren. Der Klassifikator-Code und die Regel-Engine sind veröffentlicht; der Prompt-Text nicht.

Niemand kann überprüfen, was läuft

X sagt, dass Cron-Skripte diese Standardwerte mit den Produktionswerten übereinstimmen lassen und dass Experimente über etwa 10% des Traffics hier sichtbar sein sollten. Beides sind Behauptungen über ein System, das niemand außerhalb von X beobachten kann.

Parameternamen und Codeausschnitte werden auf Englisch belassen: Sie zitieren Quellcode, und ein übersetzter Bezeichner stimmt nicht mehr mit der zitierten Zeile überein. Die Anspruchsprüfungen werden übersetzt – die Bezeichner darin bleiben unverändert.

Warum ein Datenunternehmen dies entwickelt hat

Das ist die Methode, die wir verkaufen, angewendet auf eine Quelle, über die alle streiten: etwas Undurchsichtiges nehmen, es in einen Graphen verwandeln, in dem jeder Wert seine Herkunftslinie trägt, und sich weigern, eine Zahl zu veröffentlichen, die wir nicht zitieren können. Dasselbe tun wir für öffentliche Beschaffung, Forschungsförderung und Unternehmensdaten.