Foundation Model Monoculture

Algorithmic monoculture is the situation in which many decision-makers rely on the same model, or on models that share components such as training data. It creates two different risks for a delegation stack:

Correlated errors in ordinary operation. If the actor and its checks, or many firms’ checks, make the same mistakes, layering them buys less than independence predicts. This is passive entanglement.
Correlated vulnerability to an adversary. An input crafted against one model often works against related ones, so one attack defeats every layer that shares the weakness. This is the hijack channel at scale.

The literature

The idea predates large language models. Kleinberg & Raghavan (2021, PNAS) show that when many decision-makers converge on one algorithm, collective decision quality can fall even if that algorithm is more accurate for each of them alone. Harm arises in normal operation, not only under shocks. Bommasani et al. (2021) named homogenization as a defining property of foundation models: defects in one model are inherited by everything adapted from it. Bommasani et al. (2022) define outcome homogenization, the extent to which the same individuals receive bad outcomes from every decision-maker, and find on fairness benchmarks that sharing training data reliably increases it. In deployed commercial ML APIs, Toups et al. (2023) find users misclassified by every available model, and find that model improvements rarely reduce this systemic failure, because the gains go mostly to users other models already handled: the ecosystem-level analogue of the common-cause floor.

Measurements on current language models:

Kim et al. (2025) evaluate more than 350 models. Errors are substantially correlated: on one leaderboard dataset, two models that both err give the same wrong answer 60% of the time. Shared architecture and shared provider increase correlation, and larger, more accurate models have highly correlated errors even across architectures and providers.
Goel et al. (2025) define CAPA, a chance-adjusted measure of overlap in mistakes. They find that LLM judges favor models similar to themselves, and that models’ mistakes grow more similar as capability increases.
Panickssery et al. (2024) find that LLM evaluators score their own outputs above others’ that humans rate as equal, and that the strength of this self-preference rises with the model’s ability to recognize its own text.

Kim et al.’s released pairwise data are enough to compute the statistic the site’s correlation correction needs, the common-cause weight ρ between two models’ misses. On MMLU, for models scoring above 80%, it is about 0.58 across providers and 0.69 within one (Measuring Entanglement). Benchmark label noise inflates these figures, and no study reports the correlation of checks on harmful actions. Read together, the results say that a verifier from a different provider removes only a small part of the correlation.

The provider landscape is wider than the model landscape

There are several frontier developers and competitive open-weight model families (DeepSeek, Qwen, Kimi, Llama and Mistral among them). We have no data on deployment concentration and make no claim about its trend.

Provider count overstates independence because the sources of correlation are shared across providers: mostly transformer architectures, heavily overlapping web-scale pretraining data, similar post-training methods, distillation from and synthetic data generated by other labs’ models, and optimization against the same benchmarks. The Kim et al. finding that accurate models converge across providers is the measured consequence. Architecture alone may not help either: in Goel et al.’s one test, a Mamba model’s mistakes stayed closer to those of a transformer from its own developer than to those of other developers’ transformers.

Within a single deployment, model dependencies are also easy to miss. Embedding models in a vector store, guard and moderation models, rerankers, monitoring tools and the coding assistant that wrote the glue code may all come from the provider the “independent” verifier was meant to avoid.

Adversarial transfer

Adversarial examples were first found to transfer between image classifiers with different architectures and training data (Szegedy et al. 2013), reliably enough to attack commercial models through a locally trained substitute (Papernot et al. 2016). Those transfer rates do not carry over numerically to language models, but the pattern does. Zou et al. (2023) optimized adversarial suffixes against open models and found that they also worked on the commercial chat models of the time. Later work shows that defenses fall to attackers who adapt to them: tuned attacks bypassed 12 published jailbreak and prompt-injection defenses, most with success above 90% (Nasr et al. 2025), and a staged attack took a layered classifier pipeline from 0% to 71% attack success, reaching 33% when built without access to it (McKenzie et al. 2025). Two consequences for a delegation stack:

Open weights are a surrogate for closed ones. An attacker can optimize against an open model and expect partial transfer to a closed verifier.
A learned check on a related model is not an independent filter for adversarial inputs. The site’s rule is to assume ρ → 1 among learned checks when the attacker chooses the input (Formal Definitions). No published table gives transfer rates between particular checks; measure transfer in your own stack.

Measuring it in your stack

Run every check on two sets, natural failures of the actor and adversarial inputs optimized against an open surrogate model, and compute the mixture weight ρ for each pair on each (Measuring Entanglement). Expect the adversarial value to be much higher. It is still a lower bound: a fixed set of transferred attacks is not an attacker adapting to your stack, which only a control evaluation measures.

Risks beyond one stack

One exploit, many victims. If many firms’ fraud or content checks run on the same model, a bypass found once works everywhere, and the attacker’s research cost is amortized across all of them.
Simultaneous updates. A provider’s model update changes every dependent system at once. In late April 2025 OpenAI rolled back a GPT-4o update in ChatGPT after it made the model markedly more sycophantic, a change it attributed to weighting short-term user feedback too heavily (OpenAI).
Inherited behavior. Models fine-tuned on another model’s outputs inherit its errors along with its skills, and can inherit traits the data does not visibly carry. Students trained only on number sequences from a teacher acquired the teacher’s traits, including misalignment, even after filtering, though only when both shared a base model (Cloud et al. 2025).

Mitigations

Inventory model dependencies, including embeddings, guard models, monitors and libraries, not only the main model.
Diversify method on the verification path. Rule-based checks, formal properties, execution-based tests and human review fail for different reasons than a second LLM does. A different provider is the weakest form of diversity. No form helps if every check reads the same poisoned input (Solutions).
Do not let a model family grade itself. Self-preference and similarity bias in judges are measured effects.
Prefer verifiers not distilled from, or fine-tuned on the outputs of, the model they check, and not built on its base model. Filtering the training data is not enough. You rarely control a commercial model’s pretraining data, but you do choose what your own verifiers are trained on.
Set a correlation budget, for example “no two layers share a model family”, and pin model versions so that a provider update is a deliberate change you test before rollout.
Keep a tested fallback that does not depend on the primary provider.

Monoculture is also a collective-action problem: each deployer rationally picks the best model, and correlated failure is an externality borne by everyone (Regulatory Approaches).