OpenHands Review: The Open-Source Coding Agent That Actually Ships

I've spent enough time wrestling with AI coding tools that over-promise and under-deliver, so when OpenHands started making noise as the open-source answer to Devin, I needed to see what the data actually says. The claims are bold: 72% on SWE-bench Verified, 100+ LLM backends, bring-your-own-key pricing with zero markup. But the real story is more nuanced than the hype suggests. After digging through the architecture, benchmarks, deployment models, and—critically—the limitations, I've formed a clear picture of where OpenHands genuinely excels and where it stumbles. This isn't a fanboy take or a hit piece; it's the detailed, evidence-based review I wish I'd had before spinning up my first Docker container.

What Is OpenHands and Why It Matters

When I look at the current wave of AI coding tools, OpenHands stands out because it carries a specific origin story: it started as OpenDevin but rebranded in late 2024 under the All-Hands AI organization. From my perspective, that rebrand signals a maturation from an experimental prototype into a structured open-source project. It is positioned squarely as the community's open answer to Devin, and unlike many closed competitors, it ships under the MIT license. That means anyone can use, modify, or redistribute it without hitting commercial restrictions.

What the MIT License Actually Means for Builders

• Unrestricted freedom: You can embed OpenHands in internal pipelines, fork it for a SaaS product, or run it locally without license anxiety.
• Community ownership: Because the license places no barriers on distribution, I expect the contributor surface to grow faster than locked-source alternatives.

The architecture is where OpenHands gets interesting. It is built as an LLM-provider-agnostic, tool-using coding agent. In practice, this means the core logic is not married to a single model endpoint; you can wire in different backends. The system runs inside a flexible, sandboxed environment that gives the agent room to both develop and deploy. I see this as a critical design choice because it mirrors how human engineers actually work: you need a safe space to write code, run tests, and push artifacts without contaminating the host system.

The End-to-End Execution Loop

The workflow is not a single-shot code generator. Instead, it spans three distinct phases:

1. Creation: The agent plans and builds filesystem artifacts based on your prompt.
2. Execution and testing: It drops into a terminal, runs tests, and reads output.
3. Deployment and publishing: It attempts to package and ship the result, closing the loop.

This iterative cycle is driven by a web UI that accepts natural-language prompts. When I examine the internal mechanics, the agent does not just emit a file and stop; it executes tests via terminal, observes failures, and iterates until completion. That feedback loop is what separates a coding assistant from an autonomous agent.

On benchmarks, the numbers are concrete. OpenHands has been evaluated against real GitHub issues, and it resolves over 50% of them in software engineering benchmarks. That metric matters because these are not synthetic coding quizzes; they are actual production issues extracted from open-source repositories. Hitting a >50% solve rate tells me the tool is not just generating syntax-correct snippets—it is reasoning about repository context, debugging, and patching.

Version Control and Real-World Friction

OpenHands also automates VCS operations, including initializing Git repositories and pushing to GitHub. However, I noticed a practical caveat: initial push attempts can fail and require configuration updates. This is a realistic rough edge. Automation is not magic; SSH keys, tokens, and remote permissions still need manual setup before the agent can truly run unsupervised.

Finally, the recommended LLM providers are Anthropic 3.5 Opus and GPT-4o. The fact that the maintainers point to these specific models suggests OpenHands demands strong reasoning and long-context capabilities to handle the multi-step planning and filesystem navigation required by the loop.

Benchmark Performance: The Hard Numbers

When I look at the raw numbers, OpenHands posts a 72% success rate on SWE-bench Verified and a 67.9% score on the GAIA Benchmark. These aren't vanity metrics. The SWE-bench result tells me the agent can consistently fix real bugs in production Python repositories, while the GAIA score confirms it can handle substantive web interaction—navigating APIs, scraping documentation, and reasoning across live sources rather than relying on static training data. To me, that combination matters because an agent that only codes from memory is far less useful than one that can look up current library signatures and adapt.

How the OpenHands Index Measures Real-World Coding

What stands out to me is that the team didn't stop at two headline figures. They built the OpenHands Index, which stress-tests models across five distinct vectors that mirror actual engineering workflows:

