The Open-Source Agent Stack — OpenHands, Aider, Continue, Cline

The closed-source coding agents have the cap-table headlines. Cursor at fifty billion. Cognition at twenty-five. Claude Code at a two-point-five-billion run rate. The numbers tell you where the venture money has been spent. They do not tell you where engineers are actually doing their work, and the answer in 2026 is increasingly that the closed agents share a desk with the open ones.

This piece is the practitioner-side comparison of the four open-source coding agents I see in production most often: OpenHands, Aider, Continue, and Cline. They are all in active use, all have meaningful funding or community behind them, and all make a different bet about where open coding agents should live in a developer’s workflow. The bet they share is that bring-your-own-model is the more durable architecture — that locking the agent to one vendor’s API is a worse foundation than letting the agent talk to whichever model is best, cheapest, or most compliant for the job. I think they are right.

Why open coding agents matter in 2026

A short interlude on why a piece like this is worth writing in the first place.

A year ago, the open coding agents were primarily a hedge. You ran one because you did not want to be locked into Cursor or Copilot, or because you wanted a tool that worked when you were offline, or because the closed agents did not yet support the model you wanted to run. Those reasons all still apply. What has changed is that the open agents are now competitive on the dimensions that matter to working engineers, and in some specific dimensions they are ahead.

The competitive dimensions are model freedom, deployability, scriptability, and the surface they expose to other systems. The open agents win on all four, and the moment your workflow requires more than what the closed agents expose, the open agents are the only option. Add to this the strategic dimension — that the open agents do not raise their prices when the vendor closes a funding round — and the case is straightforward.

The other half of the answer is that the funding round numbers in 2026 are starting to back up the architecture bet. OpenHands closed an $18.8M Series A led by Madrona in November 2025, on top of a 60K-star GitHub repository and a roster of contributing engineers from AMD, Apple, Google, Amazon, Netflix, TikTok, NVIDIA, Mastercard, and VMware (BusinessWire, 2025-11-18). AMD published its own guide on running OpenHands locally as part of the case (AMD developer article on OpenHands). The category has venture conviction now. That conviction has not yet translated into the kind of feature-velocity that would close the gap with Cursor’s Background Agents or Claude Code’s MCP-native integrations, but the gap is narrowing.

The four agents, one paragraph each

OpenHands (formerly OpenDevin, now stewarded by All Hands AI) is the heavyweight of the four. The architecture is a sandboxed Linux environment in which an agent can write code, run shell commands, browse the web, and use tools. The model is BYOM through LiteLLM, which means you can point it at Claude, GPT, Gemini, a local Ollama instance, or anything else with an OpenAI-compatible API. The product is shipped as both a self-hosted Docker container and a hosted cloud service. The enterprise pitch is “solves 87% of bug tickets same day” — a number to read with the appropriate amount of skepticism but also a number the company is willing to put on a press release. Funding: $5M seed (Sept 2024, Menlo), $18.8M Series A (Nov 2025, Madrona).

Aider is the senior of the group and the most opinionated. Written by Paul Gauthier, Aider is a terminal pair-programmer that lives in your git repository. The bet is that git is the right substrate for an agent — every change the agent makes becomes a commit, every undo is a checkout, every history question has an answer. Aider works with any LLM provider and is famously strong on its own SWE-bench numbers, partly because the architecture has been refined over a long enough period that the prompts and the diff-application strategy are well-tuned. Free, open source, no venture capital, no enterprise tier; pay for your own model usage.

Continue is the IDE-native open-source choice. The architecture is a VS Code (and JetBrains) extension that gives you chat, autocomplete, and agentic editing — all of it BYOM. Ten-plus LLM provider integrations, an @-mention context system that lets you point the agent at specific files or symbols, and full support for local models via Ollama, which makes it the obvious choice for air-gapped or compliance-bound deployments (Augment Code, on Continue vs Copilot). Continue is the closest thing the open-source ecosystem has to a direct competitor to GitHub Copilot.

Cline is the most recent of the four and the one whose lineage is the most interesting. Cline began as a VS Code extension that took the same general shape as Continue but with a more agent-first posture — a sidebar agent that could execute multi-step tasks across the codebase. The project forked in mid-2026 over a governance disagreement, producing Cline and a separate sibling that we will not name here, both with active development continuing under different stewardship. The fork story matters because it is the clearest example to date of the open-coding-agent ecosystem behaving like a real open-source ecosystem — with the politics, the forks, and the community-versus-vendor tensions that come with that. The good news for users is that both forks are improving rapidly.

