⚠️🤖
Candid homelab postmortem · August 11, 2026
When More AI Agents Made My Lab Slower
I decommissioned Ouroboros, OpenCode, and Pi Coding Agent. The blunt reason: my small VM had become an orchestration problem. Too many overlapping runtimes, bots, credentials, state stores, watchdogs, and backup paths were competing for resources while delivering too little distinct value.
7.3 GiB RAM VM4 GiB swap~1,000 tasks at peak3 agents retiredConsolidation, not failure
The short version
This was not a universal verdict on any of the three projects. Each agent taught me something and proved useful during experimentation. But a lab is still a production system when I depend on it every day. Once the fleet grew to nine agents, the cost of keeping every experiment alive exceeded the value of the overlap.
More agents did not create more capability in a straight line. Past a certain point, they created duplicated infrastructure, resource contention, extra attack surface, and more things to repair.
I chose consolidation: keep a smaller core around Hermes, OpenClaw, 9Router, GBrain, and on-demand coding workers; retire the stacks that had become redundant.
~81% CPU
Ouroboros was the catalyst
One point-in-time investigation showed Ouroboros consuming approximately 81% sustained CPU. Across its main and child processes, it also accounted for roughly 881 MiB of swap.
That reading was a snapshot, not a claim that every workload always behaved identically. It was still severe enough to trigger the investigation.
~526 MiB RSS
OpenCode multiplied the stack
OpenCode showed roughly 526 MiB RSS in one snapshot, before fully accounting for its supporting server and Telegram processes. Its footprint was not only memory: it brought overlapping CLI/server modes, bot state, SQLite maintenance, watchdogs, restart logic, and backups.
4 GiB full
Swap stopped being a safety net
The VM had 7.3 GiB of RAM and 4 GiB of swap. Swap was full during the worst period. At that point, small bursts—builds, agent turns, indexing, or service restarts—had to fight a system already under memory pressure.
~1,000 tasks
The fleet became the workload
The machine approached roughly 1,000 processes/tasks, with periodic memory pressure and severe CPU saturation. The infrastructure intended to help me do work was increasingly becoming the work.
What each retirement solved
| Agent | What it contributed | Why it left this VM |
|---|
| Ouroboros | An ambitious self-creating agent experiment with its own server, companion processes, Telegram integration, and startup path. | Its sustained CPU use was the immediate performance catalyst, and its capability overlapped with the remaining orchestration and automation stack. |
| OpenCode | A capable coding-agent environment with CLI, headless server, Telegram access, provider routing, GBrain integration, and session state. | The resident CLI/server/bot footprint, SQLite upkeep, restarts, watchdogs, and backups duplicated coding capabilities already available elsewhere. |
| Pi Coding Agent | A lightweight, flexible coding CLI with provider configuration, extensions, Telegram access, and a GBrain bridge. | Pi was not the single runaway process. Its cost was duplicated infrastructure: another gateway, configuration surface, credential set, update path, integration, and backup plan. |
The user-visible problems
The graphs and process snapshots matched what I felt while using the lab:
- Telegram responses could feel slower or less predictable.
- Load average rose and bursts of CPU-heavy work had less headroom.
- Builds competed with always-on agent runtimes.
- Full swap made the system less responsive under pressure.
- More services meant more potential failures, restart paths, and stale state.
- Routine maintenance required reasoning about too many nearly equivalent components.
The key lesson was not “never self-host agents.” It was “do not confuse installed capability with operational value.”
Security mattered too
Every additional agent added some combination of bot tokens, API credentials, local databases, session histories, network listeners, dependencies, update mechanisms, startup hooks, and automation. Even if each component was individually reasonable, their combined attack surface and audit burden were not free.
Maintenance had a compound cost
Nine overlapping agents meant repeated provider maps, Telegram polling, model fallbacks, backups, health checks, restore procedures, and documentation. A “small” integration repeated across several agents becomes a platform that needs an operator.
Backup first, delete second
I did not treat retirement as rm -rf. Before removing anything, I created complete restorable backups to two destinations:
- SMB/NAS: filesystem-preserving archives for local recovery.
- Private GitHub repositories: complete encrypted archives, including secret-bearing state.
- Recovery keys outside GitHub: so the encrypted copies were not self-defeating.
- Verification: remote commits, checksums, archive integrity, and test decryption were checked before deletion.
Only then did I remove agent-specific services, startup entries, cron jobs, Telegram integrations, binaries, configuration, monitoring records, backup automation, and redundant staging files—while preserving shared dependencies such as GBrain and 9Router.
What improved after consolidation
The result was not a flashy benchmark victory; it was operational breathing room. The VM had fewer resident processes, less contention, less swapping pressure, fewer service failures to investigate, and a simpler mental model. Telegram interactions, builds, and normal administration had more headroom because three always-on stacks were no longer competing for the same two-core-class VM resources.
I am deliberately separating measured before-state snapshots from observed after-state experience. The exact CPU and memory figures above are point-in-time evidence. The post-retirement gain is best understood as removal of persistent contention and complexity—not a promise that every command became a specific percentage faster.
My new rule for agent fleets
- Keep a small, clearly owned control plane running continuously.
- Launch specialized coding workers on demand instead of keeping every CLI resident.
- Require each new agent to provide a distinct capability, not a different wrapper around the same model.
- Budget credentials, backups, monitoring, and recovery as real operational costs.
- Measure idle CPU, resident memory, swap, process count, and failure rate before expanding.
- Archive experiments cleanly when their learning value has been captured.
The three agents were not “failures.” The experiment succeeded because it revealed where variety stopped helping and consolidation started winning.
Final takeaway
I like experimenting with AI agents, and I will keep doing it. But I no longer believe every successful experiment deserves permanent residency. Ouroboros, OpenCode, and Pi Coding Agent all had strengths. In this specific lab, on this specific VM, their combined resource usage and operational overlap outweighed their marginal value.
The honest conclusion: fewer agents made the system more useful. Consolidation restored performance, reduced attack surface, simplified recovery, and gave the remaining tools room to work.
Editorial note: this is an environment-specific operations decision, not a universal recommendation or negative review of the projects named above.