Four nodes, five old GPUs, and an AI with root.

The heart of the cluster is a custom-built tower: a 16-core Ryzen 9 with 64 GB of RAM and a SAS host bus adapter feeding six spinning disks to the storage server. Around it sit three retired office desktops that were headed for recycling. Each one became a Proxmox node; two of them carry a pair of workstation GPUs each.

Proxmox is free software that lets one physical computer host many independent virtual machines and lightweight containers. If one node needs maintenance, the others keep going, and every guest can be snapshotted before a change and rolled back if the change goes wrong.

Everything is managed from one laptop: a ThinkPad T14 (8-core Ryzen 7 PRO, 14 GB) running Omarchy, an opinionated Arch Linux desktop built on the Hyprland tiling window manager. It drives a 3 × 2 wall of six screens through two DisplayLink docks. Proxmox, dashboards, and the wiki live on the big monitors; terminals and the AI assistant sit on the laptop panel in the middle. The laptop is swapped daily with a work machine, so the docks, not the laptop, own the monitors.

The NAS is a TrueNAS virtual machine on node 1. Its disks are passed through individually from the host, so the VM owns them but the host still reads their SMART health. The main pool is RAIDZ1 across five 2 TB enterprise SAS drives, all manufactured in early 2012, now between 45,000 and 59,000 power-on hours. That is five to seven years of continuous spinning, each.

They are watched closely. The first-ever long SMART self-tests on the array ran in October 2026 and came back clean, but one drive had been growing defects and was the weakest member. A spare 4 TB NetApp-branded SAS drive from 2023 was reformatted from 520-byte to 512-byte sectors, hot-plugged into the VM, and swapped in for the failing drive with the pool live. The resilver moved 6.5 TB in about six hours at roughly 200 MB/s with zero errors. The pool stays at 2 TB per member until all five are 4 TB, so the capacity gain comes later.

A second single-disk pool holds a 1 TB desktop drive for scratch. Nothing is offsite yet, which is the honest weak spot and the top of the roadmap.

Satellite in, nothing out

Internet arrives by satellite, behind carrier-grade NAT, through a small OpenWrt-based consumer router. Midday it does about 175–215 Mbit down; evenings can sag to 15–45. Upload is the real constraint at 10–14 Mbit, so the router shapes upload with cake (diffserv8, auto-rate between 10 and 16 Mbit) and marks traffic in five tiers: laptops first, phones, then the cluster, then everything else, with the media stack at the bottom as bulk. Shaping download turned out to make things worse on this link, so download is controlled at the application layer instead: 1.5 MB/s during the day, unlimited overnight.

There are no port forwards, and under CGNAT there couldn't be anyway. The handful of things that must be reachable from outside, like an upload endpoint for a hobby site and a web-analytics collector, come in through an outbound tunnel to a CDN: a small container dials out, and traffic rides back down it. The public websites themselves are static files served from the CDN's edge, so the cluster being off never takes a public site down.

Remote access

Administration from outside the house goes over a mesh VPN with the router acting as a subnet router. Family members streaming from another house use the same mesh, but their devices are tagged so the VPN's access policy lets them reach exactly one port on one host: the media server, and nothing else.

Local language model

Node 3's two M2000s (8 GB VRAM combined, compute capability 5.2) run Ollama with Qwen3 8B split across both cards at about 7 tokens per second, and Qwen3 4B on a single card at about 11. Context is capped at 8k tokens; 16k runs out of memory. Maxwell is too old for most modern inference engines, so it is llama.cpp and GGUF only, no vLLM. That is enough for the jobs it has: parsing incoming email into structured data, summarising meetings, and smoke tests for workflows.

Speech-to-text

Node 4 runs whisper.cpp built from source for sm_52 with CUDA 12.8 (a 32-minute compile on a 4-core desktop) using the medium model quantised to 5 bits, at five to seven times real time. The obvious choice, faster-whisper, was a dead end: its CTranslate2 backend ships no Maxwell kernels and refuses int8 on the card. A prebuilt Docker image was 30 GB and also failed. Build it yourself, it turns out.

Meeting recorder

One hotkey on the laptop starts a 16 kHz mono recording. Pressing it again sends the audio to the cluster's whisper service (with a local fallback), chunks the transcript through the local Qwen3 model, and writes a Markdown note with a summary, decisions, actions, and open questions. A 40-minute meeting takes about 5.5 minutes to transcribe and 10 to summarise. After two runaway overnight recordings, it now stops itself at 75 minutes.

Vision in the loop

For a hobby site, photos of small collectible items taken on a phone are uploaded through the tunnel. OpenCV finds every item in the photo and matches fronts to backs by grid cell. Each one then goes to a cloud vision model to be identified, with a cheaper model first and a stronger one only when the first is unsure. Prices are fetched, draft entries are written, and a human approves the batch from a chat command. The first batch was 66 items from a handful of photos.

Everything on this page was built, repaired, or rebuilt by Claude, an AI assistant from Anthropic, working through its command-line tool on the admin laptop. The human brings the ideas, the hardware, the logins, and the decisions. The AI reads the state of the cluster over SSH, proposes a plan, and once approved does the work: writes the scripts and configs, runs them, checks the result, and documents it in the wiki.

It is not unsupervised. The whole arrangement rests on a short set of written rules the assistant reads at the start of every session.

• Snapshot before any package or config surgery, and name the snapshot so it is obvious what it was for.
• Verify with evidence: read the live state back, never trust a config file to mean the service is doing it.
• Root on the servers, never sudo on the human's own laptop. That password stays with the human.
• Secrets come from the password store by name. Never ask the human to paste one into chat.
• Check the notes before re-diagnosing. Memory files carry what was learned last time.
• Document every change in the runbook wiki, and leave a one-line pointer in the task list.
• Anything outward-facing, destructive, or that costs money gets a yes from the human first.
• Report honestly: if a test failed, say so with the output. If a step was skipped, say that.

How much work is that?

AI models read and write text in small pieces called tokens, roughly three-quarters of a word each. The figures below come from the assistant's own session logs on the laptop. The read number is much larger than the written one because at every step the assistant rereads the running conversation, its notes, and the files it is working on.