Open-Interface: LLM steuert Maus und Tastatur über Screenshots
Control Any Computer Using LLMs.
Auf einen Blick
- Was ist das?
- Open-Interface schickt Nutzeranfragen an ein Vision-Modell und führt die zurückgegebenen Schritte per simuliertem Maus- und Tastatureingaben aus. Das Projekt ist ein Autopilot für den gesamten Desktop, kein API-Wrapper für einzelne Anwendungen.
- Für wen ist es gedacht?
- Open-Interface ist für Anwender interessant, die repetitive Abläufe über mehrere Programme hinweg automatisieren wollen, ohne für jede Anwendung eine eigene API anzubinden. Für Produktionsumgebungen mit Audit-Anforderungen oder für Aufgaben, die exakte Koordinaten und deterministische Wiederholbarkeit verlangen, ist das Projekt die falsche Wahl, weil jeder Schritt auf einem Screenshot und einer Modellentscheidung beruht.
- Darf ich es kommerziell nutzen?
- Ja, unter Bedingungen. GPL-3.0 ist eine Copyleft-Lizenz: Wenn Sie Software weitergeben, die sie enthält, müssen Sie deren Quellcode unter derselben Lizenz veröffentlichen. Wer sie nur intern betreibt, ohne sie weiterzugeben, löst diese Pflicht nicht aus.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 61 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
Welches Problem Open-Interface löst und für wen es gedacht ist
Die meisten Automatisierungswerkzeuge setzen an einer Schnittstelle an. Sie sprechen eine API an, füllen ein Formularfeld über einen Selektor oder rufen eine Funktion in einem Skript auf. Open-Interface geht einen anderen Weg: Es behandelt den sichtbaren Desktop als die Schnittstelle. Das Projekt beschreibt sich selbst als Software, die den Computer selbst steuert, indem sie Anfragen an ein LLM-Backend wie GPT-4o oder Gemini schickt, um die nötigen Schritte zu ermitteln, und diese Schritte dann durch simulierte Tastatur- und Mauseingaben ausführt.
Das ist dann sinnvoll, wenn es keine API gibt. Ein Programm, das nur als grafische Oberfläche existiert, ein Webformular ohne dokumentierten Endpunkt, eine Desktop-Anwendung mit proprietärem Protokoll: Für all das existiert keine stabile Schnittstelle, aber sehr wohl ein Fenster mit Knöpfen. Die Zielgruppe sind entsprechend weniger klassische Backend-Entwickler als Anwender, die Abläufe über mehrere Programme hinweg automatisieren wollen, ohne für jedes davon eine Integration zu schreiben. Der Preis dafür ist, dass die Steuerung auf Pixeln und Modellausgaben beruht, nicht auf Verträgen.
Der Kreislauf aus Screenshot, Modellentscheidung und Eingabe
Der Mechanismus lässt sich in drei Schritten beschreiben, und alle drei stehen im README. Erstens: Die Anfrage geht an ein LLM-Backend, das daraus die erforderlichen Schritte ableitet. Zweitens: Das Programm führt diese Schritte aus, indem es Tastatur- und Mauseingaben simuliert. Drittens: Es korrigiert den Kurs, indem es dem Backend aktualisierte Screenshots des Fortschritts schickt.
Der dritte Punkt ist der eigentlich interessante. Das Modell plant nicht einmalig eine Sequenz und arbeitet sie dann ab, sondern bekommt nach Bedarf ein neues Bild des aktuellen Zustands. Damit kann es auf Zwischenergebnisse reagieren, etwa auf ein geöffnetes Dialogfenster oder eine geänderte Seite. Gleichzeitig bedeutet das, dass jeder Korrekturschritt einen Screenshot des Bildschirms an einen externen Dienst überträgt. Wer auf einem Rechner mit Kundendaten, Zugangsdaten oder vertraulichen Dokumenten arbeitet, sollte sich diese Datenbewegung bewusst machen, bevor der Autopilot startet. Das README benennt sie als Mechanismus, nicht als Risiko.
Für die Eingabesimulation nennt das Repository unter den Themen pyautogui. Die Steuerung läuft also über die übliche Bibliothek für synthetische Maus- und Tastatureingaben, nicht über Barrierefreiheits-Schnittstellen der Betriebssysteme. Das erklärt, warum das Programm auf allen drei Plattformen dieselbe grundlegende Mechanik verwenden kann, und es erklärt auch, warum es auf macOS explizit die Freigabe für Bedienungshilfen und Bildschirmaufnahme anfordert.
Installation: fertige Binaries für drei Plattformen
Der einfachste Weg führt über die Release-Seite. Für macOS lädt man das Binary der neuesten Version herunter, entpackt es und verschiebt Open Interface in den Programme-Ordner. Auf Intel-Macs kann dabei der bekannte Hinweis erscheinen, dass die App nicht geöffnet werden kann. Das README beschreibt den Ablauf: Abbrechen drücken, dann unter Systemeinstellungen, Sicherheit und Datenschutz die Option Trotzdem öffnen wählen.
Unter Linux wurde das Binary laut README bisher auf Ubuntu 20.04 getestet. Man lädt die Zip-Datei der neuesten Version, entpackt die ausführbare Datei und geht weiter zum Setup. Für Windows wurde das Binary auf Windows 10 getestet; dort entpackt man den Ordner, verschiebt die exe an den gewünschten Ort und startet sie per Doppelklick.
Wer lieber aus dem Quelltext arbeitet, installiert Python 3.12 oder neuer und klont das Repository mit git clone https://github.com/AmberSahdev/Open-Interface. Die genauen weiteren Schritte für den Skriptbetrieb sind im ausgelieferten Material abgeschnitten, das lässt sich aus dem vorliegenden README nicht vollständig rekonstruieren. Klar ist nur die Versionsanforderung: Python 3.12 oder neuer.
Setup und Berechtigungen: der Teil, der vor dem ersten Lauf zu erledigen ist
Nach der Installation verweist das README auf den Abschnitt Setup, um Open Interface mit LLMs zu verbinden, genannt wird dabei ausdrücklich OpenAI GPT-4V. Ein API-Schlüssel für einen externen Dienst ist also Voraussetzung, das Programm bringt kein eigenes Modell mit und rechnet lokal nichts. Wer den Dienst nicht bezahlen oder keine Daten an ihn senden will, kann das Projekt in dieser Form nicht nutzen.
Auf macOS kommen zwei Systemberechtigungen hinzu. Open Interface fragt nach Zugriff auf Bedienungshilfen, um Tastatur und Maus zu bedienen, und nach Bildschirmaufnahme, um Screenshots zur Fortschrittskontrolle zu erstellen. Falls die Abfrage ausbleibt, müssen beide Rechte manuell über Systemeinstellungen, Datenschutz und Sicherheit gesetzt werden. Das README zeigt für Apple-Silicon-Macs und Intel-Macs jeweils eigene Screenshots dieser Dialoge, was darauf hindeutet, dass die Abfrage nicht in jeder Konstellation zuverlässig erscheint. Das ist ein praktischer Stolperstein: Ohne diese beiden Rechte kann das Programm weder sehen noch eingreifen, und es wird keinen hilfreichen Fehler produzieren, sondern schlicht nicht funktionieren.
Wo die Screenshot-Schleife an ihre Grenzen kommt
Der Ansatz hat eine strukturelle Schwäche, die sich nicht wegkonfigurieren lässt. Jede Entscheidung des Modells beruht auf einem Bild des Bildschirms. Was auf dem Bild nicht zu sehen ist, existiert für die Planung nicht. Ein Hintergrundprozess, ein verzögert ladendes Element, ein Fenster auf einem zweiten Monitor oder eine Anwendung, die gerade keinen sichtbaren Fokus hat, fallen aus der Wahrnehmung heraus. Das README demonstriert das Konzept unter anderem mit dem Lösen des Wordle-Rätsels und dem Schreiben eines Web-App-Codes, also mit Aufgaben in einem einzelnen, klar sichtbaren Fenster.
Dazu kommt die Fehlerfortpflanzung. Ein falsch platzierter Klick auf ein anderes Element als beabsichtigt führt zu einem veränderten Bildschirmzustand, auf den das Modell in der nächsten Runde reagiert. Die Kurskorrektur ist die Stärke des Entwurfs und gleichzeitig sein Risiko: Sie kann einen Fehler ausgleichen, sie kann aber auch in einer Schleife aus Fehlversuchen enden. Für Abläufe, die exakte Koordinaten, feste Zeitfenster oder deterministische Wiederholbarkeit verlangen, ist das die falsche Architektur. Wer eine solche Aufgabe hat, sollte bei einer API-basierten Lösung bleiben, auch wenn das bedeutet, für jede Anwendung eine eigene Integration zu schreiben.
Abgrenzung zu skriptbasierter Automatisierung
Die naheliegende Alternative ist klassische GUI-Automatisierung mit pyautogui direkt, also ohne Modell dazwischen. Der Unterschied liegt nicht im Werkzeug, sondern in der Entscheidungsinstanz. Ein pyautogui-Skript führt feste Koordinaten und feste Tastenfolgen aus. Es ist schnell, kostenlos und reproduzierbar, solange sich die Oberfläche nicht ändert. Sobald ein Dialog auftaucht oder ein Knopf wandert, bricht es ab.
Open-Interface tauscht diese Determinismus gegen Anpassungsfähigkeit. Das Modell entscheidet pro Runde, was als Nächstes zu tun ist, und kann deshalb mit unerwarteten Zwischenzuständen umgehen. Der Preis ist eine Abhängigkeit von einem externen Dienst, eine Latenz pro Runde und eine Fehlerquelle, die sich nicht durch besseres Skripting beseitigen lässt. Für einen Ablauf, der sich nie ändert, ist ein pyautogui-Skript die günstigere und verlässlichere Wahl. Für einen Ablauf, der sich ständig leicht verändert und den niemand als Skript pflegen will, spielt Open-Interface seine Stärke aus.
Wartung, Release-Takt und Lizenz
Das Repository ist nicht archiviert, der letzte Push liegt laut Metadaten im Juli 2026. Die veröffentlichten Versionen zeigen einen unregelmäßigen Takt: 0.7.0 im Dezember 2024, 0.8.0 im Januar 2025, v0.9.0 im März 2025. Aus diesen Angaben lässt sich kein Versprechen für zukünftige Updates ableiten, und das Material enthält keine Aussage dazu, wie lange ältere Binaries mit neuen Modellversionen kompatibel bleiben. Wer auf einem bestimmten Modell aufsetzt, sollte damit rechnen, dass sich Schnittstellen oder Modellnamen ändern und die Anwendung angepasst werden muss.
Die Lizenz ist GPL-3.0. Wer das Projekt unverändert einsetzt, hat damit in der Regel keine weiteren Pflichten. Wer es jedoch modifiziert und weitergibt, muss den Quelltext unter derselben Lizenz offenlegen. Für eine interne Automatisierung ohne Weitergabe ist das meist unkritisch, für den Einbau in ein eigenes Produkt, das ausgeliefert wird, ist es eine relevante Einschränkung. Das ist keine Rechtsberatung, sondern nur der Hinweis, dass die Lizenzwahl vor einer Integration geprüft werden sollte.
Redaktionelles Fazit
Open-Interface ist für Anwender interessant, die repetitive Abläufe über mehrere Programme hinweg automatisieren wollen, ohne für jede Anwendung eine eigene API anzubinden. Für Produktionsumgebungen mit Audit-Anforderungen oder für Aufgaben, die exakte Koordinaten und deterministische Wiederholbarkeit verlangen, ist das Projekt die falsche Wahl, weil jeder Schritt auf einem Screenshot und einer Modellentscheidung beruht. Wer es einsetzt, sollte zuerst die Berechtigungen für Bedienungshilfen und Bildschirmaufnahme prüfen, das Setup mit einem eigenen API-Schlüssel gegen ein Testkonto fahren und einen Lauf mit einer harmlosen Aufgabe wie dem Lösen eines Wordle-Rätsels beobachten, bevor der Autopilot auf ein Produktivsystem mit echten Zugangsdaten losgelassen wird.
Community-Notizen