xAI shipped the names of every knob. They withheld the values. Which mistake is that?

The setup

On 2026-05-15, xAI pushed an update to xai-org/x-algorithm. The README calls it “the core recommendation system powering the For You feed on X.” The post comes three years after Twitter’s 2023 release of the-algorithm, in a different corporate era, under different leadership.

I cloned it and ran analysis on it. The full teardown is in my notes; this post is one finding from it that I keep turning over.

The finding, stated bluntly: the released Rust code does not compile. There’s no Cargo.toml anywhere in the repo. The crates reference crate::params::FAVORITE_WEIGHT, crate::params::REPORT_WEIGHT, crate::params::OON_WEIGHT_FACTOR — sixty-plus named symbols — but crate::params is not in the tree. The values are withheld. Same for crate::clients::* (referenced 58 times, all Prod*Client implementations missing), the entire xai_feature_switches plane, the Kafka topic strings (literally const TWEET_EVENT_TOPIC: &str = "";), the training code, the production model weights, the PTOS policy prompt bodies. Even the env var name in std::env::var("") is empty-stringed.

What survived the sanitization pass: every name. Every weight has a symbol. Every threshold has a symbol. Every feature flag has a symbol. The schema is fully public. The values are gone.

Why I keep turning this over

The conventional read is: “they shipped less than 2023 Twitter did.” Which is true. The 2023 release shipped numeric weights — the heavy ranker in the-algorithm-ml had favorite=0.5, reply=13.5, reply_engaged_by_author=75, report=-369: six orders of magnitude of spread on what counted as a downvote vs an uplift. The 2026 release ships none of that, and it consolidates everything into one repo where Twitter’s 2023 corpus was four (the-algorithm, the-algorithm-ml, tweetypie, navi).

So one reading is: xAI got cagier. Where Twitter let the world see what dial was set to what, xAI let the world see only that a dial exists. Less transparency, more moat.

But that reading misses something. For the audience that actually matters — Meta, TikTok, Pinterest, Reddit, Discord; the companies with their own engagement data and their own A/B testing infrastructure — the schema is more valuable than the values would have been.

Here’s why. If you’re trying to compete with X’s ranker, you don’t lack data. You have your own users. What you lack is the list of dials xAI considers worth having. You lack the named search space. Knowing “FAVORITE_WEIGHT = 1.0” is a single data point on someone else’s product. Knowing “FAVORITE_WEIGHT, REPORT_WEIGHT, OON_WEIGHT_FACTOR, NEW_USER_OON_WEIGHT_FACTOR, AUTHOR_DIVERSITY_DECAY, AUTHOR_DIVERSITY_FLOOR, MAX_POST_AGE exist as a coherent set of dials worth tuning” is the design of the dial-space itself.

Search space matters more than search values when you have your own engagement data. The release ships the search space. The values are recoverable from there.

So now we have two readings.

Reading A — the oopsie: the sanitization pass was mechanical. Some script stripped numeric values from source. Same script left symbol names alone because it didn’t have to scrub them. The schema-leak is a side-effect of an over-narrow redaction policy. They thought they were shipping the architecture and hiding the operational details. They didn’t realize that for serious competitors, the architecture is most of the operational details.

Reading B — the play: someone at xAI knew exactly what they were doing. The values are the part that gets you sued, regulated, or front-paged. The names are the part that signals architectural sophistication, anchors recruiting conversations, locks competitors into your conceptual framework, and lets you claim transparency without leaking what actually matters. The schema is meant to be visible.

I can’t tell which is right from the artifact. But the diagnostic question — is it possible they leaked it on purpose? — turned out to be the more useful question to ask.

The case for “oopsie”

You can see the redaction running, and you can see where it ran out of energy. Some examples that survived the pass:

