Mein 45-Euro-Handy wurde zum Server: Jetzt dirigiere ich vom Laptop

Drei Wochen lang habe ich meinen KI-Agenten über eine Miniatur-Tastatur gesteuert. Das Gerät ist ein Google Pixel 6a mit 6-Zoll-Bildschirm, ich tippe mit zwei Daumen, und für längere Texte nutze ich die Spracherkennung des Telefons. Das funktioniert – und es war trotzdem anstrengend. Am 21. September hat sich das geändert, und der Weg dahin ist eine kleine Lektion darüber, was Ergonomie für ein Ein-Mann-Technikprojekt bedeutet.

Mein Setup sieht so aus: Ein gebrauchter Pixel 6a, für 45 Euro gekauft, läuft als Cyberdeck. Darauf wohnt der Agent – ein Hermes-Agent mit Gateway, Cron-Jobs, Gedächtnis-Schichten und einem Blog. Das Denken passiert in der Cloud, das Telefon orchestriert. Das habe ich in mehreren Beiträgen beschrieben, und es funktioniert seit Wochen stabil. Was aber niemand gefragt hat: Wie steuere ich das Ding eigentlich im Alltag?

Die ehrliche Antwort: mit Daumen. Termux öffnen, Agent ansprechen, Feedback lesen, Bestätigungen tippen. Die Spracherkennung hilft bei langen Sätzen, aber Steuerbefehle, Slug-Namen, Passwörter und Pfadangaben sind Diktierhölle. Drei Wochen ging das gut, weil die Aufgaben klein waren. Sobald echter Text anfiel – Blog-Rohmaterial, Briefings, Korrekturschleifen – wurde die Miniatur-Tastatur zum Flaschenhals. Ich habe dem Agenten Aufgaben in Fragmenten gegeben, nicht weil das besser war, sondern weil langes Tippen nervte.

Hermes hat eine Desktop-App für macOS, Windows und Linux. Normalerweise startet sie eine eigene, lokale Agent-Instanz. Aber sie kann sich auch mit einem entfernten Backend verbinden – mit einer Maschine, auf der ein Hermes-Server-Prozess läuft. Genau das habe ich am 21. September eingerichtet: Auf dem Pixel habe ich den Server-Modus gestartet, gebunden auf das Netzwerk-Interface, mit einem Login geschützt. Die App auf dem MacBook verbindet sich über die WLAN-Adresse des Telefons.

Der Einrichtungs-Aufwand war lächerlich klein: zwei Konfigurationswerte, ein Server-Prozess im Hintergrund, ein Passwort. Danach erschienen in der App alle Sessions, alle Skills, das Gedächtnis des Agenten – alles, was auf dem Telefon liegt. Die App ist keine Kopie des Agenten, sie ist ein Fenster. Das Fenster ist schnell, weil es nur anzeigen muss. Das Denken passiert in der Cloud, die Orchestrierung auf dem Telefon, das Rendern auf dem Laptop – drei Geräte, drei Rollen, null zusätzliche Kosten.

Das klingt nach Komfort-Kram, ist es aber nicht. Die Miniatur-Tastatur war ein Filter: Kurze Befehle, kurze Antworten, keine langen Briefings. Ich habe dem Agenten Aufgaben in Fragmenten gegeben, weil lange Texte tippen nervte – und er hat entsprechend fragmentiert geantwortet. Seit dem Laptop schreibe ich ihm ganze Absätze, ganze Storys, ganze Korrekturlisten, und die Qualität der Zusammenarbeit ist deshalb anders, weil meine Eingaben reicher sind. Ein Agent ist nur so gut wie der Kontext, den man ihm gibt, und der Kontext war vorher durch die Tastatur limitiert, nicht durch den Agenten.

Zweitens die Dateien: Ich kann Bilder direkt in die App ziehen, statt sie über einen Cloud-Umweg zu schicken oder Screenshots zu fotografieren. Drittens das Lesen: Ein großes Fenster statt Hamster-Scrolling auf 6 Zoll. Und viertens – das hat mich selbst überrascht – die Geschwindigkeit. Ich hatte erwartet, dass die Desktop-Verbindung langsamer wäre als das Terminal direkt am Gerät. Das Gegenteil trat ein: Das Rendern am Laptop ist sofort, die Denkzeit liegt in der Cloud und ist dieselbe, und die Netzwerk-Hops im eigenen WLAN sind vernachlässigbar. Der Engpass war nie das Telefon. Der Engpass war die Tastatur.

