In this series

  1. Why I modernized my homelab instead of upgrading it
  2. Making a homelab repository agent-friendly
  3. Building the new K3s foundation
  4. Proving the entire platform with one blog
  5. Handing PostgreSQL over to Amp
  6. Modernizing an application, not merely moving it
  7. Replacing a surveillance media chain, not just a recorder
  8. Proving Frigate before the cutover
  9. Upgrading observability beyond the old cluster
  10. Building a platform agents can keep improving (this post)
A developer works at an orderly homelab bench while remote agent sessions run beside guarded production infrastructure

The point was not only to rebuild the homelab. It was to leave a platform that agents can keep improving safely.

Why did I spend so much time rebuilding a homelab that was still mostly working? Newer software was one reason, but it was not the main one. I wanted the next upgrade, security fix or half-finished idea to be easier than this one. Future Vincent had already inherited enough jobs from past Vincent!

So this project had two goals. The first was the long-overdue upgrade and rewrite. The second was to build a platform that agents can safely improve later. The previous posts tell the individual stories. This final part is about what that changes for me.

The LLM is only part of it

Better LLMs obviously made this possible, but an LLM on its own is still just a very clever chat window. It can explain Kubernetes all day and my cluster will remain exactly as old as before.

What made the difference was the agent setup around it. Amp could read the real repository, change it and run the same checks I would run. Each Orb had its own clean environment, so one task did not inherit whatever mess happened to be on my laptop. Repository instructions explained the safe way to work, and restricted runners reached the homelab only when a real test needed them.

The model did the reasoning. Amp gave it the tools, context and a safe place to work. Both mattered.

The real gain was async work

Watching an agent type quickly is impressive for about five minutes. The much bigger gain was that I did not need to sit beside it.

I could give an Orb a clear objective, let it investigate or build, and come back when it had evidence for me. Several independent jobs could run in separate sessions without fighting over one workspace. I could review a finding, answer a question or redirect a session from my phone. Production decisions still needed my attention, but the investigation did not stop just because I left my desk.

The screenshot below gives a small idea of that pace. Home Portal alone had reached 38 Amp threads and was still moving that day. Each thread kept its own task and history, instead of everything being squeezed into one heroic terminal session. My terminal has suffered enough already.

Amp project activity card for Home Portal showing 38 threads, two collaborators and a rising activity line

Remote sessions made the development pace visible: Home Portal alone had reached 38 threads.

Without hosted agents working in the background, I would not have found enough time for this rebuild. I certainly would not have had time to fix the bugs and security problems found along the way. Speed helped, but being able to work asynchronously was the game changer.

Can agents be trusted?

People often say LLMs are unreliable. They can be. An agent can misunderstand the task, trust the wrong health check or continue very confidently from a bad assumption. Confidence, unfortunately, is not a test result.

My experience is that agents can also be extremely diligent when I give them a clear goal and a solid way to check their own work. Telling an agent to “be careful” is not enough. I want it to inspect the right environment, test the real route, compare the data, open the page in a browser and stop if the result is wrong.

That happened several times during this rebuild. A check caught a result that only looked successful, and a release stopped instead of moving to production. This does not make the agent infallible. It means the usual engineering practices still work: keep the change small, test the real thing, record the result and require approval before doing anything risky. No green test, no Ship button. Simple!

I do not need an agent that is always right. I need one that checks its work, tells me what is still uncertain and stops when a check fails.

What this scale cost me

Receipt-style statement showing the monthly subscriptions and the Amp payout split between two months of subscription credits and extra token usage

There is no honest “API-equivalent” price for this work. My linked subscriptions covered a lot of the inference, including 656.6M tokens recorded at USD 0. Nobody can tell me what exactly the same work would have cost through model APIs, so I will not invent a number.

What I can show is what I actually paid Amp: USD 392.23 in total. That includes USD 40 of Amp subscription credits from two months, leaving USD 352.23 of extra token usage. Orb usage was only a tiny part of the total.

The usage is still useful for showing the scale. Across my account, I recorded 1.27B tokens: 656.6M through linked ChatGPT and 613.3M from Amp. I also found 180 threads linked to this repository. The thread chart and model charts cover different scopes, and seven older or plugin-created threads did not record a mode.

Donut chart showing 146 of 180 repository-linked threads in medium mode, with smaller shares in high, ultra and low modes

Most repository work stayed in medium mode.

Donut chart showing GPT-5.6 Sol accounting for 90.3 percent of 1.27 billion account-wide tokens

GPT-5.6 Sol accounted for most account-wide model traffic.

Donut chart showing GPT-5.6 Sol accounting for 86.9 percent of the USD 392.23 recorded account-wide cost

The recorded-cost split shows how Amp allocated the USD 392.23 payout. Linked ChatGPT inference recorded tokens at USD 0.

These are large numbers, but they are not a benchmark. Your homelab does not suddenly need a billion tokens to be respectable! They simply show how much work my subscriptions, prepaid credits and hosted environments supported.

What comes next?

The external watchdog from Part IX runs on the same free-tier Oracle VM as my OpenClaw. The obvious next step is to let Amp reach further: keep OpenClaw updated, harden the setup and build my own knowledge base for an always-on personal agent that I host myself.

That work is still ahead of me. I want to approach it in the same way as the homelab: clear ownership, repeatable changes, proper checks and a human decision before anything risky. An always-on personal agent sounds great. An always-on personal agent with no guardrails sounds like the beginning of a different kind of blog series.

A much better starting point

My old homelab depended too much on spare weekends, commands I was supposed to remember and my willingness to disturb something that was just about working. That is why so many upgrades waited for years.

The rebuilt platform is different. More of its design now lives in the repository. Agents have isolated places to work, real ways to test their changes and clear boundaries around production. LLMs made the work faster, but remote agents made it possible for me to fit the work into my life. Verification made that speed useful rather than scary.

I started this project with five years of jobs waiting for future Vincent. At least the next future Vincent will have some help.