• Issue Resolution: Measured through SWE-Bench Verified, this tracks the agent's ability to diagnose and patch bugs in real Python GitHub repositories.
• Greenfield Development: Powered by Commit0, this evaluates whether the agent can build applications from scratch over long horizons, specifically by reimplementing stripped-out codebases from nothing.
• Frontend Development: Using a verified variant of SWE-Bench Multimodal, this tests creation and refinement of frontend applications—what many teams now call "vibe coding"—pushing the agent to manipulate UI components and visual layouts.
• Software Testing: Via SWT-Bench, this measures how well the agent identifies bugs and generates reproduction tests, not just fixes.
• Information Gathering: GAIA again serves here, but framed specifically around researching APIs and implementation details through active web search and multi-step reasoning.

The Index doesn't just rank models by accuracy. It plots each candidate along three axes that matter when you're running bills at scale:

1. Ability (accuracy): Does it actually solve the task?
2. Total cost in USD: What does each run cost your wallet?
3. Average runtime per instance: How many seconds until you get feedback?

This triad forces a practical trade-off analysis. I might choose a model that sacrifices a few percentage points of accuracy if it cuts runtime by 60% and drops the per-task cost under a cent. Conversely, for a critical security patch, I'd probably prioritize the highest ability score regardless of speed or price. That flexibility is something I rarely see in benchmark suites that only publish a single leaderboard score.

Transparency is baked into the methodology. Every evaluation ships with full trajectory data, so I can trace exactly what the agent tried, where it backtracked, and how it arrived at the final patch. The integration with Laminar adds interactive trace visualization, which means I don't have to parse raw logs to understand failure modes. Everything lives in the open: the OpenHands/openhands-index-results repository is continuously updated with metadata and scores.json files. If I want to verify a claim or reproduce a benchmark locally, the data is right there.

Architecture Deep Dive: The Four-Package SDK

When I look at how OpenHands structures its SDK, the first thing that stands out is the deliberate separation of concerns across four distinct packages. Instead of dumping everything into a monolithic library, the team split the agent's brain, its hands, the sandbox, and the serving layer into isolated modules. This isn't just tidy packaging—it fundamentally changes how you can deploy the same codebase from a laptop to a production cluster without rewriting integration logic.

Core Framework and Immutable Primitives

• openhands.sdk: This is the non-negotiable foundation that every deployment pulls in. It houses the base classes for Agent, Conversation, LLM, and the Tool System, plus an Events framework and Workspace abstraction. I notice it includes LocalWorkspace, RemoteWorkspace, Skills, Condenser, Security, and MCP integration.
• Stateless by design: Every component in the core is stateless and immutable, built on type-safe Pydantic models. That means when you're passing events or workspace states around, you get validation and serialization for free, which drastically reduces runtime surprises and makes the system far easier to reason about in multi-threaded or distributed contexts.

Pre-built Tools and the Action/Observation Pattern

• openhands.tools: Here is where the agent gets its actual capabilities. The package implements concrete tools following an Action/Observation/Executor pattern, with built-in validation, error handling, and security checks.
• Tool execution model: What's interesting is that these tools run alongside the agent in whatever environment the workspace configures—local, container, or remote—without routing through workspace APIs. That keeps latency low and avoids unnecessary abstraction overhead, since the tools execute directly in the target environment rather than bouncing through intermediate layers.
• Included tooling: You get BashTool, FileEditor, GrepTool, and MCP tool integration out of the box, giving the agent immediate filesystem and shell access with guardrails already in place.

Execution Environments and Sandboxing

• openhands.workspace: This package extends the SDK's RemoteWorkspace base with concrete implementations like Docker Workspace and Remote API Workspace.
• Container lifecycle: These implementations handle container lifecycle or API client functionality, giving you sandboxed execution for untrusted code and multi-user deployments in production. If one user's session needs isolation, the workspace layer spins up the boundary without the agent ever knowing the difference.
• Inheritance model: Because everything extends RemoteWorkspace from the SDK, the contract stays consistent whether you're spawning a local Docker container or hitting a remote orchestrator. That consistency is what makes the higher-level agent code truly portable.

Multi-User API Server

