Updated on
OpenHands: reviews and analysis
The open source agent that picks up the labelled issue and opens the pull request on your own infrastructure.
Affiliate link · no extra cost to you
OpenHands is the reference autonomous agent among the ones you can host yourself. Put a label on the issue and it works alone until the pull request is open, inside an isolated container with a real terminal and real files, under an open licence and with the model you pick. What you pay for is not the tool but the tokens, which makes it the choice for anyone who does not want their code leaving the building. The price of that freedom is setup: it needs Docker and terminal fluency, and plenty of people drop out there.
Best for: Teams wanting an agent that closes issues without code leaving their infrastructure.
What the internet says
The web treats it as the reference autonomous agent among the self-hostable ones, with the label on the issue and the pull request opened on its own as a documented flow, and faults it for a Docker setup that shuts out anyone who does not come from infrastructure.
What the web repeats in favour
- Label the issue and the agent opens the pull request on its own, with the flow described in the official docs
- MIT licence and execution on your own machine or your own cloud: code and keys stay where you decide
- Runs with whichever model you want, local open models included, instead of tying you to one provider
What the web repeats against
- Setup demands Docker and terminal fluency, and it stalls on corporate laptops with restricted Docker
- The agent sometimes keeps repeating the same failing approach, and interface work comes out less reliable than back-end work
- Two name and domain changes in two years leave old tutorials and links pointing at renamed places
Sweep sources: Press · Press · Review sites · Press · Docs · Official pricing
Pros / Cons
Pros
- From labelled issue to pull request with nobody watching
- Open licence and execution on your machine or your cloud
- Works with whichever model you want, local open models included
Cons
- Setup asks for Docker and a terminal: not for anyone outside that world
- It sometimes digs in, repeating the same approach that already failed
TLDR: OpenHands is the reference autonomous agent among the ones you can host yourself. Put a label on a GitHub issue and it works alone until the pull request is open, all inside an isolated container with a real terminal and real files. The licence is open and you pick the model, so what you pay for is tokens rather than the tool. The toll sits at the door: it needs Docker and terminal fluency.
What OpenHands is and how it works
OpenHands started as the open answer to the first closed coding agents, and today it is the project of its class with the most traction among developers. The short description is that it runs an agent inside a real repository, not that it suggests snippets in a chat.
The detail matters. Each session spins up a container where the agent has a terminal, a file system and a browser, with access limited to the project directory. There it plans, edits, runs commands, checks whether tests pass and fixes. When it finishes it leaves a branch and a pull request for a person to review, and if it cannot solve the task it leaves the partial progress with a message explaining where it stopped.
The flow that answers a team’s actual question is the GitHub integration. Install the app on the repository, put a label on the issue or mention the agent in a comment, and it starts with nobody watching. The official documentation describes it step by step, and the project uses it on its own code.
Two more decisions define the product. The licence is open and permissive, so you can deploy it on your laptop, on a virtual machine or in your own private cloud. And it is model agnostic: it runs with your key from whichever provider you like, open models running locally included. For teams with privacy requirements, those two things together are worth more than any feature.
What it is like day to day
Where it truly earns its place is tedious, bounded work. Resolving a merge conflict, fixing what the linter flags red, pushing a half-finished pull request over the line, closing an issue with a clear reproduction. On that ground the label and the returning pull request save an afternoon a week.
Where it should not be pointed is open-ended interface work. Users themselves note that visual work comes out less reliable than back-end work, and that the agent sometimes digs in, repeating an approach that already failed instead of trying another. The reasonable reading is to treat it like someone who just joined the team: capable, fast, and with code pending review.
The real friction is standing it up. You need Docker, you need spare memory, and on a corporate laptop with restricted Docker the install stalls. The documentation assumes you come from the terminal, so anyone who does not will have a rough time before the first result. Worth knowing too that spinning up each session’s container adds a wait that hosted tools do not have.
A practical maintenance warning: the project has changed name and domain twice in two years. Old tutorials point at renamed places and at image versions the official docs no longer serve, so go to the source rather than the first guide that surfaces.
Pricing and plans
The honest answer here has two parts. The tool is free: the project is open and running it on your machine costs nothing. The individual tier of its cloud service is also listed as free, with the option to bring your own model key or use the in-house provider. For enterprise there is no published rate, you have to talk to them.
What does cost money are the tokens each task consumes, and that depends on the model you choose and how long the task runs. There is no single figure to quote, and anyone quoting one is making it up. The sensible way to estimate is to measure a week against your own repository before deciding anything.
The other cost appears on no invoice and is real: hosting it, updating it and debugging it is work. If nobody on the team will own that, a hosted tool comes out cheaper even at a higher list price.
Who it is for (and who it is not for)
OpenHands is for teams that want an agent closing issues without code leaving their infrastructure, for anyone who already holds model keys and prefers paying consumption, and for anyone who wants to understand what an agent does inside rather than trusting a closed box.
It is not for anyone who wants to start in five minutes. Jules solves the same thing from the browser with nothing to install. It is also not for anyone after the most polished agent with commercial backing, which is Devin, nor for anyone working locally on their own machine orchestrating several sessions, which is Conductor ground.
OpenHands alternatives
The split is clear. Jules if you want to delegate without installing, Devin if you want a finished product rather than a project, Conductor if your way of working is launching several agents in parallel from the desktop. They are in OpenHands alternatives, with the field in our guide to the best AI coding tools.
Frequently asked questions
Does it really open the pull request on its own?
Yes, that is its documented flow: label the issue or mention the agent in a comment, and it works until the pull request is open. If it cannot manage, it leaves the branch with what it had and explains where it stopped. Reviewing it is still mandatory.
Do I need Docker?
Yes, and it is the requirement that shuts most people out. On Windows it also asks for the Linux subsystem. If you cannot install Docker on your work machine, this is not your tool.
Which model does it use?
Whichever you give it. It runs with frontier models from the big providers and also with open models running on your own machine, which is the route for anyone who does not want code leaving the building.
What does each task cost?
It depends on the model and the size of the task, and there is no published figure that covers every case. Measure a week against your repository before deciding, because the difference between one model and another is severalfold.
Is it good for production code?
It is good for preparing the change, not for skipping review. The recommendation daily users repeat is to review every pull request it opens, exactly as you would review one from a new joiner.