Ist OpenHands kostenlos?

Das Open-Source-Projekt steht unter MIT-Lizenz und ist kostenlos lauffähig. Die Preisseite listet eine kostenlose lokale Stufe und eine kostenlose Individual-Stufe für die gehostete Cloud, die den eigenen Schlüssel mitbringen oder Modelle zum Einkaufspreis nutzen kann; für SaaS oder Self-Hosting in der eigenen VPC gilt individuelle Preise.

Was ist Agent Canvas?

Agent Canvas ist das aktuelle Web-Frontend: Es startet Conversations, verbindet Agent-Backends und plant Automatisierungen. Es löste die ältere Bezeichnung OpenHands Web UI ab, während einige Konfiguration noch die alte RUNTIME-Umgebungsvariable nutzt.

Braucht OpenHands Docker?

Docker ist die empfohlene Sandbox, aber nicht Pflicht: Der Prozessmodus führt den Agent-Server direkt auf dem Host ohne Isolation aus, entfernte Sandboxes nutzen gehostete Deployments. Ein Container pro Conversation verlangt OH_CONVERSATION_RUNTIME=docker.

Welche Modelle kann OpenHands verwenden?

Jedes Modell, das über LiteLLM erreichbar ist, einschließlich lokaler Server wie Ollama und vLLM, dazu der gehostete OpenHands-Anbieter. LLM-Profile erlauben es einer Conversation, mitten in der Aufgabe das Modell zu wechseln.

OpenHands im Test: Agent zum Selberhosten

OpenHands ist eine MIT-lizenzierte Plattform für Coding-Agenten: ein Web-Frontend namens Agent Canvas, eine CLI, ein Headless-Modus, ein Python-SDK und eine REST-API, die Agenten steuern, welche Dateien bearbeiten und Befehle in einer Sandbox ausführen. Die Position dieses Reviews: Es ist die vollständigste Open-Source-Option für Teams, die die Ausführungsumgebung selbst besitzen wollen, und es verhält sich wie eine Plattform im laufenden Bau statt wie ein fertiges Produkt.

Es steht dort, wo Claude Code, Codex CLI, Aider und die gehosteten Agenten stehen, zwischen Modell und Repository — aber mit einem anderen Vertrag: Das Modell ist eine austauschbare Abhängigkeit statt ein fest verbautes, und die Laufzeit ist Ihre Infrastruktur statt die eines Anbieters. Die Version 1.25.0 erschien am 6. Oktober 2026.

Was es ist

OpenHands begann als ein einzelnes Repository und besteht jetzt aus vier: das Agent-Canvas-Frontend und die lokale Orchestrierung in OpenHands/OpenHands, der Python-Agent-Server und das SDK in software-agent-sdk, ein TypeScript-Client und ein eigener Automatisierungsdienst. Dieser Split ist das Erste, was man verstehen sollte, bevor man es übernimmt.

MIT-Lizenz, der gehostete Dienst wird separat von All Hands AI vermarktet.
Version 1.25.0, veröffentlicht am 6. Oktober 2026, die Agent-Server und SDK auf 1.53.0 festschreibt.
Oberflächen: die Agent-Canvas-Web-UI, eine interaktive CLI, ein Headless-Modus für CI, ein Python-SDK und eine REST-API für Conversations, Events und Sandboxes.
Modellagnostisch über LiteLLM, mit Profilen zum Modellwechsel innerhalb einer Conversation und Unterstützung lokaler Server wie Ollama und vLLM.
Sandbox-Anbieter: Docker als empfohlene Option, ein Prozessmodus ohne Container-Isolation und entfernte Sandboxes für gehostete Setups.
Unterstützung des Agent Client Protocol, sodass Canvas Claude Code, Codex oder Gemini CLI als alternative Backends steuern kann.
Automatisierungen laufen nach Zeitplan, auf GitHub-Events oder Webhooks, mit fertigen Vorlagen für Issue-zu-Pull-Request und Pull-Request-Review.

Darunter legt der Agent-Server einen Workspace, einen Werkzeugsatz für bash, Dateibearbeitung, Browser und interaktives Terminal sowie Skills, Hooks und MCP-Server offen. Canvas und Automatisierungsdienst sind Clients dieser API, deshalb kann dieselbe Conversation per Button, Cron-Job oder Webhook starten.

Wie es funktioniert