• openhands.agent_server: Built on FastAPI, this provides HTTP and WebSocket endpoints covering conversations, bash, files, events, desktop, and even VSCode integration.
• Session isolation: It manages isolated per-user sessions, API key authentication, and health checking. I see it can run inside containers via DockerWorkspace or as a standalone process connected through RemoteWorkspace, which gives operators flexibility in how they segment compute.
• Deployment flexibility: This dual-mode operation means you don't need a separate server codebase for local experimentation versus production serving. You wire up the same agent logic to a local workspace for debugging, then point it at the server deployment when you're ready to scale.

The real architectural win here is the workspace abstraction. Because the agent logic sits cleanly above the workspace layer, you can start with LocalWorkspace on your machine, swap in DockerWorkspace for containerized safety, and eventually point the same code at a RemoteAPIWorkspace in production without touching the agent implementation. That local-first, deploy-anywhere approach removes the typical "it works on my machine" cliff that plagues most agent frameworks.

Deployment Modes: Local Prototyping vs Production Sandboxing

When I look at how OpenHands splits its deployment strategy, the distinction between local prototyping and production sandboxing isn't just about convenience—it's a fundamental architectural fork. The local path strips everything down to a single-process execution model, while the production route builds out a full distributed container orchestration stack.

Local Development: Single-Process Speed

Getting started locally is intentionally lightweight. You only need two packages:

• openhands-sdk
• openhands-tools

The SDK gives you the core primitives—Agent, LLM, Conversation, and LocalWorkspace—while the tools package bundles ready-to-use executors like BashTool, FileEditor, and GrepTool. Everything runs in-process, which means tool execution hits zero network latency and carries absolutely no container startup or teardown overhead.

The performance numbers reflect that simplicity:

• Event persistence: 0.166ms median latency per event
• Action+Observation cycle: persists in 0.36ms median
• Full state replay: 4.1ms median, 9.7ms P95
• Crash recovery: 7.4ms median, 14.9ms P95
• Storage per conversation: 380KB median, 1.4MB P95

But I see a clear trade-off here. Because there is no sandboxing layer, every tool executes directly on the host machine with full access to the local filesystem and environment variables. That makes the local mode perfect for rapid iteration on trusted codebases, yet completely unsuitable for running untrusted or generated code without external isolation.

Production Sandboxing: Distributed Container Orchestration

Flipping to production mode changes the install footprint to four packages:

• openhands-sdk
• openhands-tools
• openhands-workspace
• openhands-agent-server

Here, DockerWorkspace automatically spawns agent servers inside containers, giving each user an isolated workspace with dedicated filesystem boundaries and resource limits.

This shift introduces real overhead. Tool execution now travels over HTTP/WebSocket to the agent server, and DockerWorkspace initialization adds roughly 1–2 seconds of container startup latency. The persistence metrics remain impressive but show the network tax:

• Per-event persist latency: 0.20ms median, 0.31ms P95
• Action cycle persist: 0.40ms median, 0.56ms P95
• Crash recovery: 7.4ms median, 14.9ms P95—staying under 20ms even for conversations as large as 358 events

Storage characteristics also shift. Growth becomes linear at approximately 624 bytes per event, and I find it notable that ObservationEvents chew up 78% of total storage despite representing only 48% of events. That suggests observation payloads—likely tool outputs and command returns—are the dominant storage driver.

On the resource front, defaults are set to:

• 2GB RAM
• 2 CPU cores
• 10GB disk
• 5-minute timeout per task

For scaling, the architecture supports:

1. Horizontal scaling behind a load balancer
2. Kubernetes deployments with auto-scaling
3. Shared state stores via Database or Redis for multi-server setups
4. Configurable idle timeouts (defaulting to 1 hour)
5. Adjustable per-workspace memory, CPU, and disk limits

LLM Flexibility: 100+ Backends and the BYOK Advantage

When I examine OpenHands' LLM architecture, what stands out immediately is its refusal to lock users into a single vendor. The project acts as a thin orchestration layer rather than a model provider, routing requests through a provider-agnostic interface built on LiteLLM. I can point it at over 100 backends—including Claude, GPT-5, Mistral, Llama, or any OpenAI-compatible API—without rewriting integration logic. Because there is no hosted SaaS product, the pricing model is strictly bring-your-own-key with zero platform markup. I pay the model provider directly for inference, which keeps costs transparent and predictable. Self-hosting requires Docker and an LLM provider API key, and that is the only way to run it. That design choice tells me the maintainers prioritize user sovereignty over convenience.

