Kommentar-Pins im Browser: Hermes Desktop 0.21 macht Websites zur Sandkasten-Redaktion

Die meisten Screenshots enden im Ordnern namens "Screenshots". Ich habe lange so gearbeitet: Seite angucken, Screenshot machen, in ChatGPT kleben, "kannst du da was ändern?", und der Agent hat geraten, was ich meine. Der Screenshot zeigt ein Bild, nicht das Dokument. Der Agent hat dann den Selektor des Buttons erraten, die Klasse des Headers geschätzt, und ich habe Korrekturrunden gefeuert wie Freikarten für ein schlechtes Konzert.

Hermes Agent hat in Version 0.21 genau diese Stelle repariert. Nicht mit einem neuen Modell, nicht mit mehr Kontext, sondern mit einer ehrlichen Beobachtung: Wenn ein Agent die Seite nicht kennt, soll er sie fragen können, anstatt aus dem Bild zu raten. Im Desktop-Client gibt es jetzt im Browser einen Kommentar-Modus. Ich klicke auf Annotate, klicke auf ein Element, oder ich ziehe einen Kasten um einen Bereich, und tippe meine Notiz. Jeder gespeicherte Kommentar bleibt als nummerierter Pin auf der Seite liegen.

Der Teil, der das für mich von einem Screenshot-Stift unterscheidet: Ein Pin trägt den CSS-Selektor, das Markup des Elements und die berechneten Styles, die fürs Layout wichtig sind. Der Agent bekommt also nicht das Foto meiner Seite, sondern die Quelle. Er findet mein Element im Code, statt es aus dem Bild zu erraten. Passwörter und Felder, die nach Keys aussehen, werden vor dem Verlassen der Seite unkenntlich gemacht. Das ist die Sorte Detail, die man erst vermisst, wenn man sie einmal hatte.

Ich habe die Version auf dem Pixel-Cyberdeck laufen, einem gebrauchten Google Pixel 6a, auf dem Hermes als Gateway mit Cron und Telegram-Brücke arbeitet. Der Desktop-Client läuft auf dem MacBook daneben, und ich schicke die Arbeit über Telegram zwischen den Geräten hin und her. Der Test stand vom 11. September an: Ich habe mit Kommentar-Pins Feedback an die eigene Agentenfamilie gegeben, ohne eine Zeile Code selbst anzufassen, und die Version 0.21.1 dazu direkt vom offiziellen Release geprüft. Was folgt, sind die Zahlen, die Grenzen und die Momente, in denen der Pin-Workflow zum ersten Mal schneller war als alles, was ich vorher benutzt habe.

In den Release-Notizen zu 0.21.1 (Tag v2026.9.7, veröffentlicht am 7. September) steht der Kern in einem Satz: Speichern sendet nie einen Turn. Die Pins liegen erst mal auf der Seite, gesammelt als nummerierte Liste. Erst wenn ich sage "Add N comments", wird aus den Pins eine Handvoll Arbeitspakete: jeder Pin kommt mit einem beschnittenen Screenshot und einem kurzen Prompt, der den Kommentar benennt. Zwanzig Kritikpunkte werden so zu wenigen Batches statt zu zwanzig einzelnen Aufgaben.

Warum das wichtig ist, sieht man an der Rechnung. Ein Turn ist bei mir eine Anfrage, und Anfragen sind begrenzt: Ich fahre den Cloud-Zugang über Ollama in einem Fünf-Stunden-Fenster mit Wochenlimit. Zwanzig Pins als zwanzig separate Aufgaben hätten zwanzig Mal den gesamten Kontext geschickt. Die Batching-Logik gruppert die Pins nach dem Bereich der Seite, in dem sie sitzen, und weil die Gruppen eigene DOM-Unterbäume sind, landen sie meist in getrennten Dateien. Genau das macht es sicher, sie an parallele Arbeiter zu geben.

