Running local and cloud models in the same coding agent: what actually ships in 2026

Someone on r/LocalLLaMA asked a question this week that turned out to be harder to answer than it looks: which open-source coding harness lets a local model and a cloud model work on the same task, together, in one loop? The answers he got were a proxy and a shrug. He rejected both, correctly. So here is the actual answer, with the config knobs, and an honest account of the part that does not exist yet.

Why a gateway is not the answer

The first suggestion for this is always LiteLLM, or Bifrost, or whatever OpenAI-compatible proxy is current. Those are good at what they do. They are not what the question is asking for.

A proxy routes on what it can see in the request: the model name you asked for, weights you configured, health checks, budgets. It sits below the agent and has no idea whether the call it is forwarding is a throwaway commit message or the one architectural decision in the run. Point an agent at a gateway and you get failover and cost control. You do not get a local model and a cloud model dividing labour on a task, because nothing in the request says what the task needed. The signal you want lives one layer up.

What actually ships, by declared role

Three tools do this today. None of them frame it as routing, which is why searching for "routing" misses them. They all frame it as roles.

• Cline lets you set one model for Plan mode and a different one for Act mode. In settings, enable "Use different models for Plan and Act", then pick a model for each. Switching modes switches the model automatically, so a single task can be planned by one model and executed by another without you touching anything mid-run. The documented pairing is a stronger reasoning model for planning and a faster one for implementation, and nothing stops you pointing one of those at a local endpoint.
• Aider takes three models in one session. --model is the main one that does the editing. --editor-model handles the edit-application step. --weak-model picks up the cheap work like commit messages and history summarization. You set them independently, so a large cloud model can do the reasoning while a small local model absorbs the chatter that would otherwise burn tokens.
• Continue assigns models per role, and this is the closest thing to the original question. Autocomplete is a separate role from chat. Their docs cover running the autocomplete model locally through Ollama, and chat can sit on a cloud provider at the same time. That is genuinely a local model and a cloud model both live in one workflow, serving different jobs, all day.

So the honest answer to "does anything blend local and cloud in one loop" is yes, three things do, and they have shipped it for a while. It just is not called routing.

The pattern, and the part nobody has

Look at what those three have in common. In every case, you declare the split once, and the harness honours it for the rest of the run. Plan gets this model. Autocomplete gets that one. Commit messages get the cheap one.

What none of them do is decide the split themselves. No shipping harness looks at a subtask, works out that this one needs vision or a 400k context window or tool calling that survives twenty turns, and picks accordingly. That gap is not an oversight, and it is worth understanding why, because it tells you what to build if you are going to build it.

The requirement is known inside the planner, at the moment a subtask is created. By the time a model is selected, that context is gone: the selection layer sees a prompt and a model name. Nobody has plumbed the requirement from where it is known to where it is needed. Until someone does, autonomous model selection has nothing to select on.

If you are wiring this yourself

Two rules that survive contact with real work.

1. Route on declared capability, never on estimated difficulty. Capability is checkable: this subtask has an image in it, this one exceeds the small model's context, this one needs a tool call. Those facts stay true tomorrow. Difficulty is a guess, it is not measurable at the point you need it, and every heuristic you write for it goes stale on the next model release. A rule that rots silently is worse than no rule.
2. Put the cheap model where the work is bounded and verifiable. Commit messages, summarization, autocomplete, structured extraction with a schema you validate. In each case, a bad output is obvious immediately and costs one retry. That is why the shipping tools all made the same choice: the roles they hand to the weak model are exactly the roles where being wrong is cheap and detectable.

The interesting version of this problem is not building a smarter router. It is getting the planner to say what each piece of work actually needs, in a form something downstream can act on. Everything else follows from that.

Sources

Cline's Plan and Act docs, Aider's advanced model settings, and Continue's autocomplete deep dive, all checked while writing this.