OpenHands (formerly OpenDevin)

1. Introduction

1.1. Platform Positioning

OpenHands (formerly OpenDevin) is an open-source autonomous software engineering Agent platform led by All Hands AI, whose public narrative is to "take autonomous software engineering from demo to enterprise-grade infrastructure." It is a representative project in the "open-source Devin alternative" track: benchmarking against Cognition's closed-source product Devin (see the existing 10-devin.md), with open-source licensing, self-hosting, and model-agnosticism as its core differentiators.

An important signal in 2026 is the reconstruction of the product form: the old local GUI/CLI form has been marked legacy, and the current form has shifted toward a platform combination of "Agent Canvas + Software Agent SDK + CLI/headless + cloud + self-hosted runtime backend," expanding from a single Agent to thousands of concurrent Agents. This means OpenHands has evolved from "an open-source coding Agent" into "an open-source runtime foundation capable of hosting large-scale Agent fleets."

1.2. Basic Information Card

1.3. Development Timeline

Note: OpenHands iterates extremely quickly; this article follows the public claims as of the 2026-09-12 information cutoff. Specific version numbers have not been individually verified and are marked [To be verified].

1.4. Position in the AI Harness System

By the parameter card boundary definition, OpenHands sits at the open-source platform form between Agent Framework and vertical products:

• It provides a complete product form (Canvas, cloud, CLI), going beyond the scope of a pure framework;
• But its Harness full stack is open-source and auditable, unlike Devin/Manus which cannot be verified;
• Comparison with other open-source platforms in the group: LangGraph provides orchestration primitives (mainly L3), while OpenHands provides a complete runtime for software engineering scenarios (sandbox, tools, UI, and fleet orchestration all present)—the latter is the only representative of the "vertical scenario + open source" approach in this group;
• Across the three-generation architecture evolution, OpenHands is one of the few open-source projects to leap directly from the second generation (single-Agent tool execution) to the third generation (runtime and evaluation center + thousand-level concurrency).

2. Glossary

3. Feature Description

3.1. Autonomous Software Engineering Capabilities

OpenHands' core capabilities target the software engineering closed loop:

1. Code modification: read and write repository files, perform multi-file edits;
2. Command execution: run shell commands (build, test, scripts) in the sandbox;
3. Browser operation: access web pages, consult documentation and issue context;
4. Git operations: branch management, commits, producing PRs;
5. Task autonomy: autonomously plan from an issue description and execute through to PR delivery.

3.2. Form Evolution: From a Monolithic GUI to Platformization

The engineering implication of this refactor: splitting the "single-Agent product" into an "orchestration surface + development surface + runtime surface," so third parties can integrate just one layer—this is a typical move in the leap from application to infrastructure.

3.3. Multi-Agent Concurrent Collaboration

The official claim supports thousands of concurrent Agents: suited to large-scale batch tasks (such as whole-repository dependency upgrades and batch issue triage). This capability depends on the scheduling and isolation design of the runtime backend; specific scheduling policies and resource limits are not public and marked [To be verified].

3.4. Hardware and Cost Roadmap

OpenHands partners with AMD to strengthen on-device inference and cost structure: running Agent workloads on non-NVIDIA hardware reduces dependence on a single GPU ecosystem. For cost-sensitive self-hosting users, this is a practical option that differentiates it from closed-source competitors.

4. Platform Architecture

4.1. Five-Form Layering

1. Interaction and orchestration layer: Agent Canvas (visual orchestration) + cloud workbench;
2. Development layer: Software Agent SDK (Python), for customizing Agent behavior and tools;
3. Runtime layer: CLI/headless (automation) + cloud/self-hosted runtime backend;
4. Isolation layer: Docker sandbox—each Agent session runs in an independent container;
5. Model layer: model-agnostic, connecting any LLM (including local models, aligned with the AMD on-device roadmap).

4.2. An issue-to-PR Execution Flow

1. Task injection: a GitHub issue is dispatched via Canvas or headless mode;
2. Environment preparation: the runtime backend spins up a Docker sandbox and clones the target repository;
3. Context assembly: repository structure, issue content, and relevant retrieval results enter the Event Stream;
4. Autonomous loop: plan → edit → command execution → test → Condenser compresses history → re-plan;
5. Artifact output: commit a branch and generate a PR, accompanied by the execution trace;
6. Observation trail: the Event Stream fully records each interaction for replay and attribution.

