You picked an AI coding tool. You signed in. Somewhere in that flow it either took your provider account or handed you its own model with no way to change it. It felt convenient for a week.
Then the model you relied on changed. Or the price moved. Or you needed to run a task on a plane with no network. And you found out the hard way that the model was not a setting you could edit. It was welded into the product, and swapping it meant swapping the product.
Bring your own model is the opposite bet. You supply the key. You point at the engine. The tool treats the model as a part, not as its own beating heart. That sounds like a checkbox. It is actually a decision about how the whole thing is built, and it has to be made before the first line of the product, not bolted on after.
A key you hold is not the same as a key they hold
Start with the boring plumbing, because it decides everything above it.
When a tool asks you to sign into its account and then calls the model for you, the relationship you have with the model provider runs through the tool. Your usage is their line item. Your rate limits are whatever they negotiated. Your data agreement is theirs, not yours. If they change plans, or get acquired, or decide your tier is no longer worth serving, that is your problem arriving through their door.
When you bring your own key, the account is yours. You hold the API key from Anthropic, from OpenAI, from whoever. The billing hits your card, under your terms. The rate limits are the ones you signed up for. The data-handling agreement is the one you read and accepted. The tool is a client pointed at your credentials, and it can be pointed somewhere else tomorrow.
This is not a small distinction for anyone handling code that is not theirs to leak. If you work under a client contract, or inside the EU, or with anything you would not want reused for training, “whose key is it” is the first question, not the last. A tool that resells you tokens through its own account has quietly inserted itself into a chain you are supposed to control.
It also decides what you can do the day the terms change. When the key is yours, moving to a different provider is a settings edit you make on your own schedule. When the key runs through the tool, you wait for the tool to support the provider you want, at the price it negotiated, whenever it gets around to it. Owning the credential is what keeps the exit yours.
Local engines are not the fallback
The next piece is the one people file under “nice for hobbyists” and then need for real six months later.
You should be able to point the same tool at a model running on your own machine. An open-source model through Ollama, on your laptop, no network required. Most tools treat this as a downgrade path, the thing you use when the good API is down. That framing is backwards.
Running local is the only mode where you can promise, and mean it, that nothing left the building. For a whole class of work that promise is the requirement, not the extra. Regulated code. A client who signed something specific about where their source lives. A prototype you are not ready to expose to any third party. The moment a task like that arrives, a tool that can only call a cloud API has nothing to offer you, and you are back to copy-pasting into a terminal you trust.
A local software factory built for bring-your-own treats the local engine as a first-class citizen sitting next to the frontier APIs. Same task interface. Same contract around it. The only thing that changes is which engine picks up the work, and that is exactly the point.
Portability is decided before the product exists, not after
Here is where this stops being a features list and becomes architecture.
If a product hardcodes one model’s assumptions into its core, its prompt formats, its tool-calling quirks, its token accounting, the way it parses that one model’s output, then portability is impossible to add later without a rewrite. The model has become load-bearing. You can put a dropdown in the settings, but underneath, one engine is holding up the building and the others are decorations.
Portability has to be a shape you choose at the start. The model sits behind an adapter. The product talks to the adapter, never to the raw engine. Anthropic’s format, OpenAI’s format, a local model’s format, each one is a translation layer, and the durable part of the product does not know or care which is behind it. Add a new engine and you write one adapter. Nothing above it moves.
I care about this because I have watched the alternative. A model gets pulled, or restricted, or deprecated with a month of notice, and a product wired to that single engine goes dark with it. The teams that survive that week are the ones who decided, up front, that no single engine gets to be irreplaceable. It is the same argument I made about routing every task to the right engine: routing across a fleet only works if the fleet was portable to begin with. Bring-your-own-model is the foundation the router stands on.
What actually has to survive the swap
The model is the part you want to make disposable. So what is the part that must not be?
Everything that holds the meaning of your work. The product contract. The specifications and acceptance criteria. The decisions you made and why. The code knowledge graph. The evidence that a task actually passed. If those live inside a conversation with one model, then swapping the model throws them away, and portability is a lie.
swappable
- the model
must survive
- product contract
- specs and criteria
- decisions
- code graph
- evidence
If they live outside the model, in local storage you can inspect, then the model is genuinely swappable. You change engines and the memory is still there. Yesterday’s decisions still apply. The specs still hold. The new engine reads the same durable context the old one did and picks up where the work was. That is what portability buys you. Not the freedom to change a dropdown. The freedom to change the engine and lose nothing.
This is why bring-your-own-model and durable product memory are the same design, seen from two angles. One says the model is a part. The other says the important stuff lives outside the part. You cannot have the first without the second.
Where PaellaDoc fits
PaellaDoc is built this way on purpose. You bring your own API keys, or you point it at a local model through Ollama, and it treats Claude, Codex, Gemini and local engines as interchangeable under one contract. Your keys, your billing, your data agreement. Nothing is resold through someone else’s account.
Underneath, the part that matters does not move when you switch. The product contract, the stories and criteria, the code graph and the evidence live in local storage on your machine. Change the engine and the memory survives the change. The model is the lever. The factory around it is what you actually own.
Do you hold your own keys, or does your tool hold them for you? It is worth checking before the day you need to switch.
Frequently asked questions
What does bring your own model mean?
Bring your own model means you supply the API key or point the tool at a local engine, and the tool treats the model as a swappable part rather than its own core. You hold the credential; the tool is a client pointed at it. It sounds like a checkbox, but it is a decision about how the product is built — one that has to be made before the first line of code, not bolted on after.
Can I use my own API key with an AI coding tool?
With a bring-your-own-model tool, yes, and the difference matters. When the key is yours, billing hits your card under your terms, the rate limits are the ones you signed up for, and the data agreement is the one you accepted. Moving to another provider becomes a settings edit on your own schedule. When the key runs through the tool, you wait for it to support the provider you want, at the price it negotiated.
Can AI coding tools run local models offline?
A tool built for bring-your-own can, through an engine like Ollama running an open-source model on your machine with no network. It is not a downgrade path. Local is the only mode where that promise actually holds — the requirement for regulated code, a client contract about where source lives, or a prototype you are not ready to expose. A good factory treats the local engine as first-class next to frontier APIs.
What happens to my work if I switch AI models?
Nothing, if the work lives outside the model. The product contract, specifications, decisions, code graph and evidence must sit in local storage you can inspect, not inside a conversation with one engine. Then you change models and the memory survives: yesterday’s decisions still apply, the specs still hold, the new engine reads the same durable context. If that meaning lives inside one model, swapping it throws the work away and portability is a lie.