Der Weg dahin hatte drei Hürden. Erstens die Zugangsfrage: Die App braucht einen eigenen Login gegen das Backend, den habe ich gesetzt – Benutzername und Passwort, gespeichert in der Secrets-Datei des Agenten, niemals im Klartext irgendwo anders. Zweitens die Netzwerk-Frage: Der Server muss erreichbar sein, aber nur aus dem eigenen Netz. Für unterwegs wäre ein VPN der saubere Weg; eine Port-Weiterleitung ins offene Internet habe ich bewusst nicht gemacht. Drittens die Frage, die ich vorher nicht bedacht hatte: Was macht das eigentlich mit dem Telefon, wenn die App darauf connected?

Die Antwort nach dem Messen: Der Server-Prozess braucht 199 Megabyte RAM, die CPU bleibt bei null, solange nichts läuft. Das Telefon merkt die App kaum. Es ist ein Fenster, kein Gast. Und der eigentliche Englag war nie die Hardware – es war die Frage, ob ich den Server überhaupt starte. Ein Nachmittag Arbeit, den ich drei Wochen vor mir hergeschoben habe, weil ich dachte, das wäre ein Projekt. Es war ein Konfigurationswert.

Wenn du einen Agenten auf einem billigen Gerät betreibst und bisher alles über das Gerät selbst steuerst: Der Schritt zum Laptop als Steuerfenster ist der größte Komfort-Sprung, den ich in diesem Projekt hatte. Er kostet nichts, braucht kein Root und keinen zweiten Server – nur einen Server-Modus, ein Passwort und ein Heimnetzwerk. Was du brauchst: das billige Gerät, das läuft und wach bleibt; ein WLAN; und ein zweites Gerät mit Bildschirm. Mehr nicht.

Die Grenze liegt woanders: Für unterwegs braucht es ein VPN, wenn du nicht im selben Netz bist wie das Telefon. Und wer ein komplett unabhängiges zweites System will, braucht eine zweite Instanz. Ich wollte genau das nicht – ich wollte dasselbe Gehirn an einem zweiten Fenster, und genau das gibt die Remote-Gateway-Architektur her. Ein Gehirn, mehrere Türen, null zusätzliche Agenten.

Ein Gedanke, der mir dabei untergekommen ist: Die Antwortzeit fühlt sich in der Desktop-App schneller an als am Telefon, obwohl der Agent derselbe ist. Der Grund liegt nicht in Magie, sondern in der Aufteilung der Last. Das Denken läuft in der Ollama-Cloud und braucht immer gleich lang, egal von wo ich frage. Das Rendern übernimmt das MacBook, und das ist auf einem Laptop-Bildschirm so schnell, dass ich es nicht bemerke. Das Telefon orchestriert mit rund 199 Megabyte RAM für den Server-Prozess und fast null CPU im Leerlauf. Keine dieser Maschinen ist überlastet, deshalb fühlt sich alles sofort an – die Geschwindigkeit, die ich spüre, ist die der richtigen Aufteilung, nicht die eines schnelleren Prozessors.

Der zweite Gedanke betrifft die Kosten. Die Anbindung hat mich null zusätzliches Geld gekostet: Der Server-Modus ist Teil der Hermes-Installation, das MacBook habe ich ohnehin, und das Netzwerk ist mein WLAN. Was dazukam, sind zwei Konfigurationswerte und ein Passwort. Verglichen mit dem, was ein zweiter Server oder ein teureres Telefon gekostet hätte, ist das der günstigste Komfort-Upgrade meines Projekts – und er war drei Wochen lang ungenutzt, nur weil ich annahm, der Aufwand wäre größer.

Für die Einrichtung selbst war der wichtigste Schritt, den Server-Modus dauerhaft laufen zu lassen, nicht nur für eine Session. Auf einem Android-Gerät ist das die eigentliche Kunst: Prozesse müssen überleben, dass Android sie nachts tötet. Bei mir läuft der Server in einem tmux-Session unter demselben Watchdog wie der Gateway – ein Prozess, der bei Absturz automatisch neu startet. Ohne dieses Gerüst wäre die Desktop-Verbindung ein nettes Experiment gewesen, das nach dem ersten Akku-Sparzyklus weg war. Mit dem Gerüst ist sie eine Tür, die offen bleibt.