Building Anton · Chapter 9 of 14

Anton, chapter 9: Changing my mind about home

June 5, 2026 · 4 min read

2026-04-29 → 2026-06-05

The Spark goes quiet one day in May, and stays quiet. Not a crash, nothing to debug remotely: the box at home is simply unreachable, for days, while I'm not there to press a button. And the thing I notice isn't panic. It's that the family barely notices, because the cloud fallback carries the conversations, and what actually breaks is everything else: the scheduled jobs, the memory writes, the heartbeat, the whole household layer that lives on the same machine as the model.

This forces the conversation I've been avoiding with myself since chapter 1. The founding instinct was that Anton lives at home, on my hardware, close to the family. It's a good instinct and I still believe the half of it that matters. But a home machine has home problems: it shares the power, the network, and the physical room with a family of six, and it runs hot under sustained load in a way a datacenter never lets you feel. The realization, once I stop defending the original position, is that I'd bundled two different claims into one. The model should run on my hardware, because that's where the privacy and the economics point. The system (the always-on plumbing that the family depends on at 7am) should run wherever it's most boring and most reachable. Those were never the same requirement. I'd just wanted them to be.

So the stack moves. The worker, the bridges, the database, the whole application layer goes to a small rented server, always on, reachable from anywhere over the tailnet. The Spark keeps the one job it is uniquely good at: serving the model. It stops being the host and becomes what it functionally always was, a local inference endpoint, no different in shape from a cloud provider except that it's mine. Sometimes you change your mind in a project, and the honest version of this story is that the architecture didn't fail; my framing of it did.

The move surfaces the debt that hiding at home had let accumulate. One session chasing "I should be seeing new episodes and I don't" turns up six independent bugs stacked end to end in the media pipeline, each one masking the next: an air-date filter rejecting every torrent named by episode, a download budget that starved the back half of the watchlist forever, a skill that couldn't reach the download host because it never declared the secret it needed, and three more behind those. Nothing in the stack had been lying loudly. Everything had been failing quietly, in layers, and looking healthy at a glance. A pipeline you don't measure end to end isn't a pipeline, it's a hope.

The next problem pulls me deeper. Investigating why the local model keeps being unreliable as Anton's brain, I finally measure the one thing I'd never measured: the prompt. Eleven thousand four hundred tokens, median, every round. Identity, a storage decision tree, a cast table, thread-awareness rules, auto-loaded memory, auto-loaded directives, auto-loaded recent actions, all of it stacked in front of every single turn. A quarter of the local model's context spent before any work begins, attention diluted to nothing by round three. The diagnosis is uncomfortable: the architecture was written for a frontier model's attention span and then handed to a small one. The model was never the problem. I was asking it to read a novel before every sentence.

The fix is the deepest cut since the framework came out in chapter 5. Anton becomes a router. A three-hundred-token system prompt whose only job is picking the right specialist and composing the reply. The auto-loaded everything is gone: memory, directives, and recent actions stop being ambient context and become things the agent calls when the question needs them. Ask what time it is, and no memory is fetched, no facts ride along, nothing is spent. Ask about Clara's shoe size, and the memory specialist gets called and returns exactly that. The specialists own their domains behind prompts capped small enough that a small model can actually hold them. It's the chapter 4 lesson (give the LLM a small menu) applied to the one agent I'd exempted from it: the one at the top.

The same discipline turns destructive, in the good way, on my monitoring system. I'd built a signals primitive over the spring: definitions table, time-series, stream, drainer, breach state machine, remedy plans. Reviewing it after a false alarm, I make the call to delete nearly all of it. What a one-operator system actually needs to answer "are you healthy?" is a cron that writes a few metric rows and one skill that reads them. Build the abstraction, watch it meet the system's real scale, and keep removing until what's left is exactly what earns its keep. The best architecture review is the one where most of the architecture doesn't survive.

By the time this stretch of work settles, the shape is honest for the first time. The family layer runs where uptime is boring. The model runs where privacy is physical. And the system gets smaller twice, once at the top of the agent and once in its nervous system, both times by admitting that something I'd built with conviction was more than the problem ever asked for.