OpenHands

OpenHands, originally released as OpenDevin, is an open-source platform for building and running AI agents that carry out software development work. An AI agent, in this sense, is a program that repeatedly observes the state of some environment, decides what to do next, and acts — as opposed to a system that answers a single question and stops. What distinguishes OpenHands from code-completion tools is the breadth of what its agents are allowed to do: rather than proposing text for a developer to accept, an OpenHands agent writes and edits files, runs commands in a terminal, executes code, and browses the web, looping until a task is judged complete.^[1:1]

The project began on March 12, 2024 and was created by Binyuan Hui and Junyang Lin, researchers at Alibaba working on the Qwen family of large language models. It was named OpenDevin as an homage to Devin, a closed-source commercial agent demonstrated shortly before by the company Cognition AI, and was renamed once several early contributors founded the company All Hands AI to carry the work forward.^[2:1] The software is distributed under the MIT License, which permits commercial use and modification.^[1:2]

OpenHands has been rebuilt once. The original design, which its authors retrospectively call V0, is described in a paper presented at the Thirteenth International Conference on Learning Representations in 2025.^[1] A complete architectural redesign, V1, was published as a preprint in November 2025 and moved the agent logic into a separate software development kit.^[3:1] As of August 2026 the primary user-facing component is Agent Canvas, a self-hosted interface for running OpenHands agents and third-party agents side by side.^[4:1]

Origins

The project's stated motivation was the closed nature of the system that inspired it. Devin was demonstrated in March 2024 as an agent that could plan and execute engineering tasks end to end. Robert Brennan, who became All Hands AI's chief executive, told TechCrunch that the demonstration impressed him but also alarmed him: the technology was being developed behind closed doors, in what he called a walled garden the wider development community could not see, contribute to, or own.^[5:1] The academic paper makes the same lineage explicit in a footnote, adding that the project quickly grew beyond software engineering as contributors extended it.^[1:3]

The originators did not join the company that grew out of the project. Robert Brennan has said that investors approached within a week or two of the project taking off, and that he then spoke individually with all six people who had been early to it — himself, Neubig, Xingyao Wang, Junyang Lin, Binyuan Hui, and Bowen Li — about founding one. Lin, Hui, and Li declined, which Brennan attributes to their existing careers at Alibaba and at a research lab in China; the other three went ahead.^[6:1] Because the code is under the MIT License, no transfer of ownership was required for this: what changed was stewardship of the project, not title to it. Hui and Lin remained co-authors of the 2025 platform paper under Alibaba affiliation, credited there with benchmark integration and with advisory support and sponsored computing resources respectively.^[1] This account rests on the company's own retrospective, and no independent record of the transition was located; contemporaneous repository and discussion archives, or comment from Hui and Lin, would corroborate or correct it.

All Hands AI announced a $5 million seed round on September 5, 2024, led by Menlo Ventures. Brennan described a plan to fund the open project by selling closed-source enterprise features on top of it — an arrangement usually called an open-core model — and said human developers would remain necessary in the loop for a long time to come.^[5:2]

Growth figures reported by the project itself trace its adoption: roughly 32,000 GitHub stars and 188 contributors when the first paper was written,^[1:2] over 50,000 stars and 250 contributors by March 2025,^[2:1] and 85,500 stars by August 2026.^[4:1] These are self-reported popularity metrics rather than measures of use, and GitHub stars in particular track attention more closely than deployment.

The code has moved between GitHub organisations. The 2025 paper gives the repository address as All-Hands-AI/OpenHands,^[1] while the current repository is OpenHands/OpenHands.^[4:1] The date and circumstances of that move, and any corresponding change to the company's own name, are not documented in any source consulted for this article; the question could be settled by an announcement from the project or by inspecting the repository's redirect history.

Architecture

The original design

The V0 architecture rests on three parts: an agent abstraction, an event stream, and a runtime.^[1]

The event stream is a chronological log of everything that has happened in a session — every action the agent took, every observation that came back, and every message from the user. An agent is defined by a single function that reads this history and returns the next action; the framework handles everything else. This separation means a new agent can be written without touching the machinery that actually runs commands.^[1:1]

The runtime turns actions into observations. For each session OpenHands starts an isolated Docker container running a small API server, which maintains a bash shell, a Jupyter IPython server for interactive Python, and a Chromium browser controlled by Playwright. A directory of the user's choosing is mounted into the container so the agent can work on real files without free rein over the host machine. Because the API server can be installed into any user-supplied Docker image, an agent can be given whatever software environment a project needs.^[1:4]

Two further mechanisms sit on top. An AgentSkills library packages utilities that language models handle poorly when writing raw code — line-precise file editing, scrolling through long files, extracting text from PDFs and images — as Python functions automatically available to the agent. A delegation action lets one agent hand a subtask to another, so a generalist coding agent can pass a browsing task to a specialised web agent.^[1]

The V1 redesign

The redesign was driven by problems the maintainers attribute to early design decisions. Sandboxing had been mandatory, which split each conversation across two processes that could crash or drift out of step independently; supporting local execution meant maintaining duplicate code paths. Configuration had sprawled to more than 140 fields across 15 classes and roughly 2,800 lines, with separate hierarchies for the command line, web interface, GitHub app, and hosted service, to the point where two runs with identical parameters could diverge. And because research benchmarks and production applications shared one repository, benchmark dependencies leaked into deployments.^[3:2]

V1 answers each of these. The code is split into four Python packages — a core SDK, tool implementations, execution environments, and an API server — so that each can be tested and released independently. Sandboxing became opt-in rather than universal. Agents, tools, and model configurations are immutable objects validated when they are constructed; the only thing that changes during a run is a conversation state object holding an append-only event log. This pattern, known as event sourcing, means a session can be persisted incrementally and later resumed by replaying its events.^[3:1]