Local Serving as a First-Class Citizen

The SDK does not treat local inference as an afterthought. The uniform LLM interface means identical code works against both cloud APIs and local servers, which effectively eliminates vendor lock-in. LiteLLM provides native support for several local serving frameworks:

• Ollama: model='ollama/llama3'
• SGLang: model='sglang/llama3'
• vLLM: model='vllm/llama3'
• LM Studio: model='lmstudio/llama3'

Switching to a local endpoint is straightforward. For example, connecting to Ollama looks like this:

llm = LLM(model='ollama/llama3', api_key='ollama', base_url='http://localhost:11434')

When I look at that configuration, it is clear the abstraction is deep enough that the rest of my agent code remains unchanged whether I am hitting a cloud API or a GPU under my desk.

The Cost Economics of a Hybrid Strategy

The project provides concrete cost estimates that make a hybrid approach compelling. Based on their numbers:

• GPT-4-Turbo (proprietary API): ~$0.01 per 1K input tokens and ~$0.03 per 1K output tokens
• Local Llama 3 70B: ~$0.002–0.005 per 1K input tokens when amortizing hardware and energy costs
• Local Llama 3 8B: ~$0.0005–0.001 per 1K input tokens under the same amortization

Those gaps are significant. At scale, a workflow generating hundreds of thousands of input tokens could cost over a dollar on GPT-4-Turbo versus mere pennies on an 8B local model. To me, the logical split is obvious: I would use local models for high-volume, low-complexity tasks like code generation and refactoring, where token volume is high but reasoning demands are modest. Then I would reserve proprietary APIs for low-volume, high-complexity work like architecture design and deep debugging, where output quality matters more than per-token cost.

Who This Model Serves Best

The MIT licensing is a practical enabler here, because it permits combining OpenHands with permissively licensed open-weight models without commercial restrictions. I see this setup fitting three profiles especially well: open-source teams that need fully auditable stacks, developers who insist on direct control over data and model weights, and budget-conscious practitioners who already hold API credits and have no interest in paying a middleman markup.

Honest Limitations: Where OpenHands Falls Short

When I examined the OpenHands architecture, the most critical limitation is immediately apparent: the agent has a hard dependency on state-of-the-art large language models and cannot function with local or smaller models that lack sufficient context windows. The failure mode is structural, not cosmetic. OpenHands operates by feeding iterative code context, execution traces, and sandbox outputs back into the model in a tight loop. Smaller models simply cannot absorb the volume of multi-file context and error logs required for meaningful agentic development. While the codebase supports Ollama as a backend, pointing OpenHands at a local Llama 3 8B instance is largely a theoretical exercise. In practice, the agent's reasoning degrades substantially compared to Claude or GPT-4-class models, because the 8B parameter budget cannot maintain coherence across long context horizons filled with stack traces and directory trees.

Model Requirements and Local Deployment Reality

• Context window bottleneck: The iterative agent loop requires retaining substantial code context, test output, and previous turn history. Smaller models hit their context limits quickly, causing the agent to lose track of earlier decisions or ignore critical file dependencies.
• Ollama compatibility ≠ usability: You can configure a local endpoint, but the practical result is often a broken or truncated workflow. The model may generate syntactically valid code that ignores the broader project structure because the relevant files were evicted from the context window.
• No fallback for offline work: Because local performance is non-viable, OpenHands is not a drop-in tool for air-gapped or fully local deployments. Teams hoping to avoid cloud API costs will find the trade-off unacceptable.

Security Isolation and Runtime Latency

The security model splits sharply between local and sandboxed execution, and neither option is clean. In local development mode, I noticed there is no built-in sandboxing for security isolation. All generated code executes directly on the host machine with unrestricted access to the local filesystem and environment variables. That is a significant risk for untrusted code execution; one malicious or buggy dependency install could compromise the developer workstation.

Switching to production or sandboxed mode solves the isolation problem by containerizing the workspace, but the architecture introduces measurable latency. Each DockerWorkspace initialization adds approximately 1–2 seconds of startup overhead, and every tool execution incurs additional network latency via HTTP or WebSocket transport. During iterative debugging, those delays compound. A workflow that triggers dozens of container initializations or tool calls will feel noticeably sluggish compared to native local execution.