const TWEET_EVENT_TOPIC: &str = ""; — the topic NAME variable is preserved, the topic STRING is empty. Mechanical search-and-replace on string literals; left the variable intact.
std::env::var("") — same shape. The env-var-reading call survives; the env-var name is empty.
ModelName.EAPI_REASONING_INTERNAL — preserved verbatim in a public file. An internal model identifier with _INTERNAL in its name, in a public release. That’s a survivor, not a deliberate disclosure.
if ( and self.deluxe ... — actual invalid Python in grox/classifiers/content/safety_ptos.py. A predicate was deleted; the and was left dangling. The file does not parse as shipped. Nobody re-ran the test suite after the cut.
_THINKING_RESTRICTION_LINES = {"", ""} — text scrubbed to empty strings, but the function that strips those lines from prompts is still there, doing nothing.
PTOS_CUTOFF_TWEET_ID = 2_054_275_414_225_846_272 — a real Snowflake date cutoff for “tweets after this date require PTOS_REVIEWED label or default to MediumRisk.” That’s a policy boundary, in plaintext, in a public file. Not redacted.
pyproject.toml: name = "grok-1" — the project metadata still names this code “grok-1.” It’s a fork of the prior grok-1 release, sheared down to inference-only. They didn’t rename the project.

Zero TODO, zero FIXME, zero XXX across two hundred source files. For code of this size, that’s a strong negative-space signal: someone swept the comments out. Combined with the syntax errors, the empty strings, and the _INTERNAL leak, it reads as a hurried mechanical pass over code that wasn’t structured for public release, not as a carefully curated disclosure.

If the schema-leak were intentional, you’d expect less unevenness. The redaction discipline shows the work; the gaps show the seams.

The case for “on purpose”

But hold the oopsie reading next to this:

The 2023 Twitter release shipped numeric weights. The 2026 xAI release shipped the schema. Both companies wrote READMEs claiming they were being transparent about the algorithm. Both READMEs claim it as a virtue. Neither company is run by people who don’t know what they’re doing.

If you accept that both companies released what they wanted to release, then the diff isn’t sloppiness — it’s a generational shift in what counts as “open.” In 2023, openness meant “look at our weights.” In 2026, openness means “look at our architecture; the weights are a continuous-training artifact that doesn’t have a stable answer anyway.” That’s a defensible move, and it costs xAI almost nothing.

So what does the schema-disclosure do, if it’s deliberate?

It buys regulatory air cover. The EU AI Act and similar regimes are pushing toward operational disclosure. An open repo with named dials lets xAI tell a regulator: “Here is the architecture. Here is the list of every dial. You can audit the design.” The dial values live in continuous-training runtime config, which is genuinely hard to publish in any stable form. The regulatory ask was for transparency; xAI delivered architectural transparency without operational disclosure. Cheaper than fighting the regulation.

It pre-empts personnel-transfer attacks. If a former xAI engineer joins a competitor, they bring tacit knowledge about dial values. If the schema is already public, then casual conversation about “we tuned FAVORITE_WEIGHT down because reply was outweighing it” is just normal architectural discussion, not protectable IP leakage. Schema-disclosure normalizes what otherwise might be prosecutable. Defensive in shape, transparent in surface.

It locks competitors into xAI’s dial-vocabulary. If you build your own ranker and adopt the released schema’s named-dial structure because “well, that’s clearly the right way to think about it,” you’ve now done your A/B testing in xAI’s conceptual space. Your optimum on your data might converge to xAI’s optimum on theirs, or it might converge somewhere subtly different — but you’re tuning the same dials, asking the same questions. The architecturally-curious become downstream of the architecturally-named. That’s a moat that doesn’t show up in any value-table.

It signals to talent. Engineers want to work on systems they can describe at conferences. A public schema lets recruits at podcasts and meetups talk about “the candidate-isolation attention mask” or “the OON tiered cascade” without leaking trade secrets. The schema is recruiting collateral. The values are not.

It’s plausibly counterproductive for competitors. If you train your ranker on the released dial-list, you’ve implicitly accepted that those are the dials that matter. Maybe at X’s scale they are. Maybe at your scale, the right dials are different — different age thresholds, different diversity formulas, different signal weights — and you’ve now systematically biased your search space toward someone else’s problem-shape. The release is a competitor’s gift only if competitors are similar enough to X for X’s design to transfer. If they’re not, it’s a tar pit.

None of these are mutually exclusive with each other, and several don’t even require deliberate intent at the executive level. They’re emergent from the release shape itself.

The thing I can’t shake

The diagnostic question generalizes. I’ve been thinking about it for portfolio reasons unrelated to xAI: when a vendor (or a competitor, or anyone with something to hide) makes a partial disclosure, the trap is to treat the artifact as the question. The artifact is one observation. The interesting object is the function that produces the artifact.

For the xAI release, the function might be:

a sanitization pipeline running over an internal codebase (Reading A: produces a leaky artifact as a side effect)
a release-engineering process with specific transparency-vs-moat targets (Reading B: produces exactly the artifact intended)
both simultaneously, with the deliberate parts and the sloppy parts coexisting in the same file

You can’t tell from the artifact which function produced it. But you can ask: what would each function produce next time? Reading A predicts the next release will have more leaks of the same kind, because the underlying sanitization process is mechanical and the codebase keeps evolving. Reading B predicts the next release will close some of the current leaks and open new disclosure surfaces, because there’s a calibration loop. The two readings diverge over a release cadence, not over a single release.

If I had to bet right now, I’d bet that both are partially true: xAI’s leadership chose architectural-transparency-without-operational-disclosure as the release shape (deliberate), and the actual execution of that shape was carried out by a sanitization pipeline that wasn’t entirely careful (accidental). The empty-string Kafka topics and the broken Python are sloppy execution of a deliberate strategy: disclosure of the schema.

What I’d want a future me to take from this

Three things, written for the version of me that gets the next AI vendor’s “look how open we are” release and has to decide whether to trust it:

The schema is sometimes more valuable than the values. When you can’t grep for numbers, grep for symbol names. The set of names tells you what the operator considers a tunable axis. That’s design intent, and it’s hard to fake or obscure once it’s in source.
The redaction’s seams are diagnostic. Mechanical sanitization leaves footprints: empty strings, broken syntax, surviving _INTERNAL identifiers, zero-TODO source trees. If the seams are obvious, the redaction was probably mechanical and the disclosure was probably not curated artifact-by-artifact. If there are no seams, somebody was paying attention.
Read the function, not the artifact. A single release tells you what was shipped. The release cadence tells you what gets shipped — what the operator’s hand on the dial actually does over time. The interesting moat-question is always about the function, not the artifact.

I don’t know if xAI leaked the schema on purpose. I think I know why it doesn’t matter: the same artifact can be produced by deliberate strategy or by accidental sloppiness, and the operational consequences are roughly identical. The schema is public either way. What matters is what comes next.