Bring your own model means the agent calls the provider directly with a key you hold, instead of routing your work through the vendor's account. It changes the economics, the privacy story and what happens the day your tool's pricing changes. It also changes what you can do when one model is bad at a particular task.
The difference between renting and owning
A subscription agent bundles three things: the software, a quota of model usage, and whatever routing the vendor applies behind the interface. The bundling is the product, and for many people it is worth it. The cost is that all three move together. When a vendor reshapes a usage plan, your effective price changes whether or not your workload did.
2026 was not short of examples. Plans were restructured mid-year, allowances moved from generous to tight, and several teams discovered an overage they had not been warned about. When the tool and the meter belong to the same company, there is no way to shop around: the model you get is the model the account grants you, and it may be quietly swapped for a cheaper one.
What you can actually connect
| Source | How it connects | Typical use |
|---|---|---|
| OpenAI, Anthropic, Gemini | First-party API with your key | The main build loop |
| OpenRouter, Groq, DeepSeek | Any OpenAI-compatible endpoint | Cheaper models, one bill, fallbacks |
| Ollama, LM Studio | Local HTTP server on your machine | Free, private, no key |
| MLX | Local server on Apple Silicon | Fast local inference on Mac |
| Claude Code, Codex | Driven as a provider through their CLIs | Your existing subscription, new UI |
Every row is a provider slot. Switching between rows does not rebuild the conversation.
The last row is the one people underestimate. If you already pay for a coding subscription, you can use that brain inside a different harness rather than paying twice. The CLI's own login is reused, sessions resume per thread, and the tool calls and diffs render the same way the built-in agent does.
Image goes here
/blog/bring-your-own-model-providers.png
Provider configuration screen with keys stored in the OS keychain
Show generation prompt
Editorial technical illustration, 16:9, flat vector. Abstract representation of a provider picker: three small cloud-shaped outlines and one laptop outline arranged in a row, each with a key-like abstract glyph. A small lock icon abstracted as a rectangle with a notch is present to imply OS keychain. Charcoal (#121212) background, grey (#8c8c8c) outlines, the lock area in indigo (#5560d4), ordered-dither dot texture, generous negative space. Mood: secure, minimal. No readable text, no logos, no watermark.
Why provider-neutral history is the real feature
Threads are stored as plain text, not as an opaque blob belonging to one vendor. That sounds like an implementation detail and it is the thing that makes switching possible. Compact it, hand the thread to a different model, and it continues. Fork a conversation at any message and restart it on a different provider entirely.
Some hosted agents cannot do this even in principle. There are documented cases of compacted sessions refusing to resume on a third-party model, because the compaction record only means something inside the vendor's own stack. If your history is the vendor's format, switching is a migration. If it is text, switching is a dropdown.
Local models change the arithmetic
A local model has no token bill, which makes it the natural home for everything in an agent run that is high volume and low risk. Summarisation during compaction, thread titles, planning a refactor, a sub-agent doing a broad grep: none of these need a frontier model and all of them happen constantly.
The industry finding is that a compact prompt helps far more than a big model. Teams running local models successfully cut their system prompt hard, dropped MCP schemas, and reserved context for the actual task. A local provider in the same slot as a cloud one lets you route by task type instead of running everything through the expensive path because that is all you had configured.
How Quaka picks a model
Quaka ships with OpenAI, Anthropic and Gemini as first-class providers, supports any OpenAI-compatible endpoint, and has Ollama and MLX as built-in local providers that need no key. Air-gapped mode refuses cloud and CLI providers outright, drops web search, keeps the browser on localhost and forces the sandbox offline, for when nothing is allowed to leave the building.
Spend is metered per turn whatever the source, so a local model can say it cost nothing instead of showing a zero by accident. For what that meter protects you from, the cost post walks through where the money actually goes.
Get an invite
Quaka is in private beta.
One email when your invite is ready. macOS, Windows and Linux, bring your own key.
Read the source on GitHubCommon questions
Do I need a separate subscription for each model provider?
No. Most providers offer pay-as-you-go API pricing with no subscription, and an OpenAI-compatible endpoint lets you use several through one key. Local models through Ollama or MLX cost nothing per token at all, you only pay for the hardware you already have.
Can I switch models halfway through a task?
Yes, if the agent stores history in a provider-neutral format. The new model sees the same conversation, the same tool results and the same project instructions. Some hosted agents lock a thread to one vendor once it has been compacted, so this is worth checking before you commit to a workflow.
Is my API key safe in a desktop coding agent?
It depends where they store it. The safe pattern is the operating system keychain, which keeps credentials out of the application database and any log files written next to it. Avoid tools that persist keys in plain text inside a settings file or a local JSON store.