OpenHands review (2026): the open-source coding agent
An OpenHands review for engineers: what the open-source agent platform does well, what self-hosting actually costs, and when its cloud makes sense.
OpenHands is the coding agent you can read the source of. It started in March 2024 as OpenDevin, a community project built in the weeks after Cognition demoed Devin, and it has grown into the most visible open-source project in the category: MIT licensed, more than 80,000 GitHub stars, and a company (All Hands AI) behind it. This OpenHands review covers both halves of the product, the open-source platform you run yourself and the hosted OpenHands Cloud, and tries to be honest about what each one costs you.
Product details checked August 2026. Vendors change; check their docs for current specifics.
OpenHands review: the short version
OpenHands is genuinely good, and its open-source model is a real advantage rather than a marketing sticker. You control where the agent runs and which model it uses, and you can read the source to see what it does with your code. The cost is operational: self-hosting a fleet of agents is a part-time platform engineering job, and you should price that in before comparing it to hosted alternatives. The hosted cloud exists precisely because most teams don't want that job.
What OpenHands is
The project describes itself as "an open source platform for software engineering agents". That word "platform" is doing real work. What began as a single autonomous agent has widened into a GUI, a CLI, an SDK, and an enterprise control plane, and the current README positions it as a control center that can run the OpenHands agent alongside other coding agents (Claude Code, Codex, and Gemini among them), on your laptop, in Docker, on a VM, or in the cloud, with scheduled automations and webhook-triggered workflows on top.
The core loop is the one you'd expect from a background agent. You point it at a repository and give it a task. The agent gets a sandboxed workspace with a terminal, an editor, and a browser. In there it writes code and runs commands and tests until it has something to show you.
The tracker integration is the part most teams care about. With the GitHub integration, you label an issue openhands or mention @openhands in a comment; the agent replies that it's working, and if it resolves the issue it opens a pull request with a summary. The GitLab integration mirrors this for issues and merge requests. Few agents in this category support GitLab at all, which makes OpenHands the default answer for GitLab teams.
Where open source wins
Control is the obvious one. Self-hosted OpenHands runs on infrastructure you own. Your code never transits a vendor's servers, the network boundary is yours to draw, and if your compliance regime says "nothing leaves the VPC," you can satisfy it rather than negotiate around it.
Model freedom is close behind. OpenHands lets you bring your own key for any major provider, point it at a local model, or use its own LLM provider. You are never waiting for a vendor to add the model you want. When something new ships, you can be running it the same day, and bring-your-own-LLM works on their cloud as well as self-hosted.
Auditability matters more than it gets credit for. When a security team asks "what exactly does this agent do with our code," an open-source agent has a real answer: read it. The prompts, the sandbox setup, the tool definitions are all in the repo. With a closed vendor you get a questionnaire and a trust exercise.
And the community is large enough to be a feature in itself. Bugs get found fast, integrations accumulate, and the one-year retrospective shows a project with sustained momentum rather than a demo that peaked at launch.
What self-hosting actually costs
Here's the part a fair review has to spell out. Running one OpenHands session on your laptop is easy. Running an agent fleet for a team is an operations commitment, and it lands in four places.
Sandboxing is yours to own. In the standard Docker setup, the app spawns sandbox containers, which means mounting the Docker socket on the host, and the sandbox runtime image version has to match the app version. That's fine on a laptop. On shared infrastructure, "a service that can spawn arbitrary containers and runs LLM-directed shell commands inside them" is a design your security team will want to review carefully: per-run isolation, network egress policy, and what the agent can reach from inside the sandbox are now your decisions.
Upgrades are recurring, not one-time. The project ships quickly, which is good, and also means new releases to track, runtime images to keep in sync, and occasional breaking changes to absorb across every machine running an agent.
LLM spend management is a system you have to build. Bring-your-own-key means the bill is yours to watch. Once several engineers are each running several concurrent sessions, you need budgets, per-team metering, and rate-limit handling, and nothing provides those by default.
Security patching never stops. The host, the app, the sandbox base images, and the dependencies inside them all accumulate CVEs, and the sandbox is exactly the place untrusted, model-generated code executes. Keeping it current is the same discipline as keeping CI runners current.
None of this is an argument against self-hosting. It's the standard bill for operating any execution platform, and teams that already run self-hosted CI runners know the shape of it. The mistake is comparing "free software" to a hosted product's sticker price without counting the engineer-hours. The software is free; the operation isn't.
When OpenHands Cloud makes sense
OpenHands Cloud is the hosted version, and its pricing is straightforward: the open-source platform is free, an Individual cloud plan is free for one user with a cap of 10 conversations per day, and Enterprise is custom, offered as SaaS or self-hosted in a private VPC with SSO. On the Individual plan you either bring your own key or use their LLM provider, which they price at cost with no markup, a policy worth crediting.
The cloud makes sense when you want the agent without the platform job: the sandboxing and the upgrade treadmill become their problem. The enterprise private-VPC option is an interesting middle path, keeping the data-locality argument while outsourcing the operational one.
Who OpenHands fits
OpenHands fits teams with platform engineering capacity and a reason to use it: strict data-locality requirements, a GitLab codebase, a desire to run local or unusual models, or research work on the agents themselves. If you want to understand how coding agents work, it's the best classroom available.
It's a weaker fit for a small team that wants backlog tickets turned into pull requests this week and doesn't want to operate anything. For that team the honest choices are OpenHands Cloud or a managed agent, and the deciding factors are which tracker you live in and how you want to pay for models.
Common questions
Is OpenHands free?
The software is free and MIT licensed, and the cloud's Individual plan is free for one user with a daily conversation cap. What's never free is the model usage: you pay your LLM provider directly with your own key, or pay OpenHands' at-cost provider as you go. Self-hosting adds the cost of your own infrastructure and the time to run it.
OpenHands vs Devin: what's the difference?
They sit at opposite ends of the same category. Devin is a closed, hosted product you buy; OpenHands is an open platform you run (or let them host). Devin optimizes for turnkey; OpenHands optimizes for control and model freedom. We wrote a separate review of Devin if you're weighing that side.
Can OpenHands work with Linear?
Yes. Linear is one of the integrations listed alongside Slack, GitHub, and Notion in the OpenHands repo, and its automation system can react to Linear issues via webhooks. The deepest tracker integrations are still GitHub and GitLab, where labeling an issue gets you a pull request back.
If what you actually want is that last loop, a ticket in your tracker becoming a reviewable PR, without operating a platform, that's what Sinatra does: assign a Linear issue or label a GitHub issue, get a pull request back, on your own Anthropic or OpenRouter key with no markup. See how it compares on our alternatives page, start for free, or read the docs.