The only way to be safe from these issues is if you run the models locally, yourself.
I don't think it's really necessary to run the models locally unless you're worried about privacy. A rented GPU from somewhere like RunPod is probably fine. They have no incentive to quantize your models (why would they want you to use cheaper hardware?), and it would be hard for them to do even if they wanted to since you're running arbitrary code.
I'm actually in the middle of running an experiment using GPT-OSS-20B on rented A40's from RunPod (not using API access for exactly the reasons in your post), and it's a little bit more annoying but not that expensive[1], and I would be pretty surprised if they were messing with the code I'm running. You can even parallelize via SkyPilot, although RunPod's quality control is pretty terrible so you need to make sure the machine actually booted and has a GPU (but it's obvious when RunPod machines break -- you're not going to get seemingly good results, the code just won't run at all).
The conversation can't be shared because it used Deep Research mode, but:
For batch workloads (thousands of prompts, spin up → run → tear down, no interactive debugging), renting GPUs costs roughly the same per token as the API, sometimes less. GPT-OSS-120B on a single H100 runs ~$0.14–0.46/M output vs OpenRouter's ~$0.10–0.19/M. DeepSeek-R1 in reference FP8 needs 8×H200 (685GB of weights won't fit in 8×H100's 640GB) and lands near $3/M output vs OpenRouter's $2.50/M — parity. On B200 both models are plausibly several times cheaper than the API.
Three conditions on that:
LLM.generate() over the whole prompt list), not an HTTP server with a rate-limited client. Batch-of-1 throughput is 10–100× worse and blows up the per-token cost entirely.hf_transfer, or a network volume if you're iterating.Claude is a little bit optimistic here because RunPod's quality control is so bad, but I think it's within the right order of magnitude.
You're right, sorry.
When I wrote "locally, yourself" I was thinking of either having or renting GPUs to run your models. I should have written "on hardware you control."
For my use case, I sadly care a lot about "interactive debugging". I'm iterating on prompts, control protocols, and models, so if I was running on rented GPUs they would be idling for a long time between experiments.
I don't know too much about the details of running models on rented GPUs, but after looking into OpenRouter for the post, I am inclined to learn. Thanks for sharing!
Cerebras’ “We are committed to serving the original models for all existing endpoints, without modification”.
I actually considered using Cerebras for an experiment, but you'd have to design your entire experiment around them since they only offer three models in the non-enterprise API (and are only committed to continuing to serve one of them).
Please share this with anyone doing AI research with 3rd party providers so that they can ensure their research won’t be corrupted.
This is a tangent I took for a few days during the Pivotal AI Safety Research Fellowship. I’m doing an AI Control project mentored by Adam Kaufman and James Lucassen of Redwood Research and partnered with Aniruddh Pramod.[4]
This blog post is a human-written summary/analysis of a pile of information requested by Matthew and discovered by Claude.
OpenRouter Kills an AI Safety NeurIPS Paper
In R1 CoT illegibility revisited from April 2026, nostalgebraist revisited the findings in the NeurIPS 2025 paper Reasoning Models Sometimes Output Illegible Chains of Thought by Arun Jose. It turned out that even when using an inference provider with the same quantization (fp8, “as far as [nostalgebraist] could tell”), different providers serve different models with drastically different capabilities and chain-of-thought legibilities. Arun conceded:
“I think this is pretty convincing re your original argument that my results were contaminated by bad inference setups, and that correspondingly my paper doesn't substantiate some of its claims and conclusions with good evidence.”
While trying to set up our research codebase for an AI Control project[5] so that it would be easy to perform many experiments and know what led to the results, I came across the curious fact that different OpenRouter model providers serve models at different quantization levels. Looking into it further, it turns out that OpenRouter has barely any quality control, and providers are free to reduce quality to achieve lower costs. This stunned me, since I had always assumed that if you ask for model X from OpenRouter, OpenRouter has to give you responses from model X. That is essentially not true. My colleagues at the Pivotal Fellowship were similarly surprised.
Background
OpenRouter’s providers can:
Some people have discussed these issues before but there is evidently not enough awareness, since 31/32 searched AI Safety codebases that report results from OpenRouter, including recent ones in active development, open themselves up to data quality issues. Though OpenRouter describes this behavior in its documentation, most researchers are unaware it is potentially corrupting their results.
Prior work/writing on the subject.
This is just a selection. For more prior work see Claude’s Report.
Image from https://x.com/xlr8harder/status/1974859337387651125:
No Guarantees from Fixing a Provider
Although selecting a provider cuts down on a major source of variation, it does not guarantee that each time you request the provider for a model, you get the same model.
I had Claude look through a large number of model providers and figure out the extent to which they report what they serve, how it has changed over time, and their notice policy for changes in the future. All 10 audited had gaps. Fixing a provider is still the best practice available when using 3rd party providers, but unfortunately it falls short of ideal.
No Guarantees From Large N
You might hope that provider-routing would introduce some noise but that as long as the researcher had a large enough sample size and reported the standard deviation, then the research results would still be meaningful/replicable. Unfortunately, this is not necessarily the case. OpenRouter does not assign providers purely randomly. For example, if a provider goes down, your requests will be sent to the remaining providers. There are no guarantees of performance or of randomness. Researchers should assume that OpenRouter behaves adversarially. It is possible that if you ask for GPT-OSS-120B on Monday to do your baseline run, you’ll get a dumb/quantized/truncated model, and if you ask for GPT-OSS-120B on Tuesday to do your experimental run, you’ll get a smarter model, and your intervention will seem to have helped.[6]
No Guarantees from “The Benchmark Didn’t Move”
OpenRouter has and is continuing to develop an “Auto Exacto” “...step that automatically optimizes provider ordering for all requests that include tools. It runs by default on every tool-calling request, requiring no configuration.” I consider it to be an insufficient measure.
No Guarantees from “Choose the Most Expensive Provider”
It would be great if we could just select the most expensive endpoint to get the one which is most faithfully served. Unfortunately, that is not the case. We found that for `meta-llama/llama-3.3-70b-instruct`, originally in bf16, the most expensive endpoint is in fp8, a cheaper one exists in bf16, and the cheapest is once again in fp8. This also hints that even within a fixed quantization, price doesn’t perfectly track quality.
No Guarantees from “Set a floor”
Some research codebases we reviewed set a quantization floor. Although this can protect them from the most lossily-compressed int4 models, it doesn’t protect them from the great variability which can exist within a higher quantization level.
When is Default OpenRouter Fine?
If you are measuring capabilities, comparing models, harnesses, or setups, measuring subtle propensities or safety behaviors, generating training data, or need reproducibility, default OpenRouter is not fine.
Developing Best Practices
Even with all of this, there is no way to actually be able to rely on providers. But researchers have limited alternative options, and self-hosting is too expensive and cumbersome for most research.
Spotting Fingerprints
Nostalgebraist’s experience with different model providers allowed him to see signs of a degraded model in Arun Jose’s CoT legibility results. Identifying the effects of provider degradation on a model is not always possible for a few reasons:
If you want to attempt detective work, there are some things you could attempt. If there are transcripts available, you can check for token soup, special tokens where they don’t belong, and bad formatting (eg for reasoning tokens). There might be subtle disconnects between what the researchers say they did (eg set a temperature) and what they actually got (maybe the model provider didn’t respect the temperature parameter. Did the temperature impact the outputs as expected?).
The absence of visible fingerprints of bad inference is very weak evidence that the inference was done properly, and this type of detective work should not be relied upon.
Claude’s attempt at a taxonomy of fingerprints.
Highlighting Some Impacted Work
Exploring the 35 AI Safety repos Claude found that mention “OpenRouter”, 34 called OpenRouter and 32 use OpenRouter for their reported results. 31 out of 32 (all except nostalgebraist) were vulnerable to corruption. It would require deep knowledge of the results and setups to say whether the findings were actually impacted. See the Artifact to explore Claude’s findings for yourself.
Here are some highlights, linked to the line in which a model is called without a provider.
Should The Community Do Something About This?
Fixing Repos
Some important repos upstream of AI Safety research such as Redwood’s BashArena and Control Tower and others do not support best practices. Maintainers of these repositories should update them ASAP. I’ve already made a PR to Control Tower.
Replicating Research
Like nostalgebraist, we should work to identify which important work has the potential for its results to have been affected by this bug. Claude Fable or GPT-Sol could probably get a long way to fixing and replicating these results autonomously, and I encourage someone to do so (if you are working on OpenRouter-reliability replications please make a GitHub Issue on my Repo to coordinate!).
A New Org?
Even with all of these workarounds, we still have to place a lot of trust in the model providers which they frankly haven’t earned. It is impossible to rule out that even with all of my suggested precautions in place, an individual provider, when asked for tokens, routes some requests to one model and some to another. There is no FDA or SEC for model providers that ensure that their marketing claims are true.[11][12] A provider can change how they serve their models and not give any notice or warning. Imagine the confusion and sunk time that would occur if two chemicals with the same chemical formula had radically different properties, only one of which explodes.
The only way to be safe from these issues is if you run the models locally, yourself (edit: I should have said "on hardware you control", rather than "locally"). Then you can report your setup for reproducibility and criticism. But that’s a huge tradeoff. OpenRouter-provided models are usually much cheaper and easier to work with than having to manage your own infrastructure. They also allow for much greater parallelism, which is invaluable for quickly running most research (e.g. evaluations and control research).
The AI Safety Community should consider creating an organization to provide standardized access to models. Researchers should be able to call on it to provide the same model, provided the same way, every time it is called (unless explicitly requested by the researcher). Until the AI Safety scientific community figures out best practices and sets up good shared infrastructure, we will have difficulty escaping our ignorance.
Although I primarily looked into OpenRouter, I am under the impression that other multi-provider routers such as Requesty, Vercel AI Gateway, Unify, and Martian suffer from the same issue. Single-provider hosts don’t have switching and avoid some, but not all, of the problems, making them similar to “pinning a provider”.
By ‘safely’, we mean that the data produced by experiments calling that model are trustworthy in the sense that the request really was made as the researcher sent it.
Other things to keep in mind: data_collection defaults to ‘allow’, so be careful before sending proprietary information in requests. And keep an eye on which providers include caching for decreased cost and increased speed. This is not the focus of this post, but it is worth mentioning.
Thank you to Ethan Nguyen for giving me some feedback on this post.
The project is on extending AI Control protocols with “interrogations.” That means things like asking the untrusted model follow-up questions about why it took suspicious actions and making monitoring or control decisions informed by the answers. In future development, we plan to investigate more complex but similar protocols such as debate.
Nostalgebraist’s work is great. In his logs we can see that runs of GPQA use multiple providers of varying quality for QwQ-32B. From a single config, the provider mix ratios range from 90 Nebius + 10 DeepInfra for one run to 85 DeepInfra + 15 Nebius for another!
I wonder what OpenRouter’s incentives are. To what extent is OpenRouter aligned with users, and in particular, with researchers? I encourage economists to study and think about this.
I spend most of my time begging Claude “please please please fail loudly don’t secretly hide bugs”. If your provider is down, you should know.
Recording the providers can be really helpful here. I spent a little bit of time trying to find particular research results that are potentially impacted by bad inference. Because SpeechMap records their providers, we can tell that their results come from a variety of model providers, and their results on how models deal with controversial speech mixes together model variance and provider variance. In their case, this may be intentional/the right decision if they want to measure how models behave in “real world OpenRouter usage.”
I’m making PRs to fix some of these issues in Control Tower when they are relevant to my research.
AI Control dynamics would likely not be affected, but safety/usefulness frontiers might be.
Like Cerebras’ “We are committed to serving the original models for all existing endpoints, without modification”. Sounds great, and I’ll prefer them going forward. Still, who knows if that’s true?
Someone should be keeping a closer eye on model providers. OpenRouter says “[benchmark] data will be shown publicly soon but is not yet available on the site”. Until they do, someone else could step in. But this doesn’t eliminate the possibility providers are serving backdoored models or models that maintain accuracy but are different in other ways.