open-computer-use: ein Linux-Desktop in der E2B-Cloud, gesteuert von offenen Modellen
AI computer use powered by open source LLMs and E2B Desktop Sandbox
Auf einen Blick
- Was ist das?
- Das Projekt verbindet einen E2B Desktop Sandbox mit austauschbaren LLM-Providern für Grounding, Vision und Aktionen. Die Aufteilung ist der interessante Teil, die Konfiguration der wunde Punkt.
- Für wen ist es gedacht?
- Sinnvoll ist open-computer-use für Teams, die Computer-Use-Agenten evaluieren wollen, ohne die Ausführungsumgebung selbst zu betreiben, und die bereit sind, drei Modellrollen getrennt zu besetzen. Wer eine produktionsreife Steuerungsschicht mit stabiler API sucht oder keinen E2B-Account betreiben will, ist hier falsch.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 68 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Drei Modellrollen statt eines Alleskönners
Die meisten Computer-Use-Demos schicken einen Screenshot an ein multimodales Modell und lassen es Koordinaten ausgeben. open-computer-use trennt stattdessen drei Aufgaben. In os_computer_use/config.py stehen drei Zuweisungen: grounding_model, vision_model und action_model. Das Grounding-Modell übersetzt eine sprachliche Beschreibung in eine Position auf dem Bildschirm. Das Vision-Modell liest den Bildschirminhalt. Das Aktionsmodell entscheidet, was als Nächstes passiert. Genau diese Trennung ist der Kern des Projekts, denn sie erlaubt Kombinationen, die ein einzelnes Modell nicht leisten kann: ein spezialisiertes Grounding-Modell für Klicks, ein schnelles Modell für die Bildinterpretation, ein stärkeres für die Planung. Das README nennt als Beispiel OSAtlasProvider für Grounding, einen GroqProvider mit llama3.2 für Vision und einen GroqProvider mit llama3.3 für Aktionen. Wer diese Aufteilung nicht braucht, zahlt trotzdem ihren Preis: drei Modellaufrufe pro Schritt statt einem.
Was der Agent tatsächlich berührt: Tastatur, Maus, Shell
Laut README operiert der Agent über Tastatur, Maus und Shell-Befehle. Das ist eine wichtigere Aussage, als sie zunächst wirkt. Ein Agent, der eine Shell im Sandbox erreicht, kann Aufgaben lösen, für die eine reine GUI-Steuerung zu langsam oder zu fragil wäre, etwa das Installieren eines Pakets oder das Auslesen einer Datei. Die Kosten liegen auf der Hand: Die Angriffsfläche wächst mit jedem zusätzlichen Kanal. Die Ausführung findet in einem E2B Desktop Sandbox statt, also in einer Cloud-VM, nicht auf dem Rechner des Nutzers. Das README beschreibt den Sandbox als sicher und als Linux-Computer; die eigentliche Isolation leistet E2B, nicht das Repository. Wer wissen will, wie diese Isolation implementiert ist, muss in der E2B-Dokumentation nachsehen. Das Repository selbst beantwortet die Frage nicht.
Der Datenfluss: Stream zum Client, Pause per Eingabe
Der Display-Stream des Sandbox wird laut README live auf den Client-Rechner übertragen. Der Agent öffnet also ein Fenster, in dem der entfernte Desktop sichtbar ist. Zusätzlich kann der Nutzer den Agenten jederzeit anhalten und ihm eine neue Anweisung geben. Das ist mehr als eine Annehmlichkeit. Ein Agent, der Maus und Tastatur in einer laufenden Sitzung steuert, kann in Zustände geraten, aus denen ihn ein Neustart befreien muss. Eine Pause, die den laufenden Schritt nicht abbricht, sondern die nächste Entscheidung abwartet, ist der billigere Ausweg. Das README beschreibt die Pause-Funktion, ohne das genaue Verhalten im Detail festzulegen. Wer sie einsetzen will, sollte im Code nachsehen, an welcher Stelle die Eingabe ausgewertet wird.
Einrichtung: poetry, ffmpeg und ein Stapel API-Schlüssel
Die Installation folgt einem kurzen Pfad. Zuerst brew install poetry ffmpeg, dann git clone https://github.com/e2b-dev/open-computer-use/, dann cd open-computer-use. In einer .env-Datei im Projektverzeichnis steht E2B_API_KEY. Dazu kommen die Schlüssel der Provider, die in config.py ausgewählt sind. Das README listet FIREWORKS_API_KEY, OPENROUTER_API_KEY, LLAMA_API_KEY, GROQ_API_KEY, GEMINI_API_KEY, OPENAI_API_KEY, ANTHROPIC_API_KEY und MOONSHOT_API_KEY. Ein Schlüssel ist nicht optional: HF_TOKEN, laut README nötig, um Gradio-Rate-Limits für die Hugging-Face-Spaces zu umgehen, über die OS-Atlas und ShowUI laufen. Gestartet wird mit poetry install und anschließend poetry run start. Ein erster Auftrag lässt sich direkt mitgeben: poetry run start --prompt "use the web browser to get the current weather in sf". Der Display-Stream erscheint laut README wenige Sekunden nach dem Start des Python-Programms.
Die Modellmatrix ist breit, aber nicht symmetrisch
Das README zählt mehr als zehn Modelle auf, und die Rollen sind unterschiedlich besetzt. Llama 3.2 kann bei Groq sowohl Vision als auch Aktion, bei Fireworks, OpenRouter und der Llama API nur Vision. Llama 3.3 kann überall nur Aktion. DeepSeek kann ausschließlich Aktion. Gemini 2.0 Flash, GPT-4o, GPT-4o mini und Claude decken Vision und Aktion ab. Pixtral übernimmt bei Mistral die Vision, Mistral Large die Aktionen. Die Grounding-Rolle ist am dünnsten besetzt: OS-Atlas und ShowUI, beide über Hugging Face Spaces. Wer ein anderes Grounding-Modell will, muss einen Provider in providers.py ergänzen und das README bittet ausdrücklich um einen Pull Request. Das ist eine bewusste Erweiterungsstrategie, aber sie bedeutet auch: Die Qualität des Groundings hängt an zwei Modellen, die über einen fremden Dienst mit Rate-Limits laufen.
Kein Release, keine Versionsnummer, kein Upgrade-Pfad
Für das Repository sind keine Releases abrufbar. Es gibt also keine getaggte Version, an der man sich festhalten könnte, und keinen Changelog, aus dem hervorgeht, was sich zwischen zwei Ständen geändert hat. In der Praxis installiert man den jeweils aktuellen Stand des master-Branches. Das ist für ein Experimentierprojekt vertretbar und für einen festen Build unangenehm, weil ein poetry install zu einem späteren Zeitpunkt einen anderen Code liefert. Der letzte Push liegt laut Repository-Metadaten im Juli 2026, das Projekt ist nicht archiviert. Ob und in welchem Rhythmus es gepflegt wird, lässt sich daraus nicht ableiten. Wer es produktiv einsetzen will, sollte einen Commit-Hash festnageln und die Abhängigkeiten selbst sperren.
Lizenz und die Frage, was E2B kostet
Der Code steht unter Apache-2.0. Das erlaubt kommerzielle Nutzung, Modifikation und Weitergabe, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen kenntlich gemacht werden. Für die Modelle, die der Agent aufruft, gilt das nicht: Llama, Gemini, Claude, GPT-4o, Mistral und DeepSeek haben eigene Bedingungen, die jeweils beim Anbieter zu prüfen sind. Das Repository enthält dazu keine Aussage. Dasselbe gilt für die Laufzeitkosten. Der Sandbox läuft in der E2B-Cloud und benötigt einen E2B-API-Schlüssel; das README verlinkt das E2B-Dashboard, nennt aber kein Preismodell. Wer die Kosten abschätzen will, muss sie aus den E2B-Preisen und dem Tokenverbrauch der drei Modellrollen selbst berechnen. Das ist kein Nebenaspekt, sondern der dominierende Posten bei längerer Nutzung.
Alternative: ein Modell, ein Aufruf, weniger bewegliche Teile
Der naheliegende Vergleich ist ein Agent, der ein einziges multimodales Modell für alles verwendet und die Koordinaten direkt ausgeben lässt. Der Unterschied liegt nicht in der Modellqualität, sondern in der Anzahl der Fehlerquellen. Ein einzelner Aufruf hat eine Fehlerquelle, drei Aufrufe haben drei, und ein Fehler im Grounding pflanzt sich in die Aktion fort, ohne dass das Aktionsmodell davon weiß. Umgekehrt erlaubt die Aufteilung, ein günstiges Modell für die Bildinterpretation und ein teures nur für die Planung zu verwenden. Wer einen einzelnen Anbieter mit starker multimodaler Ausgabe bereits einsetzt, gewinnt durch die Aufteilung nichts und verliert Latenz. Wer dagegen ein Grounding-Modell gezielt verbessern will, findet hier den einzigen Ort im Ablauf, an dem das ohne Modellwechsel möglich ist.
Redaktionelles Fazit
Sinnvoll ist open-computer-use für Teams, die Computer-Use-Agenten evaluieren wollen, ohne die Ausführungsumgebung selbst zu betreiben, und die bereit sind, drei Modellrollen getrennt zu besetzen. Wer eine produktionsreife Steuerungsschicht mit stabiler API sucht oder keinen E2B-Account betreiben will, ist hier falsch. Vor dem ersten Lauf sollte man in os_computer_use/config.py prüfen, ob grounding_model, vision_model und action_model auf Provider zeigen, für die in .env tatsächlich Schlüssel liegen, und ob HF_TOKEN gesetzt ist, weil die Grounding-Modelle laut README über Hugging Face Spaces laufen.
Community-Notizen