5. Harness Design

5.1. Six-Layer Capability Overview

Strong/weak layer judgment: L2 and L3 are strengths (sandboxed execution and fleet orchestration), L1/L4/L5 depend on community evolution, and L6 is the weakest layer—open-source auditability is the baseline, but organization-level permissions, audit reports, and cost guardrails must be self-built.

5.2. L1 Context Engineering Layer

• Condenser is OpenHands' signature L1 mechanism: the event history generated by Agent-environment interaction is trimmed by a compressor, keeping only content useful for subsequent decisions—this is a direct engineering response to "context window economy" in an open-source implementation;
• Retrieval augmentation relies on real retrieval within the execution environment (grep, file reads); repository-level semantic indexing capability;
• Comparison within the group: not as strong as Claude Agent SDK's progressive disclosure and Skills mechanism, but Condenser's open-source implementation can serve as a reference for self-building.

5.3. L2 Tools and Execution Layer

• Docker sandbox: an independent container per session, with real execution capability (coding, CLI, browser);
• Compared with Devin's managed VM: Docker container isolation is weaker than microVM/VM-level isolation, but it buys zero-friction self-hosting;
• Compared with Claude Agent SDK: both follow the "give the Agent a computer" approach; OpenHands' computer is a container, and the entire environment definition is open-source and reproducible;
• Tool extension is implemented via the SDK, and the community ecosystem has contributed many domain tools.

5.4. L3 Orchestration and Control Layer

• Thousands of concurrent Agents is the boldest orchestration-scale claim among the open-source platforms in this group, pointing to "batch task fleets" rather than "complex single-task orchestration";
• Agent Canvas provides the visual orchestration surface; public documentation on task-flow organization is limited;
• Compared with LangGraph: LangGraph excels at fine-grained control flow for single tasks (graphs, interrupt, time travel), while OpenHands excels at horizontal scaling of task count—the two "strengths" of L3 differ in meaning;
• The loop within a single Agent remains planning-execution-observation; interrupt and resume primitives.

5.5. L4 Memory and State Layer

• Event Stream is the unified carrier of state and memory: all interaction events leave a trail and can be replayed;
• Checkpoint and resume-from-breakpoint mechanisms;
• Cross-session long-term memory (user preferences, accumulated project knowledge) shows no systematic mechanism and requires external systems to fill the gap.

5.6. L5 Evaluation and Observation Layer

• The Event Stream is naturally an observation data source: every interaction can be replayed and audited;
• Historically the OpenHands team has been deeply involved in the SWE-bench evaluation ecosystem, with methodological accumulation around "benchmark-driven improvement";
• But systematic evaluation for production environments (regression suites, A/B, online metrics) shows no productized capability and needs external hooks (such as LangSmith-type tools);
• The latest SWE-bench results and evaluation configuration were not verified in this round of research and are marked [To be verified].

5.7. L6 Governance and Security Layer

• Open-source auditability: MIT core code is fully auditable—this is the essential difference from closed-source vertical products (Devin/Manus);
• Self-hosting sovereignty: when the runtime backend is self-hosted, data does not leave the domain;
• Shortfalls: organization-level RBAC, audit reports, cost guardrails, and guardrail models all need to be self-built; the PolyForm enterprise catalog hints that commercial governance lives on the enterprise side, but public details are limited;
• Docker isolation is weaker than microVM-level isolation against malicious prompt injection; high-risk scenarios require additional host hardening.

5.8. Platform Architecture Layering Diagram

Figure 17-1 | OpenHands' platform form and the Harness bearing surface

Data sources: OpenHands' official repository and public reports (as of 2026-09-12); illustrative.

6. Real-World Cases

Case 1: Participation in the SWE-bench evaluation ecosystem (historical claim)

OpenHands (formerly OpenDevin) has continuously participated in the SWE-bench series of evaluations since 2024, and is one of the earliest open-source Agents to systematically compete on the leaderboard. The latest results and evaluation configuration were not verified in this round of research and are marked [To be verified].

