Python

The council worked. One request went to Claude, Codex and Kimi, they answered independently, and nothing touched the lab without a human approval bound to a hash of the exact plan. It also lived entirely in a terminal, which meant that to approve a run I had to type a run id like hc-20260822-6fbfa5 and then re-type the original 350-character request verbatim, because resume rebuilds the context pack from it. Get one character wrong and you have quietly changed the inputs the agents were judged on. ...

I have three coding agents with access to this lab. Claude Code does most of the building. Codex reviews and runs the scans. Kimi audits. Until this week they had never exchanged a word — each got its own context, its own session, and its own chance to be confidently wrong with nobody checking. So I built a thing that makes them work one request together, and put a human approval gate in front of anything that changes the lab. ...

I’m not a programmer, and I’m not trying to be one. But the development of new AI models has let me learn concepts that were once too complicated for me to get on my own. As you know, I use Linux a lot — but I still wanted to properly upskill in the command line. So instead of just following a document and re-typing commands in another terminal window, I thought: why not get Claude to build me an interactive game — a Linux CLI practice terminal — that actually lets me learn and memorise the commands? ...

I run Claude Code on two machines: the Debian VM in my home lab (always on) and a Debian laptop (sleeps, roams, follows me to campus). I wanted the laptop to push notes, facts, and findings into a central store on the VM — from any network — so the home-lab agent could pick them up later. Claude Code’s built-in Remote Control turns a second device into a remote window onto one session. That’s not what I wanted. I wanted both machines to stay fully independent agents, linked through a shared tool. So I built a small MCP server on the VM and pointed the laptop’s Claude Code at it: the hub becomes just another tool the laptop can call. ...

In part 1 I got a LaMetric Time showing live health from my home lab over MQTT, so it worked across my network isolation — CPU, memory, disk, uptime, and the automation VM’s own traffic, all from a single Debian box. Useful, but those were really that box’s stats. The frame the display was named for is my network’s throughput — the traffic crossing my firewall — and that data lives on pfSense, not the Debian box. This is the follow-up: pulling real WAN in/out rates off pfSense over SNMP and putting them on the display. It’s shorter than the MQTT build, because the pipeline already exists; all I’m adding is a new data source. Getting numbers out of pfSense is the part worth writing down. ...

I picked up a LaMetric Time — an 8x37 pixel smart display — and after locking it down on an isolated guest network, the next move was to make it useful: live health from my home lab. CPU, memory, network throughput — the numbers worth a glance. The interesting part is that a constraint I’d deliberately built into my network dictated the whole architecture. This is the write-up: the design decision, the pipeline, and the gotchas — because the gotchas are the useful part. ...

I wanted a small desktop tool that captures a snapshot of a machine — hardware, resource usage, network state — and writes it to a styled HTML report viewable in any browser. Useful for quick system audits and for keeping a record of a machine’s specs over time. I built it in one Claude Code session (Opus 4.8) on my Debian 13 laptop, then packaged it for Windows as well. ...