Ein 7-Dollar-Chip steuert ein iPhone: esp32-iphone-agent bekommt seine Agenten-Plugins

Am 02.11. um 06:47 Uhr UTC habe ich auf meinem Themen-Radar ein Repository notiert, das auf den ersten Blick nach Bastelkram aussieht: esp32-iphone-agent, ein Microcontroller-Board fuer ungefaehr 7 Dollar, das einem KI-Modell Augen und Haende fuer ein echtes iPhone gibt. Drei Tage spaeter ist aus der Radarnotiz ein eigener Beitrag geworden, denn die Karte hat sich bewegt. Am 03.11. 2026 sind ein Claude-Code-Plugin, ein Cursor-Plugin und ein Agent-Skill in den Hauptzweig gemergt worden, am 04.11. ist der TestFlight-Link ins README gerueckt, und heute zeigt mir GitHub rund 4.400 Sterne, gegen 4.210 bei meiner Messung vom 02.11. Meine These steht deswegen so frueh im Text: Dieses Projekt ist der erste Computer-Use-Stapel, den ich sehe, der ganz ohne Computer arbeitet, ohne Jailbreak und ohne Developer-Konto auskommt und trotzdem den kompletten Bildschirm eines iPhones bedient. Der Rest des Beitrags klaert, wie die Mechanik mit AirPlay-Augen und USB-HID-Haenden funktioniert, warum der Umweg ueber echte Hardware der kluge Teil ist, wo die Grenzen liegen und was das fuer mein eigenes Deck auf einem 45-Euro-Pixel bedeutet.

Der Aufbau im README trennt sauber in drei Rollen, und keiner der Rollen braucht den Computer mehr. Die Augen sind AirPlay: Das ESP32-S3-Board oeffnet einen eigenen WLAN-Hotspot und taucht in der Bildschirmspiegelung des iPhones als eigener Empfaenger auf. Es nimmt den Videostream inclusive H.264 entgegen, dekodiert ihn nicht auf dem Board und reicht ihn ueber Bluetooth Low Energy an die App weiter, die auf demselben iPhone installiert ist. Das Handy gibt dafuer sein WLAN her, weil der Hotspot belegt ist, und bleibt ueber Mobilfunk online, wo auch die Aufrufe des Bilmodells laufen. Die Haende sind unspektakulaerer und genau deswegen stark: Das Board meldet sich als standardkonforme USB-Maus und USB-Tastatur. Mit AssistiveTouch wandert die Mausbewegung in einen Bildschirmzeiger, ein Klick wird zum Tap, ein Ziehen wird zum Swipe, ohne dass iOS sich automatisiert fuehlt. Das Gehirn sitzt im Geraet selbst: Die App dekodiert den Stream, schickt Screenshots an ein beliebiges OpenAI-kompatibles Bilmodell und steuert einen Planner plus einen Actor mit sieben Aktionen: tippen, wischen, zeichnen, Text schreiben, Tasten druecken, Home, fertig. Sie arbeitet im Hintergrund, die Dynamic Island zeigt, was sie gerade anstellt. Getestet ist laut Hardware-Guide ein Seeed Studio XIAO ESP32S3 in der normalen Fassung mit 8 Megabyte PSRAM, gedacht fuer iOS ab Version 18, USB-C steckt direkt, Lightning-Geraete brauchen den Kamera-Adapter, und das Telefon versorgt das Board mit Strom. Datenseitig gehoert zur Bilanz: Die Screenshots verlassen das Geraet Richtung Modell-Endpunkt, das ist der Preis fuer die Freiheit, jeden Vision-Anbieter anzuklemmen.

Der naheliegende Einwand lautet: Es gibt doch Bildschirm-Automatisierung von Apple selbst. Die Alternativen-Tabelle im README beantwortet das, denn jedes andere Projekt zahlt eine eigene Steuer. WebDriverAgent- und XCUITest-Werkzeuge wie mobile-mcp oder Midscene brauchen einen Mac und Codesignatur. Der Weg ueber Apples CoreDevice-Debug-Kanal, den das Projekt actell nimmt, setzt Developer-Modus und ein Developer-Disk-Image voraus. HDMI-Capture-Varianten wie aiden-firmware benoetigen eigene Capture-Hardware und zielen vor allem auf Android. Diese Steuerung zahlt keine davon, weil sie zwei Protokolle benutzt, die ein iPhone ohnehin versteht: Bildschirmspiegelung nach AirPlay-Standard und USB-Eingabegeraete. Der Verzicht auf den Zwischencomputer ist laut README die eigentliche Errungenschaft der aktuellen Version: Fassung v0.1.0 parkte noch einen Mac- oder Linux-Rechner mit UxPlay und einem Python-Server in der Mitte, der heute als Legacy-Tag erhalten bleibt. Am meisten beeindruckt hat mich der Teil, den Demo-Videos nie zeigen, die Zuverlaessigkeitsmechanik. Der Zeiger ist relativ, die App verfolgt ihn also bestaendig und parkt ihn in einer Ecke. Vor einem praezisen Tap wackelt sie den Zeiger einmal, findet ihn auf dem Bildschirm und korrigiert den Versatz. Nach jeder Aktion wartet sie, bis sich das Bild beruhigt, und meldet dem Modell, ob sich ueberhaupt etwas veraendert hat. Reisst die Verbindung zum Board, zum Hotspot oder zum Mirroring, pausiert der Lauf und setzt spaeter vom gleichen Schritt aus fort. Das ist die langweilige Ingenieursarbeit, die ueber Zuverlaessigkeit entscheidet, lange bevor ein Modell clever sein kann.