Where each one fits — a hands-on comparison

I am writing the comparison from the perspective of an engineer evaluating one of these for either personal use or a team adoption. The criteria are the ones that matter when you are doing the work: how does the agent fit your existing workflow, how does it scale to harder tasks, what is the maintenance burden, and what is the failure mode you will run into first.

OpenHands fits a team that is willing to run a service. The sandboxed-Linux model is genuinely powerful — the agent can do anything a developer could do in a terminal, which means it can run tests, lint, deploy to staging, hit your APIs, and produce a working PR. The cost is that you have to host it, which is either Docker on your laptop or a real deployment on Kubernetes or one of the simpler PaaS substrates. The hosted version exists but is its own pricing decision. The deployment-as-product-of-service shape is the right one for an agency or a platform team that wants to give engineers an agent-as-a-service rather than an agent-as-a-tool. The failure mode is operational: the sandbox is a real thing you have to operate, and a team that does not have someone willing to be on call for it will find OpenHands less reliable than it should be.

Aider fits a single engineer or a small team with strong git discipline. The git-first model means every action the agent takes is auditable, recoverable, and reviewable. The terminal interface means the agent fits into whatever your existing editor and workflow happen to be. Aider’s failure mode is its strength: the git-first model assumes you are comfortable in git, and an engineer who is not will find Aider’s interface confusing in the wrong ways. The other failure mode is that Aider is doing less work than the other three — it is a pair-programmer, not an autonomous agent, and it will not run your tests or browse the web or call an API unless you set that up yourself. That is the right shape for a power user. It is the wrong shape for a team that wants the agent to do more of the work.

Continue fits a team that is already inside VS Code or JetBrains and wants a Copilot-shaped tool that they own. The configuration model is more burdensome than Copilot’s — Copilot gives you automatic per-repo semantic indexing, while Continue makes you configure the context model yourself — but the configuration is the price for the freedom. Continue’s failure mode is that the burden is non-trivial: setting up a useful Continue configuration for a real team takes a real engineer a real day, and that day is the cost of admission. The teams that pay the cost end up with a tool that fits their workflow more precisely than Copilot would. The teams that do not pay the cost end up with a less-good version of Copilot. Pick which side of that tradeoff you are on before you adopt.

Cline fits the engineer who wants the agent-mode shape of Cursor but wants to own it. The forked-history is worth understanding before adoption — both forks have momentum, neither is the obvious successor, and the choice between them is going to be a judgement call that depends on which community you trust. The fact that the choice exists is itself good for the ecosystem. The failure mode of either fork today is that the agent-mode workflow is still less polished than Cursor’s, and a team that has been using Cursor’s agent mode will feel the difference. The gap is closing. It is not yet closed.

A working setup, written down

For the engineer who wants to try the open stack without committing, here is a setup I have used and would recommend.

Start with Aider on your local machine, pointed at whichever model you can pay for — Anthropic Claude is what I use, but the agent will work with any provider. This is the lowest-friction way to get a feel for the BYOM coding-agent shape. The install is one pip command. The first useful task is a small refactor in your own repo.

# Install
pip install aider-chat

# Point at a model and a repo
cd ~/code/my-project
aider --model claude-sonnet-4-7 \
      --anthropic-api-key $ANTHROPIC_API_KEY \
      src/billing/usage.py src/billing/usage_test.py

# Inside the aider chat:
# > /add src/billing/api.py
# > rename `getUsage` to `fetchUsage` across these three files, update the test, run the test

The session feels different from Cursor’s agent mode. The agent is more deferential. Every edit produces a commit. Undo is just git revert. After a few sessions, the git-first model becomes natural.

If Aider proves useful and you want to step up to a more autonomous shape, add OpenHands. The simplest path is the Docker image plus a local Anthropic key. You will need a machine with twelve to sixteen gigabytes of RAM available, and you will want to read the OpenHands documentation carefully on the sandbox security model before pointing the agent at anything that matters.

