OpenHands Review 2026: The 76K-Star Coding Agent

This article was originally published on aifoss.dev

TL;DR: OpenHands is the most capable open-source autonomous coding agent in 2026 — MIT-licensed, 76K stars, and it resolves real GitHub issues end to end. It shines with a strong cloud model and struggles with small local ones. Run it if you want an agent that opens PRs unattended; skip it if you want lightweight in-editor edits.

	OpenHands	Aider	Cline
Best for	Autonomous issue-to-PR, async tasks	CLI pair-programming, git-first	VS Code multi-file editing
Local model support	LiteLLM (Ollama, llama.cpp, 100+)	Any OpenAI-compatible endpoint	Ollama, LM Studio, 30+
The catch	Heavier setup; needs Docker for sandboxing	Quality floors at ≥32B local models	Token costs climb on large repos

Honest take: With Claude Opus 4.6 behind it, OpenHands is the strongest open-source coding agent you can self-host today. With a 7B local model, it's a tech demo. Pick your model accordingly.

---

What OpenHands actually is

OpenHands (formerly OpenDevin) is an autonomous software-development agent. You give it a task in plain English — "fix the failing test in auth.py", "add pagination to the users endpoint" — and it plans, writes code, runs commands in a sandboxed environment, reads the output, and iterates until the task is done. It can browse the web, execute shell commands, and edit multiple files across a repo without you approving each step.

That last part is what separates it from code completion (Tabby, Continue.dev) and from a chat-first tool. OpenHands is built to work asynchronously. The 2026 product pitch is "cloud coding agents" — you hand it a GitHub issue and it comes back with a pull request.

The project is run by All-Hands-AI. It's MIT-licensed, sits at 76.4K GitHub stars as of June 2026, and raised an $18.8M Series A led by Madrona in November 2025 (with Menlo Ventures, Obvious Ventures, and Fujitsu Ventures participating). The latest release at the time of writing is v1.8.0, shipped June 10, 2026. Versions move fast — pin one rather than trusting any number you read in a blog post.

How it performs: the SWE-bench numbers

OpenHands' headline metric is SWE-bench Verified, the benchmark that measures whether an agent can resolve real GitHub issues from popular Python repos.

Configuration	SWE-bench Verified	Notes
OpenHands + Claude Sonnet 4.5	~53%	Solid default for most users
OpenHands + CodeAct v3 + Claude Opus 4.6	68.4%	Strongest published config
Aider (leaderboard, top config)	~mid-60s%	Comparable, lighter footprint
Raw model, no agent scaffold	lower	The agent loop is doing real work

Two takeaways. First, the agent scaffolding adds real value — the same model resolves more issues inside OpenHands than when prompted directly. Second, the score is almost entirely a function of the model you plug in. OpenHands with a frontier model competes with anything open-source; OpenHands with qwen2.5-coder:7b will plan poorly, loop on errors, and burn time. This is the single most important thing to understand before you install it.

Installing the CLI (the fast path)

The quickest way to try OpenHands is the CLI. It requires Python 3.12 specifically — 3.14 is not supported yet, and 3.11 will fail. The cleanest launch uses uv, which avoids polluting your global environment:

# One-line launch, no install needed
uvx --python 3.12 --from openhands-ai openhands

# Optional: alias it
alias oh="uvx --python 3.12 --from openhands-ai openhands"

Prefer pip? The package name is openhands-ai, not openhands (the latter is a different, unrelated package — a common first-run mistake):

pip install openhands-ai
openhands

On first launch it walks you through model configuration. With an Anthropic key you'd set the model to anthropic/claude-sonnet-4-5 and paste the key. That's enough to start issuing tasks in the terminal.

For the full GUI — the web interface with a chat panel, file browser, and live terminal — launch the server:

uvx --python 3.12 --from openhands-ai openhands serve
# add --mount-cwd to give it your current directory
# add --gpu if you're running a local model on the same box

It opens on localhost and spins up a Docker container as the agent's sandbox. Which brings us to the requirement nobody mentions until it breaks: you need Docker running. The sandbox is where OpenHands executes the commands it writes, isolated from your host. No Docker, no agent.

Running OpenHands fully local with Ollama

This is the reason most aifoss.dev readers are here: can you run it with zero cloud calls? Yes. OpenHands uses LiteLLM under the hood, so any of 100+ providers works — including Ollama and llama.cpp.

Start Ollama and pull a coding model:

docker run -d --name ollama --gpus all -p 11434:11434 \
  -v ollama-data:/root/.ollama ollama/ollama:latest
docker exec ollama ollama pull qwen2.5-coder:7b

Then point OpenHands at it. If you're running OpenHands itself in Docker, the networking gotcha is real: you cannot use localhost. The container can't see your host's localhost — you have to use host.docker.internal:

LLM_MODEL=ollama/qwen2.5-coder:7b
LLM_BASE_URL=http://host.docker.internal:11434
LLM_API_KEY=ollama

That LLM_API_KEY=ollama line looks pointless — Ollama doesn't check it — but LiteLLM expects a non-empty value and the connection fails without it. Set it to any string.

A real problem I hit, and the fix

The most common local-setup failure (tracked in OpenHands issue #8318) is the LLM connection failing for a Dockerized OpenHands trying to reach Ollama on the host. The symptom: the agent starts, then immediately errors on the first model call. Two fixes, in order:

1. Use host.docker.internal, not localhost or 127.0.0.1. On Linux, you may also need to launch the OpenHands container with --add-host=host.docker.internal:host-gateway for that hostname to resolve at all.
2. Set the base URL in the environment, not only the UI. The UI settings have historically overridden env values in confusing ways across versions. Set both to the same value to be safe.

After that, the agent connects. Whether it does anything useful with a 7B model is a separate question — see the limitations section.

Hardware: what you actually need

OpenHands the orchestrator is light. The weight is entirely in the model.

Setup	RAM	VRAM	Realistic outcome
OpenHands + cloud API	8 GB	none	Best results, pay per token
OpenHands + 7B local model	16 GB	8 GB	Runs; weak multi-step planning
OpenHands + 32B local model	32 GB	24 GB	Usable for scoped tasks
OpenHands + 70B+ local model	64 GB	48 GB+	Closest local gets to cloud quality

For 32B-and-up local models you're looking at a 24GB card like an RTX 4090, or pooled VRAM. If you don't own that hardware and only need an agent occasionally, renting a GPU on RunPod for the duration of a task is often cheaper than buying a card. For sizing a home GPU box, runaihome.com has build guides.

Where OpenHands falls short

This is the part the project's own README won't tell you.

Local small models disappoint. The agent loop assumes the model can plan, recover from a failed command, and stay coherent across many steps. Models under ~30B routinely lose the thread — they re-run the same broken command, hallucinate file paths, or declare victory on an unfinished task. If your privacy requirements force you onto a 7B model, OpenHands is the wrong tool; a simpler pair-programmer like Aider degrades more gracefully.

Setup is heavier than the alternatives. Docker, Pyth