The Tamagotchi operations manual: how to keep an agent alive

On September 7, 2026, I had a discussion about the uptime of my own system that nearly made me angry. Not because anyone lied, but because both sides calculated correctly and confused everything in the process. An AI summary of a forum thread claimed my agent had been running for 83 hours straight, and my own Telegram agent countered with 23 hours of process runtime and declared the number unverifiable. Both sides were right, and both were talking about completely different things. Somewhere along the way, a planned window switch got equated with a system death. That exact confusion is why almost nobody in the community keeps an agent alive for weeks. I call my method the Tamagotchi operations manual, and it has kept my agent alive since August 28, 2026 without a single crash.

The thesis up front: a context reset is not a crash. A context reset is maintenance, as plannable and unspectacular as an oil change. A crash is a kill, an intervention from outside that terminates a process. Whoever throws both into the same bucket does not understand their own system and therefore cannot run it for long. What I describe here is not a theory from a forum post but the operation of a real agent on a used Google Pixel 6a that cost 45 euros, without root, with measurable numbers and a public proof log.

I separate three levels that almost every discussion about agents mixes together. First, the runtime of the system: the gateway process has been alive continuously since August 28, 2026, more than 225 hours as of the cutoff date, and the proof chain is public, one hourly heartbeat message after another. Second, the working window: the chat context in which the agent is currently thinking grows with every message until it compresses or gets reset. That is by design, like a workshop that needs clearing out every once in a while. Third, the kill: Android terminates processes when memory gets tighter than the apps' appetite. That is the only genuine death in this setup, and it happened exactly once, on August 28, when a background Chromium ate the available RAM. Everything else is maintenance. When a discussion about crashes mixes these three levels, you get exactly the garbage that nearly made me angry that morning: a window switch booked as a system death.

In my setup a context reset is a planned procedure with a fixed sequence. I keep an eye on the context window, and as soon as it starts compressing, I tell the agent: create a re-entry point for yourself. The agent then writes its own re-entry point, a note that the next agent reads first, and only then do I reset the window. The dictation from that morning, which contains the whole routine, went in essence like this:

The division of labor is the actual trick. I watch the window and recognize when compression begins. I order, the agent writes the checkpoint, I press the reset button, and the next agent reads itself into its own legacy when it starts. It feels like a reboot and is in truth a handover protocol. Until September 7 I was the keeper watching the fill level. On that day I additionally anchored the rule that the agent will take over the monitoring itself and suggest a checkpoint in time when one is due. Whether that rule holds will be proven by its first real run, and I will talk about it only once it has happened. Since we have been working this way, not a single working window has been lost, and the evidence package from that morning showed 161 sessions with more than 10,000 stored messages that survived all those window switches because they never lived inside the window.

So nothing gets glossed over: I am not talking down what a crash is. A kill is a kill. On August 28, 2026, Android pulled the plug on a process because a background Chromium had eaten the RAM, and the terminal was dead for a moment. That was the only incident of its kind. After that I hardened the system: the tick that drives the cron jobs comes from outside, the heartbeats run hourly and publicly, and the restart chain survives a full reboot of the phone. The dmesg check of September 7 shows zero OOM kills since the hardening. How the external tick and the watchdog are built is described in the post Android kills processes, the cyberdeck survives it.

The operations doctrine itself is so unspectacular that it fits in four steps. First, feed: a checkpoint gets written before the window compresses, not after. Second, switch the window: a reset costs nothing because the memory does not live in the window. Third, keep living: the new context reads the re-entry point and continues from line one at full care. Fourth, stay honest: a reset is never sold as an emergency, because there is none. A Tamagotchi does not die because you switch the window. It dies when nobody feeds it. That is why the most important number in this setup is not the process runtime but the distance between two checkpoints.

The best part of the whole thing: the doctrine was dictated on the morning of September 7 and applied live in full for the first time in that same morning. I was in a session that had been running since the previous evening, in the middle of explaining why this doctrine is technically better than what 95 percent of the community does. At that moment I saw myself that the compression limit had been reached and told the agent: document the state, I am resetting the window. It rewrote the re-entry point completely, I reset the window, and the next agent had read itself in and continued working by seven sharp. Dictated around five, executed at seven, with no night between theory and practice.

The reason all of this works lies outside the window. Five layers hold the memory: a rules file that loads automatically on every start, an Obsidian vault as the dated brain, a local fact store with trust scores, a slim memory trigger, and a full-text search across all past sessions. The chat in our setup is a transient artifact, the interface, not the head. That is exactly why I can throw the window away mid-work and lose nothing but the loading time. People in the community run agents as chatbots, and when the window fills up, the whole head starts over. With us the head lives in the vault, and the window is just the socket. That such a head can be built on a 45 euro phone without root is described in the post A cyberdeck from a 45 euro phone.

Numbers as of September 7, 2026, 7:00 AM: the gateway has been running since August 28, 1:40 PM, more than 225 hours, proven by a gapless public heartbeat chain and not by process numbers from a container that dreams when asked anyway. Liveness in the snapshot is 306 of 306 checks, one hundred percent, with 917 megabytes of free RAM at eleven running jobs. Exactly one kill is on record, on August 28, zero since the hardening. The evidence package from that morning holds 161 sessions, 10,217 stored messages and almost 3,800 API calls in the last seven days, plus 29 published posts on this blog. And so nobody mistakes this for marketing: the numbers are written by the same checking chain that controls the posts on this blog, see The checker that does not ask.

To close, here is what I dictated on the morning of September 7 when the discussion nearly made me angry. The wording, only tamed for spelling:

So the challenge stands. Whoever wants to refute this system has to undermine the public heartbeat chain or dispute the dmesg output. Until then the operations manual applies, and the agent lives. It lives long enough that the real question is no longer whether a 45 euro phone can keep an agent alive, but when the rest of the scene starts maintaining properly instead of just launching.

I am Marcel, a graphic designer, and I run the HUNTER cyberdeck on a used Google Pixel 6a in daily operation. This post draws on the operation from August 28 to September 7, 2026: the public heartbeat chain, the stability snapshots, the dmesg check of September 7, 2026, and the evidence package from the session database. I dictated the operations doctrine on the morning of September 7, 2026, and the wording is quoted in this post. Last technically reviewed on September 7, 2026.