Choosing an AI backend

Every AI feature in DiffGuardian flows through one router, and you pick the backend per job. That choice decides exactly where your code goes — nothing else does.

#The two kinds of backend

#Local models — code never leaves your machine

Point DiffGuardian at Ollama or LM Studio running on your machine. Requests go to localhost only. Nothing is transmitted anywhere.

• Available on every plan, including Basic.
• Works with no internet connection at all.
• The strongest privacy posture, and always available as a fallback.
• Quality and speed depend on the model and the hardware you run it on.

To set it up: start Ollama or LM Studio, load a model, then enable that provider in DiffGuardian's AI settings. The app connects over the local HTTP endpoint the tool exposes and lists the models it finds.

You can also point DiffGuardian at a model endpoint you host yourself, which keeps everything inside your own infrastructure.

#Cloud providers — bring your own key

Enter your own Anthropic, OpenAI, Google Gemini, Kimi or OpenRouter API key and your code is sent from your machine directly to that provider, authenticated with your key. It is never relayed through DiffGuardian.

• Requires Pro. On Basic the provider toggles and key fields stay visible — so you can see what Pro unlocks — but enabling one opens an upgrade prompt, and a key saved there will not be used.
• Billed by the provider, on your existing account — DiffGuardian does not resell tokens.
• Because it is your key, the data is governed by your own agreement with that provider. Commercial APIs, unlike the consumer chat products, generally do not train on API inputs by default; check each provider's API data-usage terms for specifics.
• For this flow DiffGuardian is not a data processor. The provider is your subprocessor.

Your keys are encrypted in your operating system's credential store (the Keychain on macOS) and used only on your device. They are never transmitted to DiffGuardian's servers, and you can remove them at any time.

#OpenRouter — one key, hundreds of models

OpenRouter is an aggregator rather than a model owner. A single OpenRouter key reaches roughly 400 models from every major lab — Anthropic, OpenAI, Google, Meta, Mistral, DeepSeek, Qwen and the rest — so you can put a different model on a different job, or try one you have never used, without opening an account and adding a card with each vendor in turn.

Because that catalogue changes weekly, DiffGuardian does not ship a fixed model list for OpenRouter the way it does for the direct vendors. Point a row in Settings → Model routing at OpenRouter and the model field searches OpenRouter's live catalogue, showing for each model:

• its context window,
• its price in USD per million input and output tokens, and
• whether it supports structured outputs, which the review path requires.

The catalogue is cached for a day and is only a browsing aid — an assignment is just a vendor and a model id, so you can type an id by hand and routing still works if the catalogue cannot be reached. Models you have used recently stay at the top of the list.

Two things worth knowing before you route a feature through it:

• The review path is schema-bound. Most OpenRouter models honour structured outputs, but not all of them do; the picker marks the ones that do not, so you can avoid assigning them to a feature that depends on it.
• Tool calls stay on Anthropic and OpenAI. The agentic loop that lets a review call repository and MCP tools runs on those two vendors directly, and does not run through OpenRouter. Everything else — reviews, Trace It, Ask, Explain, Polish — behaves normally.

Prompts are still tailored to the model underneath: DiffGuardian reads the vendor/model prefix of an OpenRouter id, so a Claude reached through OpenRouter gets exactly the prompt rendering a Claude reached directly would.

Billing is OpenRouter's, on your own OpenRouter account, at their prices. Your code goes from your machine straight to openrouter.ai — DiffGuardian never sees it.

#Which to use when

You are not locked in either way. Reassign a feature to a different backend, or fall back to local, at any time.

#One model per kind of work

Routing is per feature, not per account, so an expensive model does not end up doing cheap work. In Settings → Model routing you assign a vendor and model to each of:

The planner and the finding checker only run at the higher review-effort settings, and both are good places for a small, fast model.

#Benchmarking your local models

Local model performance is wildly uneven on the same hardware — one model can be an order of magnitude slower than another, and the fastest is rarely the one that reviews best. Settings → Local model benchmark runs the same sample diff through every reachable local model and puts time-to-first-token, tokens per second and the actual output side by side, so you can assign models on evidence rather than by guessing.

#Embeddings

Knowledge-base and repository embeddings are generated on-device by default, using a built-in local model and a local vector store. They are only sent to a cloud provider if you explicitly select a cloud embedding model.

#Next steps

• Knowledge bases and MCP servers
• The DiffGuardian MCP server
• Privacy and data handling