Ask most developers what their AI coding assistant does for them, and you will hear a variation on autocomplete: it suggests a line, finishes a function, or writes the next test. OpenHands belongs to a different category. It takes a messy GitHub issue, opens your repository, writes code, runs the test suite, and keeps iterating until the intended result actually works. That sounds like a tall claim for an open-source project. It is.
OpenHands is quickly becoming a reference point in the open-source agent space. To understand where it shines, where it struggles, and how to put it to work, it helps to spend a few minutes looking under the hood.
What Is OpenHands?
OpenHands is an open-source platform for autonomous software engineering agents. It is not a single model. You connect OpenHands to an underlying LLM, then give the agent a full working environment: a Linux shell, file editor, and in many configurations a browser. From that shell it behaves like a human teammate who can operate a computer.
Its roots lie in OpenDevin, a research project launched by MIT, Carnegie Mellon, UC Berkeley, and other labs in early 2024. The core idea was to build an open assistant that does not just suggest code but runs it, watches the output, and adapts. Our earlier article on OpenDevin explains the community details. Since then, the project has been renamed OpenHands and is developed under the All Hands AI organization, with a growing group of contributors focused on reproducible agent research.
How OpenHands Turns a Prompt into a Patch
Suppose you paste a bug report into OpenHands: “The downloader crashes when Wi-Fi drops for more than a second.” A normal code completion tool cannot recover from that alone. OpenHands breaks the task down like this:
- Open the source file that owns the download logic.
- Search the surrounding functions to understand how errors are handled.
- Write a retry wrapper with an exponential backoff.
- Add a unit test that simulates a connection failure.
- Run the tests, notice a failure, and revise the implementation.
- Return with a summary of the changes and test output.
That list is not aspirational. In simple repos, OpenHands does all of it. The underlying loop repeats a small rhythm: act, observe, adjust. It starts with an instruction, turns it into a command, reads what the shell or editor returns, and decides whether the goal is complete.
Every run happens inside an isolated sandbox unless you explicitly point OpenHands at a local workspace. That means a bad delete command won’t wipe your real code. Each context is separated, so you can test an architecture or refactor without contaminating other projects.
Why the Brain Behind OpenHands Matters
OpenHands does not contain coding intelligence itself. It is a control layer around many possible language models. You can attach Anthropic, Google, OpenAI, DeepSeek, or a local model served through Ollama. That flexibility is one of its biggest advantages, but it creates surprises. A model that scores well on a code benchmark can still get lost when it has to search many files and choose a fix after ten failed attempts.
For developers who want to keep everything self-hosted, open-weight models are part of the appeal. IBM’s Granite 4.2 family, for instance, includes compact models that perform well on code-related tasks. If you want to compare agent-ready models, our breakdown of how Granite 4.2 LLMs are built offers the architecture and decisions. The short version is this: models trained with agentic tool-use patterns tend to produce better sequences in OpenHands, so choose the underlying model carefully.
Where OpenHands Eases Real Work
OpenHands is more than a proof of concept. Once past the first “wow”, developers find solid uses for it:
- Refactor legacy code across many files while maintaining consistent style.
- Update documentation after an API change.
- Write missing unit tests for a code function.
- Automate the repetitive labor found in dependency upgrades.
- Prototype a small service from a one-line architecture description.
Those jobs all involve many files and feedback loops. OpenHands is good at exactly that mix. It can also validate a new toolchain setup because it can run the resulting binary, not just print it.
Honest Limitations of OpenHands
OpenHands still hits a few walls. Large repositories can slow it down. If a project has thousands of modules and a nonstandard build system, the agent may spend many turns hunting for the right file. Token costs can also accumulate with high-end models, and an ambitious refactor might cost more than you expect.
Context is another limit. The agent does not remember your preferences between sessions unless you write them into a project file. Restart the sandbox and it starts from scratch. For a helper that works alongside humans, that is acceptable, but do not treat it as a roving central brain with permanent memory.
Getting Started with OpenHands
You can start small. Clone the OpenHands repository from GitHub, follow the Docker setup guide, and decide which model endpoint to use. The web interface asks you to describe a task and lets you watch the agent’s steps in real time. Keep the first assignment contained: ask it to fix a linting rule in a tiny library, not to redesign a microservice that nobody fully understands.
Watch a few sessions before employing it on valuable branches. When a task is clear, the sandbox is active, and tests exist to verify progress, OpenHands feels like a junior contributor with a fast typing speed. When the task is vague, it spends time guessing, and everyone learns less. Start there, be ready to review its work, and let OpenHands show what it handles well. For many teams, an agent that can run a loop and act on the result is more useful than one that can simply predict the next token. That is the cleanest way to measure what OpenHands brings to the table.