Quartalsende, und du öffnest dasselbe interne Admin-Panel, das du seit fünf Jahren öffnest. Es gibt keine API-Dokumentation, der Login läuft über ein Captcha, und der Bericht, den du brauchst, liegt drei Bildschirme tief hinter einem Dropdown. Du willst, dass der Agent das für dich erledigt, und er hängt schon bei Schritt eins – es gibt nichts, was sich per POST verschicken ließe. Ein Bildschirm ist die einzige Schnittstelle, die dieses System je hatte, und er war immer der blinde Fleck des Agenten.

Sai von Simular schließt genau diese Lücke. Es ist ein Computer-Use-Agent, der auf einem Cloud-Computer läuft: Du gibst ihm eine Aufgabe in Worten, es öffnet Seiten, klickt Buttons und füllt Formulare aus wie ein Mensch, und meldet das Ergebnis anschließend als Text zurück. Auf der Hermes-Seite besteht die Arbeit nur darin, diese Fähigkeit anzubinden – und diese Anbindung liegt jetzt im offiziellen Plugin-Katalog.

Die Welt ohne API ist größer, als du denkst

Wir lesen Automatisierung standardmäßig als „ruf den Endpoint auf“. Die reale Arbeit sagt etwas anderes: alte interne Backends, Konsolen, die nur Admins sehen, SaaS-Seiten, an die du ohne Session nicht herankommst, Antragsformulare, die es nur als HTML gibt. Gemeinsam ist ihnen, dass ein Mensch sie bedienen kann und eine Maschine sie nicht aufrufen kann.

Die alte Antwort waren Selenium-Skripte, ein Satz Selektoren pro Seite, und beim nächsten Redesign war alles kaputt. Sai geht einen anderen Weg: Es pflegt keine Selektoren, sondern schaut auf den Bildschirm und entscheidet den nächsten Schritt mit einem Modell. Der Preis ist Geschwindigkeit – jeder Klick kostet eine Modellentscheidung – und der Gewinn ist, dass die Automatisierung nicht zerbricht, wenn die Seite einen Button verschiebt.

Das definiert auch die Rolle von Hermes an dieser Stelle. Scheduling, Kontext, Memory und Freigaben bleiben lokal. Der Teil, der tatsächlich klickt, gehört zu einem Computer irgendwo anders. Aufgabentext, die Dateien, die du hochladen lässt, und dein API-Key gehen an api.simular.ai, und dort läuft der Cloud-Computer.

Drei Dinge, die du vor der Installation prüfen solltest

Erstens Node.js. Das Plugin bringt keinen eigenen Code mit – es ist ein Agent-Plugins-v1-Paket (plugin.json, mcp.json, skills/) – die eigentliche Fähigkeit ist das npm-Paket @simular-ai/sai-mcp, gepinnt auf 0.4.0 und per npx gestartet. Du brauchst also Node.js 22.12 oder neuer plus npm auf der Maschine.

Zweitens ein Sai-API-Key. Erstelle einen unter API Keys auf platform.simular.ai; Keys sehen aus wie sapi_.... Der kostenlose Tarif enthält einen Cloud-Computer und ein Tageskontingent, das reicht, um den Ablauf einmal durchzuspielen.

Drittens die Datengrenze. Das solltest du vor der Installation entscheiden, nicht danach: Aufgabeninhalt, jede Datei, die der Agent hochlädt, und der API-Key verlassen deine Maschine in Richtung Simular-API, und Aufgaben verbrauchen Guthaben deines Sai-Kontos. Das ist kein lokales Werkzeug, sondern ein ausdrücklicher Service-Aufruf.

Zwei Befehle zur Installation

Der Eintrag im offiziellen Katalog heißt simular-sai:

hermes plugins install simular-sai --no-enable
hermes plugins enable simular-sai

Der erste Befehl zieht den gepinnten Commit (365b247, Plugin-Version 0.1.2) und installiert deaktiviert, damit du den Key setzen kannst, bevor irgendetwas läuft. Der zweite schaltet es ein.

Den Key trägst du in Desktop unter Settings > Plugins ein oder in die .env des aktiven Profils:

SAI_API_KEY=sapi_your_key_here

Starte danach das Gateway neu, damit der neue Prozess die Umgebung sieht. Um zu prüfen, was du tatsächlich installiert hast:

hermes plugins info simular-sai

Die Ausgabe listet Version, gepinnten Commit, die benötigte Hermes-Version (>=0.21.6) und die vollständige Datenoffenlegung. Wie der Katalog selbst funktioniert, steht im Plugin-Katalog-Leitfaden.

