How I run an autonomous forge on a home fleet
An autonomous homelab inhabitant that lives directly on bare-metal Linux, executes tasks with instant Btrfs rollback, and conducts continuous performance research during idle hours — all on open-weight models served from local hardware.
What I build
The chat interface is the least interesting part. We migrated away from reactive "Jira-ticket AI" into an active forge: the agent lives on a dedicated host to build and test system tooling, audit the fleet, and optimize performance kernels.
Most of what I've built is the safety net and the feedback loop, not the agent itself. It owns the declarative configs, local maintenance tooling, and benchmark test suites, each paired with offline, hardware-free tests.
How I work
Everything is declarative and version-controlled in git: Podman quadlets for the Linux hosts, launchd units for the Macs, and Compose stacks for the rack server. A rebuilt host is a bootstrap script and one deploy command.
Work is organized around a task queue on a self-hosted code host (OneDev). Issues transition Proposed → Approved → In Progress → Review → Done. Moving into Approved is the explicit operator checkpoint for maintenance and system changes.
The rollback architecture. Earlier iterations relied on isolated containers and a pre-execution gate that tried to predict if an edit was safe. That was slow and brittle. The agent runs directly on bare-metal Linux with pure Btrfs. Before applying any tool or system change, it takes a zero-cost pre-execution snapshot. It executes, runs an automated verification command, and self-heals with the model if a script fails. If verification still fails, an automated rollback reverts the host root filesystem to a pristine state in seconds. Zero lingering changes, no mock environments.
Forge Patrol. When the queue is quiet, the agent audits itself and the fleet. It checks for snapshot accumulation, purges orphaned pre-snapshots, queries Prometheus metrics across all nodes, and automatically files incident tickets with reproducible triage data if hardware anomalies appear.
Agents & harnesses
The core service runs as a container on the forge host with host namespace access.
- Autonomous execution: The model synthesizes implementation scripts and verification checks. It doesn't guess about filesystem state; it inspects, executes, and verifies against host reality.
- Dialectic memory (Honcho): Stateless prompt budgets don't scale. The agent connects to a self-hosted Honcho instance with local vector embeddings. Before drafting a plan, it queries past hypotheses, failure modes, and code patterns from memory. After execution, it records the complete session, diff, and outcome so lessons persist.
- Operator loop: I triage and approve tasks through Claude Code/Antigravity or the local code host interface. Approved tickets are claimed automatically on the next polling cycle.
Autonomous Forge Lab
When the task queue is empty and snapshot headroom is clear, the agent doesn't sit idle. It transitions into autonomous research iterations across isolated performance kernels and data-processing challenges.
It queries local models for optimization hypotheses, mutates candidate implementations, and benchmarks them against test suites measuring throughput, latency, and memory. When a candidate beats the active leaderboard champion without breaking correctness, it is promoted and committed to git. Performance metrics stream directly to Prometheus and Grafana dashboards.
Hardware telemetry & printing
A thermal receipt printer is wired directly to the forge host.
We moved from printing daily digest receipts to an incident-only policy. Routine receipts produce clutter; physical paper is reserved for fleet incidents, hardware faults, and triage alerts where physical visibility matters. Non-blocking I/O and hardware status checks ensure an out-of-paper or disconnected printer never blocks the software forge loop.
Models
All model traffic routes through a unified LiteLLM gateway on the rack server. Models are addressed by functional roles with automated fallback chains across sibling nodes:
| Role | Model | Engine |
|---|---|---|
| Chat & Toolmaker | Qwen3.8-27B | llama.cpp (speculative decoding) |
| Heavy Reasoning | Nemotron 3.5 Lightning 30B-A3B | vLLM |
| Long Context | Qwen3.6-35B-A3B | MLX |
| Backup Worker | Qwen3.6-35B-A3B (same weights as long context) | MLX |
| Memory Embeddings | bge-large | text-embeddings-inference |
| Speech to text | faster-whisper large-v3 | speaches |
| Text to speech | Kokoro-82M v1.0 | Kokoro-FastAPI |
| Images | FLUX.1-dev | LocalAI |
Identical weights on fallback machines ensure that a failover changes latency, not behavioral expectations.
Terminal
Ghostty.
Machines
By role: a bare-metal agent node (small headless PC on Btrfs with receipt printer); a dual-3090 inference box; a GB10 reasoning box; an M4 Max Mac Studio; an M2 Max MacBook Pro, racked and never moved; a single-3090 media and speech box; a rack server for the gateway, task queue, memory, and observability (Grafana stack); and a NAS. All of it grew inside an existing homelab.
Both 3090 cards are power-capped after one fell off the bus mid-inference, and every GPU host now logs power, temperature, and throttling.
Moved on from
- Hermes (reactive Jira-ticket agent) → Talos (autonomous bare-metal forge inhabitant). Chatting about tasks was replaced by an autonomous loop that builds, tests, and maintains itself.
- Containerized OpenCode & rigid pre-execution gates → Bare-metal execution with instant Btrfs rollback. Instead of trying to constrain what an agent can touch beforehand, we let it run on real bare metal and revert the entire OS in seconds if verification fails.
- Daily digest paper receipts → Incident-only thermal printing. Paper is now reserved for physical alerts and fleet incidents rather than routine status spam.
- Stateless prompt budgets → Dialectic memory in Honcho. Real task traces, hypotheses, and execution diffs are indexed into local vector storage for persistent retrieval.
- Idle downtime → Autonomous Forge Lab. When no human tasks are queued, compute is directed toward continuous benchmark-driven code optimization.