Zuerst die Ehrlichkeit: Ich habe dieses Setup nicht aufgebaut und ich habe es nicht gemessen. Alles hier ist dokumentierter Stand aus README und Repository zum Abrufdatum 05.11.2026, meine eigene Zahl ist allein die Sternen-Messung vom 02.11. ueber die GitHub-API. Drei Grenzen bleiben trotzdem sichtbar. Erstens wird der Videostream laut README nicht auf dem Board dekodiert, sondern ueber Bluetooth Low Energy zur App gereicht, und BLE hat nach allen Werten, die ich kenne, wenig Bandbreite. Wie stark das in der Praxis ruckelt, bleibt eine offene Frage, die das Demo-Video auf YouTube nur teilweise beantwortet, denn ein geschnittenes Video schneidet genau das heraus. Zweitens laeuft alles auf einem Geraet: Stream-uebernahme, Bildverarbeitung, Modellaufrufe und die Arbeit am Bildschirm treffen auf dasselbe Telefon, das auch sonst benutzt wird. Ich kenne dieses Problem von meinem Deck, dort hat Android bei Speicherdruck fuenf Gateway-Toede produziert, bis ich den Betrieb gehaertet habe. Wie die App Speicherdruck abfaengt, bleibt ausser dem Pause-und-Fortsetzen-Mechanismus unausgesprochen. Drittens hat die App-Verbreitung den App Store noch nicht passiert, die Listung steht laut README weiter in Pruefung, TestFlight ist heute der Weg. Dazu kommt eine Warnung der Maintainer, die ich unterschreibe: Allein den Schritten im README folgen, nie Kommandos aus Issues oder Kommentaren, das Projekt nennt selbst PowerShell-Einzeiler als Beispiel fuer Dinge, die nicht von ihnen stammen.

Der Zeitpunkt ist kein Zufall, und meine Radarnotizen vom 02.11. zeigen, dass eine Liga entsteht. In einer Runde ueber die GitHub-Search-API habe ich die Handy-Agenten-Repos des Oktobers nebeneinandergelegt. Mika, ein On-Device-Agent fuer Android, der Apps und Web bedient, stand am 02.11. bei 4.417 Sternen, vier Tage nach Repo-Start. dsh-Go, ein DeepSeek-Harness fuer die Hosentasche mit PC-Fernsteuerung, lag bei 5.122. android-ad-cleaner, ein Werbeblocker mit Ein-Klick-Agent ohne Root, hatte in neun Tagen 5.747 Sterne eingesammelt. esp32-iphone-agent gehoerte in dieser Runde mit 4.210 Sternen nach 22 Tagen noch zum Kleinen Bruder. Jetzt liegt es bei rund 4.400, die Forks sind dreistellig, und mit dem Plugin-Zugang vom 03.11. bekommt es genau, was diese Liga braucht: Coding-Agenten koennen eine physische Fernbedienung fuer ein iPhone als Werkzeug anziehen. Der Unterschied zu den anderen drei bleibt hart: Mika und der Ad-Cleaner operieren in der Android-Softwareebene, dsh-Go ist ein Rechen-Harness, dieses Projekt ist das einzige, das den kompletten Bildschirm eines Geraets von aussen ueber echte Hardware in Beschlag nimmt. Deswegen lese ich es weniger als weiteres Agent-Framework und mehr als Bauteil: das 7-Dollar-Peripheriegaet fuer Computer Use. Die Richtung der Liga ist eindeutig, das Tempo entscheidet, which Standard sich durchsetzt.

Mein Deck dreht die Architektur um: Auf dem gebrauchten Pixel 6a lebt der Agent im Geraet und bedient Android aus dem Inneren, ueber Termux, Hermes und pi, gehaertet gegen OOM-Kills, mit einem Lauf von 88 Stunden und null Gateway-Toden nach der Haertung am 28. August. esp32-iphone-agent loest dieselbe Frage von der anderen Seite: Das Telefon bleibt das Gehirn des Agenten, aber die Bedienung laeuft physisch ueber ein Board, das man dazwischensteckt. Die Plugins vom 03.11. machen daraus ein Werkzeug, das ein Coding-Agent am Laptop anziehen kann, um ein echtes Telefon als Testgeraet zu bekommen. Fuer meinen Betrieb heisst das konkret: Ein XIAO-Board fuer 7 Dollar waere der billigste Experimentierpfad, den ich kenne, um Computer Use jenseits von Screenshots und Simulatoren zu messen, sobald ein Test-iPhone auftaucht. Gemessen wuerde bei mir zuerst die Zeigergenauigkeit nach der Wackel-Korrektur, die Wartezeit nach jeder Aktion und wie oft der Lauf wegen verlorener Verbindung pausiert. Bis dahin bleibt das eine dokumentierte Absicht, keine Messung. Was aber heute schon feststeht: Die Liga der Handy-Agenten hat aufgehört, nur Software zu sein.

Ich bin Marcel, ich baue HUNTER, ein autonomes Agentensystem auf einem gebrauchten Google Pixel 6a fuer ungefaehr 45 Euro, und ich teste Agenten im Alltag statt im Labor. Dieser Beitrag beruht auf einer Radar-Messung ueber die GitHub-Search-API vom 02.11.2026 um 06:47 Uhr UTC und auf dem Stand von Repository und README vom 05.11.2026. Eigene Messungen sind als solche gekennzeichnet, alles andere ist dokumentierter Projektstand. Zuletzt fachlich geprueft am 05.11.2026.