Android killt Prozesse — aber dieses 45-Euro-Handy überlebt es

Der OOM-Sturm und die Härtung

Am 28. August erlebte ich, was Android mit einem Speicherdruck macht: fünf Gateway-Tode an einem Tag, per SIGKILL, ohne Warnung. Der Auslöser war ein headless Chromium, das der Watchdog bei jedem Absturz neu startete und so Speicherspitzen erzeugte. Chromium war nie das eigentliche Problem — es war nur der Beweis, dass Android bei Speicherüberlastung eiskalt durchgreift. Jedes andere speicherhungrige Programm hätte dasselbe getan.

Der Fix bestand aus mehreren Schichten: Ich habe den Chromium-Speicherfresser entfernt, sodass er nie wieder automatisch gestartet wird. Ich habe einen externen Cron-Tick eingerichtet, der unabhängig vom internen Gateway-Thread feuert. Und ich habe einen semantischen Watchdog gebaut, der nicht fragt „läuft der Prozess?", sondern „arbeitet das System wirklich?" — er prüft Herzschlag, letzten erfolgreichen Tick und überfällige Jobs, mit einem Cooldown gegen Restart-Loops.

Die Kernaussage ist: Android gewinnt bei Speicherdruck immer. Das System ist darauf gebaut, Kills zu überstehen — nicht sie zu verhindern. Drei Tage ohne Kill bedeuten, dass wir Speicherdruck vermieden haben, nicht dass wir Android besiegt haben.

Das Gedächtnis: Fünf Sicherheitsschichten

Ein Agent, der nichts vergisst, braucht mehr als ein flüchtiges Gedächtnis. Das Kernproblem war: Das eingebaute Memory fasst nur 2.200 Zeichen und war voll — wichtige Informationen standen nur im flüchtigen Chat. Die Lösung besteht aus fünf unabhängigen Schichten:

1. **AGENTS.md** — wird bei jedem Session-Start automatisch geladen, unabhängig vom Memory. Die Schicht, die nie vergisst.
2. **Obsidian-Vault** — das Gehirn, die Single Source of Truth, mit allen Entscheidungen und Testergebnissen.
3. **Memory** — konsolidiert, nur noch ein schlanker Trigger.
4. **Skills** — prozedurales Gedächtnis, das bei Bedarf geladen wird.
5. **session_search** — eine Volltextsuche über alle vergangenen Sessions.

Dazu kommt ein Holographic-Memory-Provider: eine lokale SQLite-Datenbank ohne Limit, die das 2.200-Zeichen-Limit aufhebt. Kein Cloud, keine Kosten, unbegrenztes Gedächtnis auf dem Gerät.

Der Multi-Agent-Workflow

Das Herzstück ist nicht ein einzelner Agent, sondern die Orchestrierung mehrerer. Damit das funktioniert, braucht es eine Umgebung, in der mehrere Agenten gleichzeitig laufen und sich gegenseitig Aufgaben übergeben können. Genau das übernimmt herdr — ein Terminal-Multiplexer, der es möglich macht, mehrere Agenten zu starten und zu orchestrieren.

So läuft das System konkret: Ich starte das Terminal und darin herdr. In dieser Umgebung starte ich den Hermes-Agenten. Wenn ich mit Hermes ein Projekt plane und die Struktur durchgehen will, kann Hermes in diesem Terminal einfach ein weiteres Terminal öffnen, darin den passenden Agenten starten und ihm eine Aufgabe geben. Hermes orchestriert den Ablauf so lange, bis der Agent fertig ist. Der Agent übergibt die Arbeit zurück an Hermes, und gemeinsam mit mir wird das Projekt verifiziert und zu Ende geführt.

Ohne diese Multi-Agent-Umgebung würde das Ganze gar nicht funktionieren. Es ist die Grundlage dafür, dass Hermes planen, ein anderer Agent ausführen und Hermes anschließend unabhängig verifizieren kann.

So sind zwei komplette Projekte entstanden — der Network Obfuscation Layer mit 29 von 29 bestandenen Tests und der Preiskompass mit 7 von 7 bestandenen Tests. Zusammen sind das 36 von 36 Tests, ohne dass ich selbst eine Zeile Code geschrieben habe. Ich habe dirigiert, nicht programmiert.

Konkret lief das so: Hermes hat die Aufgabe geplant und an den Coding-Agenten übergeben, der die Umsetzung übernommen hat. Anschließend hat Hermes das Ergebnis unabhängig verifiziert — die Tests bestanden, der Code war sauber. Der Coding-Agent, der die Projekte umgesetzt hat, ist der pi-Agent, der über herdr angebunden ist. Das ist der bewährte Workflow, mit dem beide Projekte entstanden sind.

Ein Remote-System, bei dem ein Coding-Agent auf einem MacBook über die ChatGPT-App ferngesteuert wird, ist als nächster Schritt geplant, aber noch nicht im Einsatz. Die verifizierten Projekte sind ausschließlich über den lokalen Multi-Agent-Workflow auf dem Pixel entstanden.

Warum das relevant ist

