OpenHands

Last reviewed Aug 26, 2026 · 850 words

Before your first OpenHands run, decide two things: which model pays the bills and how much a failed task is allowed to cost. The agent itself — formerly OpenDevin, now 85,000 GitHub stars and MIT-licensed — is a solved installation problem; a Docker command has the UI on port 3000 in five minutes. What separates people who get value from people who rage-quit is that an autonomous agent writes code, runs commands, browses docs, and retries in a loop, and every step in that loop is model tokens. Point it at a strong model with no budget and one meandering task can cost more than a month of a ChatGPT subscription. Point it at a weak model to save money and it flails. The setup below is how I keep it useful on both axes.

The sandbox is Docker-in-Docker, on purpose

OpenHands executes agent actions inside disposable runtime containers, which is the right call — you want an entity that runs arbitrary shell commands doing so in a sandbox, not in your shell. The practical consequence is that the launch command mounts the host Docker socket so the app can spawn those runtimes. Understand what that grant means: control of the Docker socket is effectively root on the host. Run it on a machine you would be comfortable rebuilding, or in a VM, and never expose the web UI to the internet unauthenticated — the UI drives an agent that can execute anything. The official docs keep the current run command and flags; copy it from there rather than from a months-old blog post, because the runtime images version in step with releases. Host requirements are modest next to the model bill: the catalogue's 4 GB RAM minimum is about right, plus disk for runtime images.

Model choice is 90% of agent quality

OpenHands is model-agnostic — configure a provider and model in settings, with local backends reachable the same way. The unhappy truth in 2026 is still that agentic coding stresses exactly what cheap models lack: long-horizon planning, tool-call reliability, and recovering from their own mistakes. Frontier models complete multi-step tasks that mid-tier models loop on, and a local 8B model through Ollama will technically connect but mostly waste your afternoon. My working split: a frontier model for real tasks, a cheaper one for mechanical chores (renames, test scaffolding, dependency bumps), and Ollama only for experimenting with the harness itself. Set hard spending caps at the provider level, not just in the app — the techniques in LLM cost engineering apply doubly to agents because retries multiply everything.

Write tickets, not wishes

The catalogue lists "results can vary" as a con, and scoping is where the variance lives. "Improve the codebase" produces expensive wandering. "Add a --json flag to the export command, update the two affected tests, and make make test pass" produces a mergeable diff more often than not. The tasks where OpenHands has repaid me: well-described bug fixes with a reproduction, test coverage for existing modules, dependency upgrades with breakage fixes, and boilerplate-heavy features in codebases with good existing patterns to imitate. The tasks where it burns money: anything requiring taste, architectural judgment, or knowledge that lives in someone's head instead of the repo. Give it what you would give a competent contractor on day one — clear acceptance criteria and a working test command — and review the diff like a pull request from that contractor, because that is what it is.

Autonomous agent or pair programmer — pick per task

OpenHands occupies the "delegate and walk away" end of AI coding, the self-hosted answer to Devin. That is a different tool from a terminal pair-programmer like aider, which keeps you in the loop for every edit, costs a fraction of the tokens, and is the better fit when you already know the shape of the change. I run both: aider for work I am actively thinking about, OpenHands for parallelizable chores I want done while I think about something else. If you have never used either, start with the pair-programming style — my workflow notes cover it — because it teaches you cheaply what models can and cannot do, and that intuition is exactly what makes your agent task scoping good later.

What I'd do

Install it on a sacrificial VM via the official Docker command, wire up a frontier model with a $25 hard cap for the first month, and feed it five genuinely well-scoped tasks from your real backlog — reproduction steps, acceptance criteria, test command. Track what each run cost and whether you shipped the diff. In my experience roughly the same effort that would brief a junior colleague gets a usable result at single-digit dollars per task, and that trade is worth automating; if your five-task trial says otherwise for your codebase, drop back to aider and revisit in six months. The agents keep getting better, and the harness is free either way.