Local vs cloud coding agents: control plane and execution plane

Two planes, not one axis

Almost every discussion of local versus cloud coding agents collapses two independent decisions into one. The first is where model selection, policy enforcement, and billing happen — the control plane. The second is where the agent loop runs and where your source code is read, written, and executed — the execution plane. A product can be cloud on one and local on the other, and most of the interesting architectures are exactly that.

Once you separate them, the questions get sharper. Privacy is almost entirely an execution-plane question: it matters far less whether a routing decision was made on a server than whether your repository was copied to one. Cost control, model failover, and spend policy are control-plane questions, and they are better solved centrally than in a config file on every developer’s laptop. Continuity — whether work survives you closing the lid — is an execution-plane question and the one that most changes daily experience.

What a control plane is actually for

A serious control plane does four things that are painful to replicate per machine: it resolves a request to a specific model under policy, it enforces spend limits before the call rather than after, it holds provider credentials encrypted so they never sit in a developer’s shell profile, and it produces a reconcilable usage record.

Kendr’s cloud is a worked example of this shape. A routing service creates an immutable plan for each request — in normal mode resolving only the alias asked for, and in intelligent mode applying capability gates, classification, calibrated scoring, policy filters, and a bounded replacement set. A billing service reserves enough wallet credit for the complete bounded plan before execution, then settles or releases against the terminal execution record, so a failed call is never presented as a settled one. Provider credentials are decrypted only inside a connector service. Each settled call records normalised usage dimensions, the rate-card version, the charge, one ledger debit, and the remaining balance.^[1]

That documentation also carries a disclaimer worth repeating, because it is the kind of claim vendors usually leave ambiguous: managed routing does not invoke a second model to verify the first model’s answer. Provider diversity is a routing and fallback property, not a factual-validation guarantee. Applications that need answer verification have to build and evaluate that workflow themselves.

The execution plane and the walk-away test

The execution plane is where the trade-offs bite. Local execution gives you the real environment — your dependencies, your credentials, your database, your half-finished branch — with no upload, no snapshot drift, and no per-minute compute bill. Hosted execution gives you continuity, parallelism beyond your laptop’s cores, and a clean environment that cannot be contaminated by whatever is broken on your machine.

The single sharpest way to tell them apart is what we call the walk-away test: start a task, close the laptop, and see whether the work continues. Claude Code passes it through cloud sessions and scheduled Routines that run without your machine.^[2] The GitHub Copilot coding agent passes it by construction — it works in an ephemeral GitHub Actions environment, pushes commits to a draft pull request, and requests review, with a hard cap on session length and one branch and one pull request per task.^[3] Codex passes it for hosted tasks. Cursor passes it for cloud agents.

Locally executing harnesses fail it, and they should be honest that this is a capability gap rather than a philosophy. Kendr Code sits in an instructive middle position. It operates a substantial cloud control plane, ships deployment commands that publish a task’s output to hosted targets, and — since its August release — a frozen headless execution contract with a GitHub Action and a GitLab template, so work does continue in CI without your machine. But there is no hosted runner: outside a CI job the coding loop runs on your laptop, and closing it stops the work. That is worth naming precisely rather than blurring, because CI-as-execution-plane and a hosted runner solve different halves of the problem. CI is excellent for well-scoped, definition-of-done work triggered by a repository event; it is poor for the long exploratory task you want to hand off at 6pm and collect in the morning. Machine-off continuation for that second case has become table stakes for anything marketed as an autonomous colleague, and no amount of control-plane engineering substitutes for it.

• If your repository cannot leave your network, the execution plane must be local or self-hosted — the control plane can still be managed.
• If your bottleneck is wall-clock time on long tasks, hosted execution buys parallelism your laptop cannot.
• If your bottleneck is environment fidelity — a local database, a hardware dependency, an unfinished branch — local execution is not a compromise, it is the requirement.
• If you need both, look for products where a session can move between planes rather than products that only offer one.

The hybrid designs worth studying

Three hybrid patterns have emerged and each solves a different half of the problem. The first is session teleport: start locally, push the session to the cloud when you leave, pull it back when you return. This preserves environment fidelity for interactive work and continuity for long work, and it is the most complete answer currently shipping.

The second is the local server with remote clients. OpenCode’s architecture puts inference, tool execution, session persistence, and MCP servers in a backend on your machine and lets terminal, desktop, web, and mobile clients connect over HTTP and server-sent events.^[4] You gain phone-and-tablet reach without your code ever leaving the host — but the host must stay awake, so this solves reach and not continuity.

The third is CI-as-execution-plane: the repository host runs the agent in an ephemeral environment triggered by an issue or a pull request. This is the cheapest hybrid to adopt because the infrastructure already exists, and the most constrained, because CI environments are deliberately clean and short-lived. It suits well-scoped tasks with a clear definition of done and suits exploratory work poorly.

Local models are a separate question again

It is worth untangling one more conflation: running the agent locally and running the model locally are independent. Most local-execution harnesses call a hosted frontier model; most cloud-execution harnesses do too. Genuinely local inference through Ollama, llama.cpp, LM Studio, or vLLM is supported broadly across the open harness field — OpenCode, Cline, Continue, Goose, and most of the independent tier all speak to it.

The practical caveat is not capability but configuration. Local runtimes have their own failure modes that harnesses handle unevenly — a context window silently truncating a long prompt is the classic one, and it presents as the model producing garbage rather than as an error. A harness that sizes the context per request and fails fast when a prompt cannot fit is far more usable with local models than one that sends the request and hopes. Ask about that specific behaviour before assuming local-model support is production-grade.

Sources and evidence

Primary and authoritative sources used for factual claims. Company research and executive forecasts are labeled as such in the article.

1. 1
   Kendr cloud platform architecture and model call lifecycleKendr
2. 2
   Claude Code surfaces, cloud sessions, and RoutinesAnthropic
3. 3
   About GitHub Copilot coding agentGitHub
4. 4
   OpenCode documentationOpenCode
5. 5
   Kendr developer API and model contractsKendr