Eine Conversation ist ein Strom typisierter Events: Der Agent schlägt eine Aktion vor, die Aktion läuft in der Sandbox, die Observation kommt zurück, und die Schleife läuft weiter, bis das Modell aufhört. Die interessanten Entscheidungen liegen an der Grenze — welche Dateien der Workspace freigibt, welche Befehle die Politik erlaubt und welches Modellprofil die nächste Runde bezahlt.

Die Schleife steckt im Agent Server, deshalb erreichen ein Button, ein Cron-Job und ein Webhook denselben Ausführungspfad.

Weil die Schleife im Agent Server und nicht in der UI lebt, kann dieselbe Conversation aus Canvas, CLI, Zeitplan oder Webhook starten und pausiert, fortgesetzt, verzweigt oder als Trajektorie exportiert werden. Das ist das architektonische Argument des Projekts: ein Ausführungspfad mit mehreren Einstiegen.

Erste Schritte

Der dokumentierte Weg ist Docker: ein Container veröffentlicht den Canvas auf localhost, mountet ein Projektverzeichnis, auf das der Agent zugreifen darf, und hält seinen Zustand in einem Home-Verzeichnis-Volume.

# one container for the canvas, the agent server and a mounted workspace
export PROJECTS_PATH="$HOME/projects"
mkdir -p "$PROJECTS_PATH" "$HOME/.openhands"

docker run -it --rm \
  -p 127.0.0.1:8000:8000 \
  -e AGENT_CANVAS_ALLOW_LAN_SESSION_KEY=true \
  -v "$HOME/.openhands:/home/openhands/.openhands" \
  -v "${PROJECTS_PATH}:/projects" \
  ghcr.io/openhands/agent-canvas:1.25.0

# open http://localhost:8000, add a model key, start a conversation

Der npm-Weg, npm install -g @openhands/agent-canvas, braucht Node.js 24 und uv und führt den Agent-Server direkt auf dem Host aus; die README warnt, dass der Agent damit vollen Dateisystemzugriff hat. Der Container-Weg ist der, den man in ein Team-Setup überträgt.

Sandbox und Radius eines Fehlers

Die Sandbox ist die Sicherheitsgrenze, und die Dokumentation ist unverblümt: Docker wird empfohlen, der Prozessmodus ist als unsicher, aber schnell gekennzeichnet, entfernte Sandboxes bedienen gehostete Deployments. In der Sandbox laufen Befehle und werden Dateien bearbeitet, deshalb entscheidet ihre Konfiguration darüber, was ein Prompt einer Maschine antun kann.

Die Docker-Sandbox führt den Agent-Server in einem Container aus und ist der empfohlene Anbieter auf einem Arbeitsplatzrechner.
Die Prozess-Sandbox führt ihn als normalen Prozess ohne Container-Isolation aus: schneller, und nur für vertrauenswürdige Arbeit.
OH_CONVERSATION_RUNTIME=docker gibt jeder Conversation einen eigenen Container mit eigenem Workspace und eigenem Zustand.
Hooks können gefährliche Befehle blockieren und Prüfungen erzwingen, bevor der Agent stoppt, und eine Bestätigungsrichtlinie kann Aktionen freigeben lassen.
Workspaces sind auf einen gemounteten Projekt Pfad begrenzt, deshalb sieht der Standard-Container den Rest des Host-Dateisystems nicht.

Automatisierungen

Automatisierungen sind der Grund, sich dafür statt für einen Terminal-Agenten zu entscheiden. Ein Task läuft nach Zeitplan oder auf ein Event — ein GitHub-Issue, ein Pull Request, ein Webhook —, schickt eine Conversation an einen Agent Server, und das Ergebnis kommt als Kommentar, Pull Request oder Slack-Nachricht zurück.

Fertige Vorlagen decken Issue-zu-Pull-Request, Pull-Request-Review, Repository-Überwachung und einen Slack-Kanal-Monitor ab.
Zeitpläne und Event-Trigger teilen sich ein Dashboard, mit Laufhistorie und Aktivieren oder Deaktivieren pro Automatisierung.
Automatisierungen lassen sich exportieren, importieren und mit einem Git-Repository synchronisieren, sodass sie als Dateien bearbeitet und wie Code geteilt werden.
Integrationen umfassen Slack, GitHub, Linear, Notion und Webhooks; der Automatisierungsdienst läuft als eigenes Repository und eigener Prozess.
Mit einem Container pro Conversation konkurrieren parallele Automatisierungen nicht um denselben Workspace.

