Contradicted by the source
“Un repost vale 20 veces un 'me gusta'.”
RetweetWeight es 1.0 y FavoriteWeight es 0.5, por lo que un repost tiene el doble de peso que un 'me gusta' — no veinte veces.
De dónde viene: Ninguna versión publicada del algoritmo usó 20. El ranker pesado de 2023 también ponderó el retweet en 1.0 frente al favorito en 0.5.
Was true, of an older version
“Una respuesta vale 27 veces un 'me gusta' (o 13.5 veces).”
ReplyWeight es 5.0 frente a FavoriteWeight 0.5, es decir, diez veces — y cuarenta veces entre seguidores mutuos, porque BidirectionalFollowReplyWeightBoost añade 15.0 al peso de la respuesta para publicaciones originales entre cuentas que se siguen mutuamente.
De dónde viene: Ambas cifras fueron reales, para un modelo que ya no existe: el ranker pesado de 2023 publicó 27 el 31-03-2023, luego 13.5 el 05-04-2023. Describen un pipeline de Scala reemplazado por el actual de Rust.
Was true, of an older version
“Los clics en tu perfil valen 12 veces un 'me gusta'.”
ProfileClickWeight es 0.0. Un clic en el perfil no contribuye en nada a la puntuación ponderada.
De dónde viene: 12.0 fue el peso de 2023 para `good_profile_click` — una señal compuesta diferente (abrir un perfil Y luego dar 'me gusta' o responder). El modelo actual tiene un encabezado de clic de perfil simple, ponderado a cero.
No such parameter exists
“Un marcador vale 10 'me gusta' — los marcadores son la señal más fuerte.”
No hay peso de marcador en param.rs, por lo que los marcadores no entran en la puntuación ponderada en absoluto. Sin embargo, no son invisibles: bookmark_count se hidrata en cada candidato como una característica del modelo, y ClientTweetBookmark cuenta como una interacción positiva en el historial del espectador. Leído, pero sin ponderar.
De dónde viene: La actualización de Scala de 2025 declaró un parámetro home_mixer_model_weight_bookmark — con un valor predeterminado de 0.0. Ninguna versión publicada lo ponderó jamás en 10.
Lo que buscamos, en el commit fijado
No hay peso de marcador en param.rs
bookmark · 2 archivos · 0 coincidencias
bookmark_count se hidrata en cada candidato como una característica del modelo
bookmark_count · 1 archivo · 5 coincidencias
ClientTweetBookmark cuenta como una interacción positiva en el historial del espectador
ClientTweetBookmark · 1 archivo · 1 coincidencia
Right numbers, wrong reading
“Un reporte cancela 468 'me gusta' (−234.0 ÷ 0.5).”
La aritmética es correcta y la conclusión sigue siendo errónea. Los pesos multiplican una PROBABILIDAD PREDECIDA, no un recuento de acciones. X afirma que la probabilidad base de un reporte es más de mil veces menor que la de un 'me gusta', por lo que dividir un peso por otro no da una tasa de cambio entre acciones.
De dónde viene: Este no está obsoleto — es una mala interpretación de números correctos, y aparece incluso en páginas que publican la tabla correcta. X añadió una advertencia explícita al respecto en su propio README el 14-08-2026.
No such parameter exists
“La velocidad de interacción cuenta 1000×, la autoridad del autor 50×, la actualidad 22×.”
No existe ningún parámetro con nombre para velocidad, autoridad o actualidad en param.rs. La edad no es un peso en absoluto, es un corte estricto: AgeFilter elimina cualquier publicación con más de MAX_POST_AGE, una constante compilada de 48 horas. Nada multiplica la puntuación de una publicación por su frescura.
Lo que buscamos, en el commit fijado
No existe ningún parámetro nombrado para velocidad, autoridad o actualidad en param.rs
velocity|authority|recency · 1 archivo · 0 coincidencias
AgeFilter descarta cualquier publicación anterior a MAX_POST_AGE
AgeFilter::new\(.*MAX_POST_AGE · 1 archivo · 1 coincidencia
Contradicted by the source
“Un grupo coordinado puede enterrar tu publicación mediante informes masivos o bloqueos masivos.”
X aborda esto directamente en los comentarios de param.rs, y el mecanismo que describe es verificable: el modelo predice TU probabilidad de una acción, por lo que las recomendaciones son personalizadas; los informes de una brigada afectan principalmente lo que se recomienda a personas similares a esa brigada. Y una interacción solo cuenta si ocurre en una publicación servida en la línea de tiempo de inicio: navegar directamente a una publicación, por ejemplo, desde un chat grupal, no tiene impacto en la clasificación.
De dónde viene: Una inferencia razonable a partir de los pesos negativos muy grandes, que los pesos por sí solos no respaldan.
Lo que buscamos, en el commit fijado
Was true, of an older version
“X publicó el código pero retuvo los pesos de clasificación por razones de seguridad.”
Verdadero para la versión de enero de 2026, falso desde el 13 de agosto de 2026. Los valores numéricos predeterminados ahora están en param.rs, y X afirma que los scripts cron los mantienen iguales a los valores de producción principales.
De dónde viene: Informes precisos de la caída de enero de 2026, nunca actualizados después de agosto.
Lo que buscamos, en el commit fijado
Contradicted by the source
“Las publicaciones que contienen enlaces externos son clasificadas a la baja.”
En el código de clasificación publicado, OpenLinkWeight es POSITIVO en 0.2 y se aplica incondicionalmente; abrir un enlace es recompensado. Los enlaces solo se penalizan a través de etiquetas de seguridad como MALICIOUS_URL y DO_NOT_AMPLIFY, que se refieren al destino, no a la acción de enlazar.
Lo que buscamos, en el commit fijado
Los enlaces son penalizados solo a través de etiquetas de seguridad como MALICIOUS_URL
MALICIOUS_URL · 7 archivos · 1 coincidencia
… y DO_NOT_AMPLIFY
DO_NOT_AMPLIFY · 7 archivos · 1 coincidencia
Contradicted by the source
“Una marca de verificación pagada compra un impulso en la clasificación.”
No existe ningún multiplicador premium, verificado o de suscripción en param.rs, y ningún re-puntuador de este tipo aparece en los puntuadores publicados. El código de 2023 sí incluía uno — multiplicadores de 4.0 en la red y 2.0 fuera de la red para autores con verificación Azul — y ha desaparecido del árbol actual. Límite honesto: Phoenix es un modelo aprendido cuyos pesos no se publican, por lo que una correlación aprendida no puede excluirse leyendo el código.
De dónde viene: La pipeline Scala de 2023 realmente aplicó un multiplicador de 4.0 / 2.0 para la verificación Azul.
Lo que buscamos, en el commit fijado
No existe ningún multiplicador premium, verificado o de suscripción en param.rs
premium|verified|subscription · 1 archivo · 0 coincidencias
ningún reevaluador de este tipo aparece en los evaluadores publicados
premium|verified|subscription · 8 archivos · 0 coincidencias
Contradicted by the source
“X ahora publica solicitudes de eliminación gubernamentales en su repositorio de código abierto, y Brasil es el único país listado.”
El repositorio publica el MECANISMO de aplicación, nunca una solicitud. Las reglas que eliminan una publicación para los espectadores en un país restringido — LegalTakedown y LocalLawsTakedown — leen un motivo que contiene el código de país, pero ese motivo se obtiene en tiempo de ejecución de un servicio no publicado, y el tipo que lo contiene (TakedownReason) se define en un 'crate' ausente del repositorio. X también publica la infraestructura alrededor de ese tipo, en Scala: un filtro de lectura 'gizmoduck' que elimina las eliminaciones no aplicadas antes de que una lectura regrese, una columna y transformación del Servicio de Entidades de Tweets que recupera los motivos de eliminación de una publicación, y los trabajos internos que convierten esos motivos en las etiquetas que se muestran a una cuenta sobre sí misma. Así, las estructuras Thrift que lo contienen — Takedowns { country_codes, takedown_country_reasons } — son leídas por código publicado, en 3 archivos: `takedowns/gizmoduck/RedactUnenforcedTakedownsFilter.scala`, `takedowns/tweet-entity-service/TakedownReasonsTransform.scala`, `under-the-hood/scalding/UthPctdAccountTakedownEventsJob.scala`. Lo que eso añade es más MECANISMO, no una solicitud: en el 'commit' fijado, ningún código de país está escrito junto a un motivo de eliminación fuera de los 'test fixtures' — los únicos códigos de dos letras que el código de eliminación contiene son `xx`, `xy`, los centinelas mundiales que la fuente nombra, que significan 'en todas partes' y son lo opuesto a un país. Y el método que solicitaría esos códigos al Servicio de Entidades de Tweets bajo su propio nombre, get_takedown_country_codes, no aparece en ninguna parte del repositorio. Brasil es algo completamente diferente: una lista codificada de 2795 cuentas reportadas al Tribunal Electoral, obtenida del conjunto de datos de candidatos públicos, eliminadas de 'Para Ti' para todos los espectadores a nivel mundial a menos que sigan la cuenta — sin ninguna condición de país, lo cual es lo opuesto a cómo funciona una eliminación legal aquí. Límite honesto: un repositorio sin un país codificado no es una plataforma sin eliminaciones por país. Las solicitudes existen; viven fuera del repositorio, agregadas, en el Centro de Transparencia y el informe DSA.
De dónde viene: La propia publicación de X del 14 de agosto anunció dos cosas: los pesos de clasificación y el filtro electoral de Brasil. Musk lo citó al día siguiente en 61 caracteres — "Cualquier censura requerida por los gobiernos ahora es claramente visible" — sin nombrar el repositorio, ni las solicitudes, ni los países; la prensa lo vinculó a un aviso para el usuario que fue anunciado, no implementado. Las palabras "solicitudes" y "en el algoritmo de código abierto" aparecen juntas por primera vez en una cuenta agregadora.
Lo que buscamos, en el commit fijado
La infraestructura Scala publicada lee las estructuras de retirada Thrift — Takedowns { country_codes, takedown_country_reasons }
\bTakedowns\b|\btakedownCountryReasons\b · 43 archivos · 15 coincidencias
Contradicted by the source
“Silenciar una palabra clave oculta cada publicación que la contiene.”
Una palabra clave silenciada no es una sola regla. El servicio de línea de tiempo publicado lo aplica con 2 filtros que no leen el mismo texto: ViewerMutedKeywordFilter, registrado en phoenix_candidate_pipeline.rs, lo compara con tweet_text; FollowingViewerMutedKeywordFilter, registrado en reverse_chron_posts_pipeline.rs, lo compara con ancestor_texts, quoted_tweet_text y tweet_text. Los campos que solo algunos de ellos leen — ancestor_texts y quoted_tweet_text — son escritos por conversation_gap_ancestor_hydrator.rs, quote_hydrator.rs y quoted_post_text_hydrator.rs, registrados en phoenix_candidate_pipeline.rs, phoenix_scores_pipeline.rs y reverse_chron_posts_pipeline.rs. Una 'pipeline' que no ejecuta esos 'hydrators' nunca los llena: allí el texto de una publicación citada o ancestral no solo no se lee, sino que está ausente. Más allá de la línea de tiempo, el motor de reglas de filtrado de visibilidad — la capa que puede ocultar una publicación dondequiera que aparezca — contiene ViewerMutesAuthor (Mutes) y ViewerMutesRetweets (MuteRetweets), y ninguna regla cuya decisión lea una palabra clave. El único resultado de palabra clave silenciada que este repositorio nombra, MatchesMutedKeyword, aparece exactamente 1 vez — en graphql_results.rs — y solo a la izquierda de un 'match arm' que lo mapea a una etiqueta intersticial. Nada aquí lo decide; lo que lo haga no está publicado. Dos límites honestos. Este repositorio es el servicio que construye una línea de tiempo: lo que hace el silenciamiento en las notificaciones o en la búsqueda se decide en otro lugar, en código que X no publica, y una ausencia aquí es una ausencia del repositorio, no del producto. Y no le decimos qué pestaña sirve cada 'pipeline' — ese cableado atraviesa varias capas, y un mapeo que no podemos extraer limpiamente es un mapeo que no publicamos.
De dónde viene: Silenciar es una única configuración en el producto, por lo que se interpreta como una única regla que se aplica en todas partes. El código publicado muestra algo más limitado: una palabra clave silenciada se aplica mientras se ensambla una línea de tiempo, y los filtros que la aplican no leen todos el mismo texto — por lo que una publicación puede contener la palabra en un lugar que ningún filtro en esa ruta jamás examina.