Security is handled by two separate components, which keeps the judgement of risk apart from the decision of what to do about it. A security analyzer rates each proposed tool call as low, medium, high, or unknown risk. A confirmation policy then decides whether that call needs human approval; if it does, the agent stops and waits, and may try a safer approach if the user refuses. The shipped default blocks anything above high risk, and the policy can be loosened or tightened mid-session.^[3:3]

Models

OpenHands is model-agnostic by design. It reaches more than 100 model providers through LiteLLM, a library that presents many different model APIs behind one interface. Models that cannot natively call tools are supported by translating tool definitions into ordinary text instructions and parsing the model's replies back into tool calls, which widens the range of usable models considerably. A routing class allows a single conversation to use several models — sending images to a multimodal model and plain text to a cheaper one, for instance.^[3:4]

The project has also shaped model development directly. Devstral, released in May 2025 under the Apache License 2.0, was built by Mistral AI in collaboration with All Hands AI and trained specifically to work inside agent scaffolds such as OpenHands. Mistral reported it resolving 46.8% of SWE-Bench Verified issues within the OpenHands scaffold, ahead of far larger models evaluated the same way, while remaining small enough to run on a single consumer graphics card or a Mac with 32 GB of memory.^[7:1]

Evaluation

OpenHands ships an evaluation framework covering 15 benchmarks across software engineering, web browsing, and general assistance.^[1] Three recur most often:

• SWE-Bench presents an agent with a real issue report from an open source repository. The agent edits the codebase; its patch is then judged by running the test suite that the human maintainers wrote when they fixed the same issue. SWE-Bench Lite is a 300-instance subset; SWE-Bench Verified is a 500-instance subset screened by hand for solvability.
• WebArena consists of 812 human-written tasks on self-hosted replicas of real websites, checking whether an agent can navigate and complete goals in a live web environment.
• GAIA poses general assistant questions requiring some combination of reasoning, web browsing, tool use, and handling of images or documents.^[1]

Reported results have risen sharply, though the two rows below are not directly comparable — they use different benchmark subsets, different underlying models, and different versions of OpenHands itself.

The 2024 figures were obtained without the hint text that SWE-Bench optionally supplies, and the paper records per-instance costs alongside them — $1.10 on average for the best-performing configuration, against $0.01 for the cheapest and weakest.^[1:5] The V1 figures are stated to come from one specific commit of the SDK paired with one specific commit of the benchmark harness.^[3:5]

Both sets of numbers are self-reported by the system's own developers, and how far performance on curated benchmark issues predicts performance on unfamiliar production codebases remains an open question. Independent replication would settle it; no such replication is cited here.

Deployment

Agents can be run on a laptop, on a dedicated machine, on a virtual machine, or on the commercial OpenHands Cloud service. The documentation is explicit that the simplest installation, which runs without a sandbox, gives the agent full access to the host filesystem.^[4:1]

Agent Canvas, in beta as of August 2026, is the current front end. It connects to one or more agent backends and can switch between them, so that a team might share a server for routine work such as dependency updates while individual developers run their own agents locally. It also runs agents other than OpenHands — including Claude Code, Codex, and Gemini — through the Agent-Client Protocol, and can trigger agent runs on a schedule or in response to webhooks from services such as Slack, GitHub, and Linear. The project is now split across four repositories, with the Python SDK and agent server maintained separately from the interface.^[4:1]

Analysis: openness and developer agency

This section presents evaluation by Agpedia contributors rather than sourced description, and should be read as such.

The question OpenHands poses is not whether agents write competent code but who controls the loop they run in. Three of its design choices bear directly on that.

First, model-agnosticism keeps the substitution costs low. A developer whose agent framework is welded to one vendor's models has limited recourse if pricing, availability, or model behaviour changes. Reaching 100-plus providers through a common interface, and supporting models that lack native tool-calling, makes switching a configuration change rather than a migration.^[3:4] The Devstral collaboration extends this to the model layer itself: a permissively licensed model that runs on a single consumer GPU means an agent workflow can be operated with no external dependency at all.^[7:1] That matters most for the people with the least leverage — individual developers, small teams, organisations handling code they cannot send to a third party.

Second, the confirmation mechanism treats human approval as architecture rather than etiquette. Risk-rating each action and halting for approval above a threshold builds a supervision point into the control loop, where many systems leave oversight to whatever the user notices in a log.^[3:3] The project's own ethics statement makes this framing explicit, arguing that facilitating human-agent interaction — rather than autonomous operation without oversight — is one of the ways it reduces risk.^[1:6] The safeguard is real but bounded: a threshold that must be relaxed to make the agent useful will tend to get relaxed, and an approval prompt only preserves agency if the person approving still understands what they are approving.

Third, openness here is partial by design. The open-core model was stated from the outset: enterprise features are closed so that enterprise revenue sustains the open project.^[5:2] This is a defensible bargain and a common one, but it means the coordination features organisations most depend on may sit on the closed side of the line, while the self-hostable core remains genuinely forkable. Whether that leaves real independence or only nominal independence depends on which capabilities end up where — something only observable over time.

A cost cuts across all three. Brennan framed the goal as removing toil so developers can concentrate on creative work.^[5:2] Toil, though, is also how much of a codebase gets learned. Writing the tests and chasing the dependency updates is how a developer builds the situated knowledge that later makes them competent to review an agent's patch. Delegating that work wholesale risks hollowing out the very expertise the supervision model assumes. Whether agent-assisted development erodes or strengthens developer understanding over a career is an empirical question that current evidence does not answer, and the benchmark results reported above bear on capability, not on that.