Hier wird auch der Betriebsaufwand sichtbar: ein dauerhaft laufender Canvas, ein Automatisierungsdienst und Container pro Conversation sind drei zusätzliche Dinge im Vergleich zu einem Terminal-Agenten. Die eigenen Use-Case-Seiten des Projekts beschreiben eine Vier-Automatisierungen-Pipeline vom Issue bis zum Merge — ein legitimes Ziel und eine ehrliche Menge an Mechanik.

Wo es hakelt

Die Schwächen zuerst: OpenHands bewegt sich schnell, und die Oberfläche zeigt das. Die Begriffe wechselten in V1 von Runtimes zu Sandboxes, während die Konfiguration noch RUNTIME liest, das Frontend heißt jetzt Agent Canvas statt älteres Web-UI, und der Code verteilt sich auf vier Repositories mit separat versionierten Teilen. Wer nichts fest pinnt, findet Upgrade-Hinweise in seinen Tickets.

API-Stabilität: SDK und Agent Server versionieren sich unabhängig vom Canvas, und die 1.25.0-Notes schreiben sie auf 1.53.0 fest.
Das Ergebnis folgt dem Modell: Der eigene OpenHands Index findet kleine Abstände zwischen Modellen bei der Issue-Lösung und deutlich größere über seinen Fünf-Aufgaben-Mix hinweg.
Selbst gehostete Automatisierungen brauchen eine Maschine, die immer an ist, plus Zugriffsverwaltung für GitHub, Slack und den Modellanbieter.
GUI, CLI und Canvas überlappen, sodass ein Team einen Einstieg wählen muss statt ihn zu erben.

Das meiste lässt sich mit Disziplin verwalten statt vermeiden: die drei Versionsnummern gemeinsam pinnen, pro Team einen Einstieg behalten und eine Release Note lesen, bevor sie als Störung gelesen wird.

System	Wo es läuft	Modellwahl	Schwerster Teil
OpenHands	Ihr Docker, eine entfernte Sandbox oder ein lokaler Prozess	jeder Anbieter über LiteLLM, lokale Server eingerechnet	dauerhaft laufender Canvas, Agent Server und Container
Claude Code	Ihr Terminal, mit Hooks und CI-Skripten	Anthropic-Modelle	fast keiner
Aider	Ihr Terminal, mit bewussten Git-Eingriffen	viele Anbieter, lokale Server eingerechnet	fast keiner
Cline	eine VS-Code-Erweiterung	viele Anbieter, lokale Server eingerechnet	eine offene Editor-Sitzung

Der Vergleich geht in Wahrheit um Infrastruktur. OpenHands kauft sandboxierte, planbare, modellagnostische Ausführung und bezahlt sie mit Dauerbetrieb; die Terminal-Agenten kaufen Einfachheit und verzichten auf die Steuerungsebene.

Fazit

OpenHands lohnt sich, wenn die Arbeit unbeaufsichtigt stattfinden soll: Issues, die zu Pull Requests werden, Reviews, die bei jedem Merge laufen, Monitorings, die ein Repository beobachten. Für interaktive Arbeit in einem Repository ist ein Terminal-Agent mit einer Sandbox, der man ohnehin vertraut, mit weniger Mechanik beim gleichen Ergebnis.

Nutzen Sie es, wenn das Modell eine austauschbare Abhängigkeit bleiben muss: Profile, LiteLLM-Anbieter und lokale Server sind First Class, kein Anbieter ist tragend.
Nutzen Sie es selbst gehostet, wenn das Besitzen der Ausführungsumgebung der Punkt ist; die MIT-Lizenz und der Docker-Weg machen das zu einem gestützten Weg statt zu einem Workaround.
Beginnen Sie mit der Container-Installation, mounten Sie Projekte aus einem Verzeichnis und behandeln Sie den Prozessmodus als Debugging-Komfort.
Übernehmen Sie es nicht für eine stabile API: Pinnen Sie Canvas, Agent Server und SDK gemeinsam und lesen Sie jede Release Note vor dem Upgrade.
Aktivieren Sie keine Automatisierungen, die Sie nicht prüfen können: Jeder Zeitplan ist ein Agent mit Zugangsdaten, deshalb gehören Bestätigungsrichtlinien und Hooks standardmäßig an.

OpenHands ist kein Werkzeug, das man auf ein Projekt loslässt. Es ist eine kleine Plattform, die Ihre Agenten betreibt, und die Plattform ist der Teil, den Sie besetzen müssen.

OpenHands: der Open-Source-Coding-Agent im Eigenbetrieb

Das Wichtigste in Kürze