# Run OpenHands locally
docker run -it --rm --pull=always \
  -e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:latest \
  -e LLM_MODEL=anthropic/claude-sonnet-4-7 \
  -e LLM_API_KEY=$ANTHROPIC_API_KEY \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -p 3000:3000 \
  docker.all-hands.dev/all-hands-ai/openhands:latest

# Open http://localhost:3000 in your browser.
# Give the agent a task: "Read the README, find the open issue marked 'bug', and produce a fix as a PR."

The OpenHands experience is closer to Devin or Claude Code’s autonomous mode than Aider’s pair-programming experience. You give it a task; it works for a while; it produces output. The model freedom means you can run it against a local Ollama instance if you want to keep everything on your machine for compliance reasons.

For IDE-integrated work, add Continue. The install is a VS Code extension. The configuration lives in a ~/.continue/config.yaml and is worth spending a couple of hours getting right. Here is a starter that I use:

# ~/.continue/config.yaml
name: my-stack
models:
  - name: Claude Sonnet 4.7
    provider: anthropic
    model: claude-sonnet-4-7
    apiKey: ${ANTHROPIC_API_KEY}
  - name: Local Llama
    provider: ollama
    model: llama3.3:70b
    apiBase: http://localhost:11434

contextProviders:
  - provider: file
  - provider: code
  - provider: diff
  - provider: terminal
  - provider: docs
    params:
      sites:
        - title: "Project docs"
          rootUrl: "https://docs.myproject.internal"

systemMessage: |
  You are pair-programming inside a codebase that follows these conventions:
  - All new files use the existing module structure under src/.
  - Tests live next to the code they test, suffixed _test.py.
  - Do not introduce new dependencies without asking.
  - Match the existing code style (run black + ruff on output).

The configuration is the work. Once it is in place, the agent has the context it needs to be useful, and the BYOM model means you can switch between Claude and a local model with a keystroke.

Finally, Cline as a candidate for the agent-mode slot. Install the VS Code extension, configure it against the model of your choice, and try one of the autonomous workflows on a small task. If you are coming from Cursor’s agent mode, the experience will feel slightly less polished but functionally similar. If you are coming from a non-agent workflow, the experience will feel like a new gear.

The orchestration question — where this stack stops being enough

There is a layer above the coding agent that this piece has skipped, and I want to be honest about it. The open coding agents are excellent at the level of “produce a working diff against a brief.” They are less excellent at the level of “operate as one specialist in a larger system.” The slot above the coding agent — the orchestration that decides which agent runs, what feedback it gets, which human reviews the result — is a slot the open coding agents do not fill.

That slot is where the agent-platforms come in. LangGraph and CrewAI are the framework answers; the packaged agentic-workforce-platform category is the productized answer for teams that want the orchestration as the platform rather than as something to build. The open coding agent is one specialist in that system, not the whole system. A team that is building a serious agentic workflow should pick the orchestration layer first and then pick which coding agent to run inside it. The open ones compose more cleanly with custom orchestration than the closed ones do, which is itself a reason to pay the operational cost.

What we are watching next

Three threads worth tracking.

First, OpenHands’ enterprise rollout. The $18.8M Series A is being spent on the hosted product and on enterprise features. If those land — air-gapped deployment, SSO, audit logging — OpenHands becomes a credible alternative to Devin for the kind of enterprise that wants an autonomous coding agent it can actually operate. If they don’t, OpenHands stays a power-user tool.

Second, the Continue-versus-Copilot delta. The two tools are converging — Continue is getting better at automatic context, Copilot is getting better at BYOM at the enterprise tier — and at some point the delta is going to be small enough that the choice becomes a procurement question rather than a product question. We are not there yet. We might be in twelve months.

Third, Cline’s fork resolution. Either one of the two forks consolidates into the obvious successor, or they coexist as friendly competitors, or one of them dies. Each outcome has different implications for teams that adopt today. The cautious move is to use the fork your community trusts and to keep an eye on the other.

The short version. The open coding agents are real tools, not hedges. They make a different bet than the closed agents — BYOM, deployable, scriptable — and that bet is paying off in 2026. The right move for most teams is to use both: a closed agent for the polished daily-work experience and an open agent for the cases where the closed one’s constraints get in the way. The cost of running both is small. The optionality is large.

— Reza Mokhtari