A knowledge base is only half a brain. The other half is the model — and the moment you have more than one document class, “which model” stops being a preference and becomes a routing decision. I answer it with two engines: a cloud one for what is not sensitive, and a local one for what is. This post is about the cloud half and the single rule that keeps it honest.
This is Part 3 of 6 in the Building a Private Local-AI Stack series.
- The Use Case
- LightRAG as a Personal Knowledge Base
- OpenRouter and the Case for Safe Models (this post)
- Right-Sizing a Local LLM with llmfit
- AionUi: A GUI for Your CLI AI Agents
- Basic Memory: An AI Memory in My Obsidian Vault
One API, One Key, No SDK Churn
The model landscape moves too fast to marry a single provider. Last quarter’s obvious choice is mid-tier now, the good one is behind a different API, and I did not want my agents littered with provider SDKs — each a separate thing to break.
OpenRouter solves that. One endpoint, one key, one request format. Behind it, a catalogue of models from every provider that matters. I change which model an agent uses by changing a string. No new SDK, no auth dance, no code rewrite. For a stack meant to outlive any given model generation, that indirection is valuable on its own.
But the feature that made me adopt it is not the breadth. It is the control.
Pinning: Predictability Over Convenience
By default, an aggregator routes you to whoever is cheapest or fastest right now. Two providers serve the same model? It picks one. That one goes down? It falls back. For a chat toy, fine. For an unattended automation stack, a liability.
Here is the problem, and I hit it early. I have not vetted every provider in the catalogue. I vetted some — read their terms, checked their retention posture, decided I am comfortable sending them non-sensitive work. If the router is free to fall back to a provider I never looked at, my vetting is theatre. My request lands somewhere I did not choose, under terms I did not read, and I find out never — or worse, I find out when a bill arrives from a provider I did not know I was using.
OpenRouter lets me shut that door. I pin a specific provider and disable fallbacks. One of two things happens: my request goes to the provider I vetted, or it fails outright. It never quietly reroutes to a stranger. A hard failure I can see and handle. A silent switch to an unvetted provider is the thing I fear, and pinning makes it impossible.
Concretely: I can pin to Amazon Bedrock for a model several providers offer, and tell OpenRouter that if Bedrock cannot serve it, do not go elsewhere. I get the model under terms and a jurisdiction I chose, every time, or I get a clean error. That is the trade I want.
Predictability matters because unattended automation that behaves differently depending on which provider won the routing lottery is an agent I cannot reason about. I learned this the hard way when an agent that had been working fine for weeks started returning different output for the same input. The diff was subtle — phrasing changes, slightly different answers to the same question — and it took me an afternoon to figure out the router had started sending half the requests to a different provider that served the same model name but with a different quantization. Same API, different behaviour, zero visibility. Pinning fixed it. Model fixed, provider fixed, behaviour repeatable. When I change one now it is because I decided to, not because a load balancer did.
What Makes a Model “Safe”
This is the part that earns OpenRouter its place in the stack: I deliberately route non-sensitive documents to vetted cloud models. Not grudgingly — as the primary path. Most of what my agents touch is not sensitive. Public notes, reference material, draft prose, code I would paste into a gist, “summarise this article” jobs. For all that, a good cloud model is faster, more capable, and cheap enough that running it locally is waste. There is no privacy argument against sending content that is already public.
So the question is not “cloud or local.” It is “is this model safe for this data class.”
A model is not safe in the abstract. It is safe for a given sensitivity class or it is not. I judge that on three things, and I actually read the fine print each time before I pin a provider.
Provider terms. What does the contract permit them to do with my input? I read the terms of the specific provider I am pinning to — not the marketing page, the actual terms of service. The pinning discipline makes this meaningful. Vetting terms is pointless if the router can reroute past them.
I have walked away from providers whose terms were too vague on input usage. “We may use your content to improve our services” is a red flag I will not tolerate even for non-sensitive work, because “improve” is a weasel word that can mean training and I do not want my public notes teaching someone else’s model without explicit opt-in. If the contract does not explicitly exclude training, or if opting out requires an email to support instead of a checkbox, I do not pin that provider. Period.
Data-retention and training policy. Do they retain prompts? For how long? Do they train on inputs by default, and can I turn that off with a config flag I control? A provider that trains on content might be fine for a blog draft and disqualified for anything I would not want resurfacing in someone else’s output.
The retention window matters too. “We delete after 30 days” is different from “we delete after you close your account,” which is different from “we retain indefinitely for compliance.” I pick providers that state a retention window I can live with for the data class I am sending.
Jurisdiction. Where does the request land physically, whose law governs it? For non-PII work this is a soft factor, but still a factor. I prefer requests landing under a jurisdiction whose data laws I actually trust. Pinning to a named provider lets me control that instead of leaving it to whichever CDN edge the router feels like this hour.
A model clears the bar when all three line up for the data class I am sending. The same model can be safe for public notes and unsafe for anything personal. “Safe” is a relation between a model and a kind of data, never a property of the model alone. Keeping that straight is most of the discipline, and it is why I keep a short written list of which providers I have vetted for which data classes. When an agent asks for a model, I do not guess — I check the list.
The Line Personal Data Never Crosses
Here is the rule: PII and sensitive documents never touch any cloud model. Full stop.
Not the vetted ones. Not the pinned ones. Not the provider with the spotless retention policy. The safe-model machinery I just described is a tool for the non-sensitive half, and it stops at the sensitivity boundary from Part 1. Anything personal, financial, or private does not go to OpenRouter at all, no matter how good the terms look. Vetting reduces risk; it does not eliminate it. For data that would genuinely hurt to leak, “reduced risk” is not the standard. Zero exposure is.
The reason I hold this line is that the failure mode is irreversible. A public note sent to a provider that trains on it is an annoyance. A sensitive document in someone else’s training corpus is a fact I can never take back. Encryption at rest, deletion endpoints, retention promises — all of it is a bet the provider is competent, honest, and never breached. For non-PII work that is a bet I am happy to make. For the sensitive half it is a bet with no upside worth the downside, so I do not make it.
That is why sensitive work stays on a local model, on my hardware, where the request never leaves the machine and no third party’s policy is load-bearing. OpenRouter handles one side of the split — the non-PII side — and handles it well. The other side runs on iron I control, and no amount of vetting moves a private document across that line.
Which raises the question: if the sensitive half runs locally, which local model, on hardware that is not a datacentre? Picking one that fits real constraints is harder than it sounds, and I stopped guessing once I found the right tool.
What’s Next
The cloud engine is settled: OpenRouter, pinned providers, no fallbacks, safe models for non-sensitive work. The local engine is the other half of the boundary, and it has to earn its keep on hardware I own. Part 4 is right-sizing that local LLM with llmfit — how I stopped guessing which model fits and started measuring it.
Any opinions in this article are my own.