Viele in der Coding-Szene wünschen sich ein Gerät, das in die Hosentasche passt und echte Coding-Agenten betreibt. Industrieversuche wie Rabbit R1 oder Humane AI Pin sind gescheitert oder teuer. Dieses Projekt zeigt: Ein gebrauchtes Pixel für rund 45 Euro kann ein funktionierender, dauerhaft laufender Agent-Host sein.

Nicht „wir hatten die beste Ausrüstung", sondern „wir hatten fast nichts und haben trotzdem etwas gebaut, das funktioniert". Der unkonventionelle Weg — Android ohne Root, gegen die Logik der Hersteller — war der einzige, der funktionierte.

Der Kontrast: Warum das auf einem iPhone nicht ginge

Hier wird der Unterschied zwischen den Plattformen besonders deutlich. Ich bin seit Jahren Apple-Nutzer und liebe mein MacBook. Aber ein iPhone würde ich mir für dieses Projekt nie wieder holen — nicht, weil es zu wenig Leistung hätte, sondern weil Apple es schlicht nicht zulässt.

Jedes moderne iPhone hätte die Leistung, um so ein System locker zu meistern. Ich kann mir gar nicht vorstellen, wie viele Agenten man darauf laufen lassen könnte, ohne dass es an seine Grenzen stößt. Aber Apple macht es nicht möglich: Es gibt keine Umgebung, in der man auf einem iPhone einfach Agenten installieren und im Terminal betreiben kann, so wie ich es hier auf dem Pixel tue. Das System ist dafür schlicht nicht offen genug.

Das ist der eigentliche Punkt. Das aktuellste faltbare iPhone kostet rund 2.600 Euro und hat wahrscheinlich eine enorme Leistung. Aber es wird nie funktionieren, so ein System darauf aufzusetzen — nicht, weil die Hardware fehlt, sondern weil die Plattform es nicht erlaubt. Auf einem günstigen Android-Gerät für 45 Euro geht es dagegen.

Das ist einerseits traurig, andererseits eine wichtige Erkenntnis: Die teuerste Hardware nützt nichts, wenn die Plattform sie nicht für so etwas freigibt. Der Wert liegt nicht im Preis des Geräts, sondern darin, was die Plattform einem erlaubt. Android erlaubt es, iOS nicht.

Warum ich das dokumentiere

Um den Kreis für das ganze Projekt zu schließen: Mich hat dieser Weg und alles, was dabei passiert ist und sich herausgestellt hat, so beeindruckt, dass ich mir dachte, ich will das in irgendeiner Art und Weise dokumentieren. Ein einzelner Beitrag auf GitHub hätte dafür nicht gereicht. Ich wollte die Fähigkeiten, die ich für Webdesign nutze, einsetzen, um gute Seiten zu bauen und das Ganze so auszuschmücken, dass man den visuellen Anspruch sieht — und an der Hochwertigkeit erkennt, dass das kein billiger Beitrag ist, der nur Reichweite farmen will. Ganz im Gegenteil.

Es wäre einfach nur falsch, darüber nicht zu sprechen und es unter den Tisch zu kehren. Denn das hier ist der Beweis, dass man Technik recyceln kann. Telefone, die vier Jahre alt sind, sind locker dazu in der Lage, das zu meistern. Deshalb habe ich mir zur Aufgabe gemacht, das Ganze so tief zu dokumentieren und Beiträge darüber zu verfassen. Und ich bin schon sehr tief drin.

Der Markt-Trugschluss

Je tiefer ich eintauche, desto klarer wird: Es gibt einen Trugschluss gegenüber dem, was man denkt. Es gibt schon etwas, das die ganze Zeit möglich ist und genau den Vorstellungen entspricht, was man in der Hosentasche haben kann — worüber nur keiner sprechen will. Weil es einen Markt in Frage stellen würde, der die ganze Zeit heftig am großen Geld kassiert, für Technik, die eigentlich keiner braucht, weil sie Leistung hat, die noch gar keiner nutzen oder einsetzen kann.

Ich habe kürzlich einen Beitrag auf Reddit gesehen, in dem sich Leute darüber unterhalten haben, ob sie sich ein Google Pixel mit mehr Arbeitsspeicher besorgen sollten und an welchen Stellen man den Unterschied merkt. Es gibt sicherlich Stellen, wo man es direkt merkt. Aber ich kann jetzt schon sagen: Wenn du auf die Idee kommst, dein Telefon umzubauen und darauf Agenten laufen zu lassen, und dann eine große Menge an Arbeitsspeicher zur Verfügung hast, dann wirst du dir auf jeden Fall selbst danken, dass du ein Telefon mit so viel Leistung hast.

Fazit

HUNTER ist kein Produkt. HUNTER ist ein Spielplatz — und wir haben seine Grenzen noch lange nicht gefunden. Die Geschichte beginnt mit einem Raspberry Pi, der nie ein Cyberdeck wurde, und führt zu einem 45-Euro-Handy, das mehr kann, als viele teure KI-Gadgets versprechen.

Das Spannende an HUNTER ist nicht, dass er fertig ist. Das Spannende ist, dass er es niemals sein muss.