Local-first field guide
Open-source and local AI coding agents by control boundary
Choose an open-source or local AI coding agent by editor surface, provider flexibility, self-hosting, repository workflow, and the parts that still leave your machine.
“Local” has four meanings
A tool can install locally while sending prompts and repository context to a hosted model. It can be open source while depending on a commercial inference API. It can support local models but still use cloud indexing. It can also be genuinely self-hostable, including the application and execution environment.
Choose the boundary you require before choosing the product:
- Local interface: the client runs on your machine.
- Local execution: commands and file edits run in your environment.
- Local inference: model requests stay on hardware you control.
- Self-hosted service: shared application and supporting infrastructure run under operator control.
Shortlist by workflow
Aider: Git-aware terminal work
Aider is the narrowest recommendation. It works in the terminal, builds repository context, uses Git checkpoints, and can run lint and test loops. Choose it when inspectable repository changes matter more than a polished multi-surface product.
Its flexibility moves responsibility to the operator. Model quality, API keys, local-model performance, and usage cost depend on the providers you configure.
OpenCode: broader terminal, desktop, and editor use
OpenCode is a better fit when provider independence should extend beyond one terminal workflow. It offers an open-source agent across terminal, desktop, and editor surfaces with documented enterprise configuration.
That larger surface means more product behavior to evaluate. Test permissions, configuration portability, and local-provider quality instead of treating “supports local models” as proof of a usable local workflow.
Continue: source-controlled team configuration
Continue is strongest when AI behavior should live near the repository. Its IDE and CLI clients can assign models to different roles and carry configuration into team workflows and checks.
Choose it for explicit model routing and reviewable configuration. Avoid it when the team wants one turnkey model subscription with minimal provider setup.
Cline: visible agent approvals in the editor
Cline fits developers who want a powerful agent inside supported editors while retaining provider choice and inspectable source. Its approval-oriented loop makes tool use visible.
The trade-off is inference setup and cost. A free client can still generate a substantial provider bill, and privacy follows the chosen provider path.
OpenHands: deployment choice
OpenHands deserves separate consideration because it covers local software, a managed cloud, and self-hosted enterprise deployment. It fits teams evaluating the execution environment and governance boundary—not only an editor extension.
Operating an agent platform introduces infrastructure, sandboxing, secrets, observability, and upgrade work. Include those in the decision.
Zed: open editor plus external agents
Zed is an open-source editor rather than merely an agent client. It can use hosted models, provider keys, local models, subscriptions, and external agents. Choose it when the editor itself should remain inspectable and multi-provider.
Its collaboration and hosted services remain separate from the open editor core, so “open source” should not be translated into “every service is self-hosted.”
Privacy evaluation checklist
- Which process reads files?
- Which service receives prompts, diffs, terminal output, and repository context?
- Is indexing local, remote, optional, or unknown?
- Where are credentials stored?
- Can telemetry be disabled?
- Does a local model path still call hosted embedding or routing services?
- Which logs remain after a task?
Unknown is not a safe answer. Treat it as a procurement question that must be resolved before sensitive code enters the workflow.
Bounded local-first test
Use a small private fixture repository with synthetic secrets, then block outbound traffic except to the explicitly selected inference endpoint. Run one edit, one command, one test repair, and one context search. Inspect network logs and the resulting Git history.
This reveals whether the practical data boundary matches the architecture you intended to buy.
Primary sources
- Aider repository ↗ · checked 2026-07-31
- OpenCode repository ↗ · checked 2026-07-31
- Continue repository ↗ · checked 2026-07-31
- Cline repository ↗ · checked 2026-07-31
- OpenHands license ↗ · checked 2026-07-31
- Zed repository ↗ · checked 2026-08-23