Android kills processes — but this 45-euro phone survives it

The OOM Storm and the Hardening

On August 28, I experienced what Android does under memory pressure: five gateway deaths in one day, by SIGKILL, without warning. The trigger was a headless Chromium that the watchdog restarted on every crash, creating memory spikes. Chromium was never the real problem, it was just the proof that Android cracks down ruthlessly under memory overload. Any other memory-hungry program would have done the same.

The fix consisted of several layers: I removed the Chromium memory hog so it never starts automatically again. I set up an external cron tick that fires independently of the internal gateway thread. And I built a semantic watchdog that doesn't ask "is the process running?" but "is the system actually working?", it checks heartbeat, last successful tick, and overdue jobs, with a cooldown against restart loops.

The key message is: Android always wins under memory pressure. The system is built to survive kills, not to prevent them. Three days without a kill mean we avoided memory pressure, not that we beat Android.

The Memory: Five Safety Layers

An agent that forgets nothing needs more than a fleeting memory. The core problem was: the built-in memory only holds 2,200 characters and was full, important information only lived in the fleeting chat. The solution consists of five independent layers:

1. **AGENTS.md**, loaded automatically at every session start, independent of memory. The layer that never forgets.
2. **Obsidian Vault**, the brain, the single source of truth, with all decisions and test results.
3. **Memory**, consolidated, now just a slim trigger.
4. **Skills**, procedural memory, loaded on demand.
5. **session_search**, a full-text search over all past sessions.

Plus a Holographic Memory provider: a local SQLite database without limits that lifts the 2,200-character cap. No cloud, no cost, unlimited memory on the device.

The Multi-Agent Workflow

The heart is not a single agent, but the orchestration of several. For that to work, you need an environment where multiple agents run at the same time and can hand tasks to each other. That's exactly what herdr does, a terminal multiplexer that makes it possible to start and orchestrate multiple agents.

Here's how the system concretely runs: I start the terminal and herdr inside it. In that environment I start the Hermes agent. When I plan a project with Hermes and want to go through the structure, Hermes can simply open another terminal in this one, start the right agent in it, and give it a task. Hermes orchestrates the flow until the agent is done. The agent hands the work back to Hermes, and together with me the project is verified and brought to completion.

Without this multi-agent environment, none of it would work. It's the foundation for Hermes to plan, another agent to execute, and Hermes to independently verify afterward.

That's how two complete projects came about, the Network Obfuscation Layer with 29 of 29 passing tests and the Preiskompass with 7 of 7 passing tests. Together that's 36 of 36 tests, without me writing a single line of code myself. I directed, I didn't program.

Concretely it worked like this: Hermes planned the task and handed it to the coding agent, who did the implementation. Then Hermes independently verified the result, the tests passed, the code was clean. The coding agent that built the projects is the pi agent, connected via herdr. That's the proven workflow behind both projects.

A remote system, where a coding agent on a MacBook is remote-controlled via the ChatGPT app, is planned as the next step but not yet in use. The verified projects were created exclusively through the local multi-agent workflow on the Pixel.

Why This Matters

Many in the coding scene want a device that fits in their pocket and runs real coding agents. Industry attempts like the Rabbit R1 or the Humane AI Pin have failed or are expensive. This project shows: a used Pixel for around 45 euros can be a working, permanently running agent host.

Not "we had the best equipment," but "we had almost nothing and still built something that works." The unconventional path, Android without root, against the logic of the manufacturers, was the only one that worked.

The Contrast: Why This Wouldn't Work on an iPhone

This is where the difference between the platforms becomes especially clear. I've been an Apple user for years and love my MacBook. But I would never get an iPhone for this project again, not because it lacks performance, but because Apple simply doesn't allow it.

Every modern iPhone would have the performance to easily handle a system like this. I can't even imagine how many agents you could run on it without hitting its limits. But Apple doesn't make it possible: there's no environment where you can simply install agents on an iPhone and run them in a terminal, the way I do here on the Pixel. The system simply isn't open enough for that.

That's the real point. The latest foldable iPhone costs around 2,600 euros and probably has enormous performance. But it will never work to set up a system like this on it, not because the hardware is missing, but because the platform doesn't allow it. On a cheap Android device for 45 euros, it works.

That's sad on one hand, but on the other hand it's an important insight: the most expensive hardware is useless if the platform doesn't free it up for something like this. The value isn't in the price of the device, but in what the platform allows you to do. Android allows it, iOS doesn't.

Why I Document This

To close the circle for the whole project: this path and everything that happened and came out of it impressed me so much that I thought, I want to document this in some way. A single post on GitHub wouldn't have been enough. I wanted to use the skills I use for web design to build good pages and polish it so you see the visual standard, and recognize from the quality that this isn't a cheap post trying to farm reach. Quite the opposite.

It would simply be wrong not to talk about it and sweep it under the rug. Because this is the proof that you can recycle tech. Phones that are four years old are easily capable of handling this. That's why I made it my task to document this so deeply and write posts about it. And I'm already very deep in.

The Market Fallacy

The deeper I dive, the clearer it becomes: there's a fallacy about what you think. There's already something that has been possible all along and matches exactly what you imagine having in your pocket, that nobody wants to talk about. Because it would question a market that has been raking in big money the whole time, for tech that nobody really needs, because it has performance that nobody is even using or can use yet.

I recently saw a post on Reddit where people discussed whether they should get a Google Pixel with more RAM and where you notice the difference. There are certainly places where you notice it directly. But I can say right now: if you get the idea to rebuild your phone and run agents on it, and you have a large amount of RAM available, then you will definitely thank yourself for having a phone with that much performance.

Conclusion

HUNTER is not a product. HUNTER is a playground, and we haven't found its limits yet. The story begins with a Raspberry Pi that never became a cyberdeck and leads to a 45-euro phone that can do more than many expensive AI gadgets promise.

The exciting thing about HUNTER isn't that it's finished. The exciting thing is that it never has to be.