Die Zahlen zum Release-Fenster stammen aus den offiziellen Release-Notizen auf GitHub und sind dort von dritter Seite nachgezählt worden: ein lokaler Klon ergab 5.140 Non-Merge-Commits, also genau einen mehr als die Snapshot-Zahl, was zur Release-Commit-Verzögerung passt. Ich zähle sowas nach, weil ich einmal einen Blogbeitrag auf einer falschen Wortzählung gebaut habe und das nicht noch einmal erleben will. Die Lücke von einem Commit ist keine Unstimmigkeit, sie ist der Beweis, dass die Zahl aus einem echten Git-Fenster kommt.

Mein bisheriger Loop für Website-Änderungen sah so aus: Screenshot machen, in die App kleben, Text drumherum schreiben, abonnieren, auf Rückfragen warten, Rückfragen wieder mit Screenshots beantworten. Vier bis sechs Nachrichten für eine Änderung, die im Kopf in zehn Sekunden klar war. Mit den Pins ist es eine Aktion: Ich markiere das Element, tippe die Notiz, und der Agent hat Selektor und Styles schon dabei. Die Rückfrage "meinst du den Innenabstand oder den Außenabstand?" fällt weg, weil die berechneten Styles die Antwort enthalten.

Der zweite Unterschied sitzt im Desktop-Client selbst. Version 0.21 hat außerdem strukturierte Session-Controls bekommen, Sessions lassen sich aus dem New-Session-Dialog per Drag-and-drop anlegen und in Profilgruppen sortieren, und es gibt eine Import-Ansicht für Transkripte fremder Programmier-Agenten. Das passt zu dem, was ich den ganzen Sommer über gebaut habe: eine kleine Werkstatt, in der mehrere Agenten parallel an getrennten Aufgaben sitzen, statt einem Alleskönner zuzuschauen, wie er der Reihe nach stockt. Ich orchestriere, die Pins liefern das Rohmaterial, und die Session-Controls halten die Werkstatt sortiert.

Ich will an dieser Stelle ehrlich bleiben: Mein Test war ein Alltagstest, kein Laborversuch. Ich habe gezählt, wie viele Nachrichten der Loop braucht, ich habe geprüft, ob Pins nach dem Reload liegen bleiben, und ich habe geschaut, ob der Agent die gemeinten Elemente trifft. Beides traf er in meinem Durchlauf zuverlässig, weil die Pins die Struktur mitliefern. Was ich nicht gemacht habe: systematische Benchmarkreihen über hundert Pins oder einen Blindvergleich gegen andere Tools. Dafür reiche ich die Methodik offen ein, damit jeder den Umfang meines Testurteils einordnen kann.

Die Branche diskutiert gerade, welche Benutzeroberfläche für Agenten die richtige ist. Rabbit R1, Humane AI Pin und Omi haben es 2024 mit eigener Hardware versucht, Plaud NotePin hat es wieder probiert, und alle sind an dem Punkt gescheitert, an dem ein zusätzliches Gerät im Alltag nervt statt zu helfen. Die interestingere Frage ist nicht, welche neue Hardware Agenten verdient, sondern welche Werkzeuge Menschen bereits offen haben. Ein Telefon ist so ein Werkzeug, und mein Pixel 6a trägt inzwischen einen kompletten Agentenbetrieb.

Der Kommentar-Modus geht denselben Weg, nur an der anderen Stelle: Er setzt nicht auf ein neues Gerät, sondern auf die Oberfläche, die Webarbeit ohnehin hat, den Browser. Ich muss nicht lernen, mit einem Agenten zu reden, ich muss nur tun, was ich bei jeder Design-Runde sowieso mache: auf die Stelle zeigen, die mich stört, und sagen, was falsch ist. Der Rest ist Mechanik, und die hat der Agent in Selektor und Styles schon liegen.

