Open-Source Coding Agents Don’t Remove Lock-In. They Hand You the Adapter Layer

The sales pitch for an open-source coding agent is refreshingly compelling: keep the agent, change the model vendor, retain your dignity. And, technically, this is true in the same way that owning a cast-iron pan means you are no longer locked in to restaurant kitchens. You have freedom. You also have seasoning, smoke, and one pan that now lives permanently on the stove because putting it away would be admitting defeat.

Tools such as OpenHands and Aider make it practical to bring your own model endpoint, key, and occasionally self-hosted server. That matters. A provider can change pricing, rate limits, supported regions, or its opinion about which API is the real API this quarter; a local agent that speaks to several backends gives you options. But “avoid vendor lock-in” is not the same proposition as “stop maintaining vendor integrations.” It generally means the latter job has been promoted from a vendor support ticket to one of your recurring responsibilities.

The portable part is real

Aider is unusually direct about model selection. You can start a session against a named provider or an aggregator with a command such as:

aider --model openrouter/deepseek/deepseek-chat \
  --api-key openrouter=your-key-goes-here

That is a genuinely useful escape hatch. It lets a team preserve its command-line workflow while changing the model behind it. OpenHands takes the same idea further through its LLM configuration: its CLI supports temporary overrides through environment variables, including the model, API key, and custom base URL. The following is the kind of provider swap that is pleasantly boring when the endpoint behaves like the agent expects:

export LLM_MODEL="openai/qwen3-coder:30b"
export LLM_API_KEY="local-llm"
export LLM_BASE_URL="http://host.docker.internal:11434/v1"
openhands --override-with-envs

OpenHands documents this mode specifically as non-persistent, which is good: an experiment should not become a mysterious default six weeks later. It also exposes a 120-second timeout in its SDK configuration, plus retry controls. Those are not glamorous knobs, but a timeout is where “multi-provider flexibility” becomes “why did the terminal just sit there contemplating mortality.”

Then the abstraction starts charging rent

The agent’s provider layer usually normalizes the easy 80 percent: model name, key, base URL, messages in, text out. Coding agents inhabit the remaining 20 percent with the enthusiasm of a cat locating the one shelf you did not childproof. Tool calls, streaming event shapes, context limits, image support, caching hints, token accounting, and retry behavior are all places where “OpenAI-compatible” may mean compatible in the broad philosophical sense.

OpenHands says it can connect through LiteLLM to a large set of providers, but its own documentation also calls out settings that may need to bypass the UI and land in environment variables or config: API version, parameter dropping, vision disabling, caching, embeddings. Its local-model guide warns that weaker local and open models can produce long waits, poor results, or malformed JSON. That is not a failure of open source. It is the bill for operating a boundary between an agent designed around tool use and a model endpoint whose idea of structured output may be more aspirational.

This is where a proprietary agent can feel suspiciously restful. One company owns the client, the model, the auth flow, and most of the blame. The open alternative lets you choose every component, including the component that breaks on Friday because a provider renamed a model, changed a default, or started rejecting an argument your adapter helpfully kept sending.

Treat provider support like a dependency, not a checkbox

The sensible move is not to avoid open-source agents. It is to stop pretending that provider portability is a permanent property you acquire at install time. It is a compatibility surface you maintain. Give it the same ceremony you give a database migration: small, explicit, tested, and mildly resented.

1. Keep provider profiles in version control, with the model identifier, base URL, required environment variables, maximum timeout, and a human owner. Do not leave the winning combination in a chat thread named “agent stuff.”
2. Run a small smoke task whenever you change model, gateway, or agent version: inspect a repository, edit one file, run one test command, and ask the agent to explain the diff. This checks the part that matters: tool use plus editing plus shell execution, not merely whether an API returns 200.
3. Set spending and rate-limit expectations separately for each provider. OpenHands explicitly notes that agents issue many prompts and recommends monitoring usage; a successful single prompt is not a cost model.
4. Keep one known-good fallback profile. The point is not ideological purity. The point is that when your preferred endpoint starts returning 429s, you can continue shipping instead of becoming an amateur protocol archaeologist.
5. Record failures by capability: “streaming broken,” “tool-call JSON unreliable,” “context too small for this repository.” “Model bad” is emotionally satisfying but operationally thin.

The bad fit is teams that want to forget the plumbing

If your primary requirement is that everyone has the same polished experience, identical permissions, centrally handled billing, and a vendor to escalate to when the agent invents a malformed function call, an open-source agent may be the wrong economy. You can absolutely build that layer yourself. You can also make your own espresso machine from parts. The question is not whether it can be done; it is whether that is what you meant to do before coffee.

For developers who need options across cloud APIs, gateways, and local models, open-source agents are worth the maintenance. They make exit possible, let you test new models without changing your entire workflow, and turn “we are stuck” into a configuration problem. Just describe the trade honestly: vendor lock-in has not vanished. It has been decomposed into YAML, environment variables, compatibility notes, and a Tuesday afternoon spent finding out that base_url was almost right.