Wie eine Aufgabe von Anfang bis Ende aussieht

Nach dem Aktivieren hat Hermes einen neuen MCP-Server (sai) und einen Skill (simular-sai:sai). Der Skill entscheidet, wann eine Aufgabe abgegeben werden sollte; der Server erledigt die Arbeit: Aufgabe starten, auf sie warten, Berechtigungsanfragen beantworten, sie stoppen, eine Datei hochladen, Computer und Modelle auflisten und den Bildschirm an einen Menschen übergeben.

Ein Satz genügt, um das auszulösen:

Use Sai to open Notepad on my cloud computer, type Hello from Sai, and tell me the window title.

Dahinter passiert Folgendes:

1. Start. Hermes übergibt Ziel und Kontext an Sai, das daraufhin auf dem Cloud-Computer zu arbeiten beginnt.
2. Warten. Aufgaben sind nicht sofort fertig – du pollst. Erwarte keine API-Latenz.
3. Berechtigungen beantworten. Wenn Sai einen Befehl ausführen oder eine Datei auf seinem eigenen Computer schreiben will, fragt es vorher, und Hermes antwortet in deinem Namen. Eine Aufgabe hat also zwei Freigabeschichten: die Werkzeug-Freigaben von Hermes plus die internen von Sai.
4. Text einsammeln. Das Ergebnis kommt als Text zurück, nicht als Screenshot-Serie.
5. Optional Übergabe. Wenn ein Schritt wirklich einen Menschen braucht, liefert sai_live_link einen Link, mit dem jeder, der ihn hat, diesen Cloud-Computer steuern kann, bis er abläuft.

Während eines Laufs gibt es noch eine hübsche Kleinigkeit: Eine Live-Ansicht wird auf 127.0.0.1 ausgeliefert (als watch_url exponiert), sodass du dem Cloud-Computer bei der Arbeit zusehen kannst. Dein API-Key erreicht diesen Browser nie.

Grenzen, die später wehtun

Benutze es nicht als Browser. Wenn du eine öffentliche Seite scrapst oder ein Formular ausfüllst, dessen Endpoint du aufrufen kannst, sind die Browser-CDP-Werkzeuge dramatisch schneller und günstiger. Sai verdient seinen Platz nur dort, wo sich „keine API“ und „braucht Bedienung wie durch einen Menschen“ überschneiden.

Uploads sind begrenzt. sai_upload schickt eine lokale Datei an den Cloud-Computer, bis 25 MB pro Datei. Das ist kein Datentransporter.

Ein Live-Link ist ein echter Schlüssel. Wer die URL aus sai_live_link hat, kann deinen Cloud-Computer bis expires_at bedienen. Der Skill weist den Agenten an, sie nur dir zu geben, aber diese Regel wird von einem Modell durchgesetzt, nicht von einem Schloss – in einen Gruppenchat kopiert, kommt sie nicht zurück.

Kein trust: untrusted-Gate, und das mit Absicht. Sais Werkzeuge tragen keinen readOnlyHint, ein Trust-Gate würde also bei jedem sai_task_wait-Poll nachfragen und die Aufgabe würde nie fertig. Der Ersatz ist Sais eigener needs_approval-Schritt, der vor Befehlen und Dateischreibvorgängen weiterhin fragt.

Es ist nicht billig und sollte nicht dauerlaufen. Jeder Klick ist eine Modell-Inferenz. Es passt zu „dreimal am Tag, zehn Minuten lang“; es passt nicht zu „jede Minute“. Für token-sparsame Routinearbeit bleib bei den eigenen Werkzeugen von Hermes.

Wann es sich lohnt

Meine Regel: Wenn ein Workflow etwas ist, das du jeden Monat von Hand machst, einen Login braucht, dich durch einen Stapel Seiten klickt und keine API hat – gib ihn einmal an Sai und schau, was passiert. Alles, was ein curl-Aufruf oder ein eingebautes Werkzeug erledigen kann, sollte diesen Umweg nicht nehmen.

Die Installation sind zwei Befehle; die eigentliche Entscheidung ist, welche Aufgaben du bereit bist abzugeben und ob eine davon Material enthält, das nicht auf dem Server von jemand anderem liegen sollte. Klärst du diese zwei Fragen, dauert die Konfiguration zehn Minuten. Wenn dich Berechtigungsgrenzen umtreiben, ist der Leitfaden zu Plugin-Isolation und Host-Grenzen die passende Ergänzung.