Case 2: Community scaling (third-party claim)

Its GitHub 74,000—81,000 stars (varies by snapshot) make it one of the largest open-source projects in the software engineering Agent track; the 2026-02 media report confirmed its platformization transition and community activity. The scaled case of multi-Agent concurrent collaboration (thousands of Agents) is an official claim; no third-party verification was found.

Parts with no public quantitative data found: enterprise customer production deployment cases, controlled head-to-head comparisons with Devin, and quantitative data on task success rates and cost savings were all not found. These are truthfully noted here and not filled in.

7. Summary

7.1. Strengths

1. Open-source auditability: the MIT core full stack is readable, modifiable, and self-hostable, avoiding closed-source lock-in;
2. Solid L2: Docker sandbox + real execution (coding, CLI, browser, Git) fully covers the software engineering action surface;
3. L3 scale ambition: an open-source implementation of thousands of concurrent Agents, pointing to batch task fleet scenarios;
4. Condenser mechanism: an open-source context compression implementation that can serve as a reference for self-building;
5. Model-agnostic: connects any LLM, including local models and the AMD on-device roadmap, with manageable cost;
6. Clear license layering: MIT core + PolyForm enterprise catalog, with a clear boundary between open source and commercialization.

7.2. Weaknesses

1. Weak L6: organization-level permissions, audit, and cost guardrails must be self-built;
2. Limited isolation level: Docker is weaker than microVM/VM, and high-risk scenarios require hardening;
3. Evaluation not productized: L5 relies on raw Event Stream data, and systematic evaluation requires external hooks;
4. Form-migration growing pains: during the period when legacy and new platform forms coexist, documentation and tutorials are fragmented;
5. Insufficient architecture documentation: public documentation for Agent Canvas and the SDK is limited, raising the bar for deep customization;
6. Missing long-term memory: cross-session memory must be filled in by external systems.

7.3. Applicability Boundaries

7.4. Selection Recommendations

• With limited budget but needing Devin-level capability: self-hosted OpenHands is the most realistic option in this group;
• For fine-grained control of single-task control flow: choose LangGraph (see 04-langgraph.md); for horizontally scaling task count: choose OpenHands;
• For out-of-the-box governance in regulated industries: closed-source managed (Devin) or cloud platforms (AgentCore, Bailian) take less effort; OpenHands requires investing in self-built governance;
• Before adoption, it is recommended to test SWE-bench-type tasks on your own codebase to verify the real success rate of the current version.

Information Gap Statement

1. Latest SWE-bench results: the results and evaluation configuration of the latest version on the SWE-bench series of benchmarks have not been verified, marked [To be verified].
2. Agent Canvas architecture documentation: the capability boundaries and documentation details of the orchestration surface have not been verified, marked [To be verified].
3. Thousand-concurrency implementation details: scheduling policies, resource limits, and failure handling are not public.
4. Version numbers and release cadence: specific version numbers have not been individually verified, marked [To be verified].
5. Long-term memory mechanism: no systematic public description was found.
6. AMD partnership details: the specific hardware models and performance data for on-device inference are not public.

8. References

1. OpenHands — GitHub official repository (All Hands AI). https://github.com/All-Hands-AI/OpenHands
2. OpenHands — official documentation. https://docs.all-hands.dev/
3. All Hands AI — official website. https://www.all-hands.dev/
4. Report on OpenHands' platformization transition — Tencent News, 2026-02. https://news.qq.com/rain/a/20260226A06VSE00
5. SWE-bench — official benchmark website. https://www.swebench.com/
6. Best Open Source AI Coding Tools 2026 — frontman.sh (status verification). https://frontman.sh/blog/best-open-source-ai-coding-tools-2026
7. AMD — official website (on-device inference partnership background). https://www.amd.com/
8. Docker — official documentation on container isolation technology. https://docs.docker.com/
9. R18-IDE-Agents-supplementary-platform research report — internal research report for this project (AG-3 key fact card).
10. Project parameter card v1.1 (six-layer capability model and genealogical boundaries) — internal baseline document for this project.