Integration Limits and Operational Overhead

On the integration front, the GitHub push workflow can fail on initial attempts and requires manual configuration tweaks to stabilize. More fundamentally, there is no hosted SaaS product. Teams must manage their own Docker infrastructure, wire up their own LLM provider API connections, and maintain the runtime environment.

OpenHands follows a strict bring-your-own-key model. While this keeps direct costs low and prevents vendor lock-in, it shifts substantial operational complexity to the user. I find that managing API keys, monitoring token burn rates across different providers, and handling rate-limit retries all fall on the operator. Compared to Devin, which markets itself as a fully automated AI teammate capable of replacing junior software engineers on simple tasks, OpenHands demands more manual assembly. It is genuinely open-source and extensible, but that openness comes with setup and maintenance overhead that teams need to factor into their adoption plans.

Verdict: Who Should Use OpenHands and Who Should Wait

After spending time with the codebase and benchmarks, I see OpenHands as a tool that makes no apologies for its complexity—and that is exactly why it works for certain users. It is not a consumer product, and the developers seem intent on keeping it that way. Instead, it functions as a high-trust, high-control engine for teams that treat AI coding agents as infrastructure rather than a magic button.

Where OpenHands Earns Its Keep

I break down the ideal user base into three clear groups. First, open-source teams that demand full control and auditability over their coding agent stack. When every inference step and tool call must be traceable, a black-box SaaS simply will not do. Second, budget-conscious developers who already hold API credits with frontier model providers. OpenHands runs on a bring-your-own-key model with zero platform markup, which means you pay for tokens and nothing else. Third, engineering teams building proprietary AI-powered development tools who need a production-grade SDK. The four-package modular architecture gives them the flexibility to embed, extend, or repurpose components without fighting a monolithic framework.

The performance numbers back up the architectural promise. I look at the 72% SWE-bench Verified score and the 67.9% GAIA benchmark, and I see genuine capability across both code generation and web interaction. These are not vanity metrics; they indicate the agent can handle real software engineering tasks and navigate external systems with a reasonable degree of autonomy.

The Engineering Rigor Behind the Modularity

What impresses me most is the workspace abstraction. The system allows you to move from LocalWorkspace to DockerWorkspace to RemoteAPIWorkspace without rewriting application logic. That kind of portability matters when you are prototyping on a laptop but eventually need to ship to a remote cluster. The architecture genuinely enables local-first, deploy-anywhere development.

The persistence layer is equally serious. In local mode, I noticed sub-millisecond event persistence, which keeps the feedback loop tight during iterative debugging. Even more telling is the crash recovery: the system recovers conversations with under-20ms latency even for 358-event histories in production mode. That level of resilience suggests the event store and state management were built by people who understand that agent sessions are long, messy, and prone to interruption.

The Trade-Offs That Filter Out Casual Users

That said, OpenHands draws a hard line on hardware and operations. The requirement for state-of-the-art LLMs with large context windows is non-negotiable. If you are hoping to run this fully offline with a small parameter model, you will hit a wall. The agent needs the context headroom to track files, errors, and tool outputs across extended sessions.

Security is another consideration. The lack of sandboxing in local mode means untrusted code executes on your host filesystem. I would not run an unknown generated script without switching to DockerWorkspace or another isolated environment. It is a real gap that demands user awareness.

Finally, there is no hosted SaaS option. Every team must manage its own Docker infrastructure, model provider integrations, and scaling logic. For a solo developer or a small startup looking for a zero-config experience, that operational overhead is significant. You are not just adopting a tool; you are adopting an ops workload.

Final Assessment

For teams already comfortable managing containers and paying for frontier API access, OpenHands stands out as one of the most transparent and architecturally sound open-source coding agents I have evaluated. The zero-markup pricing, modular SDK, and honest benchmarking make it a strong foundation for serious AI-native development workflows. However, if you need a fully local, cost-free setup or a managed service that just works out of the box, the current release will likely frustrate you more than it helps. My advice: adopt it if you have the infrastructure muscle and the model budget; wait for a hosted tier if you do not.