What I built, and what I actually use it for

• A$1,524April upgrade for five office PCs

Over the past year I have ended up with a small pile of computers at home that can run AI models, most of them bought for something else first. The local-AI setup is built, it works, and I have benchmarked it. It is not yet doing much of my actual work, and I would rather say so at the start than let the hardware list imply otherwise. Here is the inventory, what runs on it today, and what is defined but sitting idle.

The machines, by role

There are three kinds of machine.

The first is six refurbished office PCs, A$239 to A$259 each, in December 2025. Five do compute; the sixth, a different model delivered by mistake, has another job. In April I upgraded the five. The upgrade, A$1,524 for memory and three faster drives, took each of them to 32 GB of RAM. Most of them have other jobs first, and running AI models is something they do on the side.

The second is a mini PC with a Core Ultra 9 and 32 GB of DDR5, which arrived in April 2026. Its Intel chip also carries a graphics unit and a neural processing unit (NPU, a block of silicon meant to accelerate AI work).

The third is a desktop built from parts bought in September 2025, with a 16 GB Radeon RX 9060 XT graphics card. It is the only machine here with a card that can run a mid-sized model quickly, and it is also my gaming machine. On that card I measured one 20-billion-parameter model at 61.3 tokens a second in June 2026, fast enough to read as it types. While I am playing something, though, the card is not available for anything else. That is a real limit, and it shapes the setup below.

None of this was bought as a dedicated AI cluster.

What actually runs today

Three things run, and all of them are small.

The first is a router: a piece of software, LiteLLM, that sits in front of the models and presents them as one address on the home network. Requests go to the desktop’s graphics card, because it is the fast one. When the desktop is off or busy with a game, the router falls back to one of the office PCs, which is slower but always on. It has been running since the end of June 2026.

The second is a chat front end: a web page where I can type to a model and, if I want, point it at my own documents.

The third is the first real user of the router. On 1 July 2026 the browser’s built-in assistant was pointed at it, so a question typed into the browser is answered by a model on the home network. That is the nearest thing I have to evidence that the setup works as a dependable service rather than something I only poke at with a test command.

I want to be careful about what that evidence is. It shows the router answers when asked. It does not show that I rely on it. The files I keep record no request counts or usage figures, so I cannot tell you how often it is used.

What is defined but unused

A hardware list tends to leave this part out.

Home Assistant, the home-automation system that runs the house, has a call defined that sends a question to a model and reads the answer back. It was defined and confirmed working in March. No automation uses it. The automation tool, which chains steps together into workflows, is installed, and I have not built a workflow in it yet. The mini PC’s graphics unit and NPU are in the same position: the drivers are installed, and neither runs a model for me.

So the picture is three things running (the router, the chat front end and the browser assistant) and three things defined but unused (the Home Assistant call, the automation workflows and the mini PC’s extra AI silicon).

Most of my AI work is still done by a cloud assistant. The router has a route to a cloud model defined, but it is switched off: local models are opt-in, and the cloud is the default for everything else I do.

The one reliability event on file

There is exactly one recorded failure touching the AI services, and it is a useful one. On 17 April 2026 a full disk on the services machine took the chat front end, the workflow tool and the photo service down together.

What filled it is a story for another day; the pattern is the useful part. Unrelated services failed at once, those three among them, because they shared one disk. If services share a disk, they share a fate. At the time there was no disk-usage alert, which is the cheap thing that would have turned an outage into a warning.

Two gotchas worth your time

The first: Ubuntu Server’s installer, with its default disk layout, gives the root volume only about 100 GB, whatever the disk size. The root volume is the part of the disk the operating system lives on. On the services machine about 900 GB sat unallocated until I extended the volume by hand. The fix is two commands, sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv then sudo resize2fs /dev/ubuntu-vg/ubuntu-lv, and it is worth running them first, before anything is installed.

The second: never pip install openai-whisper on a machine without an NVIDIA card. Whisper is the speech-to-text model; pip is Python’s package installer. On a CPU-only machine, the pip version pulls in about 2.5 GB of NVIDIA libraries that cannot be used, and puts its command somewhere that is not on your path. Build whisper.cpp from source instead, a plain C++ port with none of that baggage.

Where this stands

What I have not done is the test that would show whether a local model does useful work on the writing I publish. That is the next step: run it on real blog jobs, and write up what happened once it has run. I am not going to name the jobs, the model or a date here, because I would rather report a result than a promise.