Es gibt da einen Satz, der mir bei der Vorbereitung hängen geblieben ist, weil er genau das Problem benennt: Ein Screenshot zeigt, wie die Seite aussieht. Ein Pin zeigt, was sie ist. Wer Webdesign macht, weiß, dass der Abstand zwischen beiden Aussagen der ganze Job ist. Wenn ein Agent denselben Abstand nicht überbrücken muss, spart das nicht Sekunden, es spart Runden. Und Runden sind der teure Teil, weil jede Runde ein Turn ist.

Erste Grenze: Der Kommentar-Modus sitzt im Desktop-Client, nicht im Telefon. Ich steuere von unterwegs über Telegram, und die Pins entstehen am Schreibtisch, wenn das MacBook offen ist. Das ist für meinen Workflow kein Problem, weil ich Webdesign ohnehin am großen Screen mache. Es ist aber keine mobile Lösung, und wer den ganzen Loop vom Telefon aus erwartet, liegt falsch.

Zweite Grenze: Pins ersetzen den richtigen Auftrag nicht. Wenn ich sage "der Button soll schöner werden", bekommt der Agent einen Selektor, aber keinen Geschmack. Der Wert der Funktion liegt in der präzisen Stelle, nicht in der präzisen Absicht. Ich habe im Test die Notizen bewusst knapp gehalten und trotzdem den Design-Entscheid selbst getroffen. Der Agent baut, was ich anpinke, nicht was ich meine.

Dritte Grenze: Der Kommentar-Modus hat mein Gefühl für die roten Linien nicht ersetzt, sondern verschärft. Ich sehe jetzt schneller, wo mein Layout inkonsistent ist, weil die Pins nummeriert sind und nebeneinander liegen. Das ist gut für die Arbeit, aber es bedeutet auch, dass ich mehr Korrekturen formuliere, als ich vorher getippt hätte. Wer dachte, Agenten machen Feedback überflüssig, hat den Teil verwechselt, der bleibt: das Urteil.

Die Blog-Seite hier steht als nächster Testkandidat an. Ich habe vor, eine Überarbeitung der Vergleichs-Serie komplett über Pins zu fahren: jede Überschrift, jeder CTA, jede Tabelle bekommt einen Pin mit einer kurzen Notiz, und ich lasse die Änderungen als Batch laufen. Danach will ich den Loop gegen meinen alten Screenshot-Loop stellen und beide Nachrichtenmengen danebenlegen. Wenn die Zahl nachlässt und die Qualität hält, schreibe ich das Update als eigenen Beitrag, mit den konkreten Zahlen statt mit Gefühl.

Parallel schaue ich mir an, wie die Import-Ansicht für fremde Transkripte mit meiner Werkstatt zusammenspielt. Ich habe Agenten auf verschiedenen Geräten, und deren Protokolle landen in verschiedenen Formaten. Wenn der Desktop-Client die einlesen kann, wird aus meiner Agentenfamilie eine Agentenfamilie mit gemeinsamem Fotoalbum. Das ist ein Test für die kommenden Wochen, kein Versprechen. Was ich heute sagen kann, ist nur das, was ich gemessen habe: 0.21 hat meinen Loop vom Screenshot auf das Element umgestellt, und das war der richtige Schritt.

Über den Autor: Ich bin Marcel und betreibe das HUNTER-Cyberdeck auf einem gebrauchten Google Pixel 6a, dazu Hermes Desktop auf dem MacBook. Die Tests zu diesem Beitrag habe ich am 11. und 12. September 2026 im Alltag gefahren, im normalen Betrieb mit Telegram-Brücke und Cron. Zuletzt fachlich geprüft am 12.09.2026.

Quellen: Release-Notizen Hermes Agent v0.21.1 (Tag v2026.9.7, 07.09.2026) und v0.21.2 (Tag v2026.9.11, 11.09.2026), GitHub NousResearch/hermes-agent, abgerufen am 12.09.2026. Blake Crosley, The Practitioner's Reference (2026), Nachzählung der Release-Fenster aus einem lokalen Klon, abgerufen am 12.09.2026. Eigene Messwerte: Pixel-Cyberdeck-Betrieb, September 2026.