I trained Claude Code on my home server logs, and now it understands my infrastructure better than I do

Published Aug 30, 2026, 6:00 AM EDT Maker, meme-r, and unabashed geek, Joe has been writing about technology since starting his career in 2018 at KnowTechie. He's covered everything from Apple to apps and crowdfunding and loves getting to the bottom of complicated topics. In that time, he's also written for SlashGear and numerous corporate clients before finding his home at XDA in the spring of 2023. He was the kid who took apart every toy to see how it worked, even if it didn't exactly go back together afterward. That's given him a solid background for explaining how complex systems work together, and he promises he's gotten better at the putting things back together stage since then. I love my Proxmox nodes, and they're indispensable parts of my home lab. But each of them writes a journal I have never read and am unlikely to read anytime soon. It's just too much data. Two weeks' worth is thousands of lines of systemd, cron sessions, or timers, with a handful of useful pieces of information buried under the weight of noise. So, I "trained" Claude Code on it, and like when Claude helped clean up my Windows install, now I can make sense of the clutter. I use "trained" in the loosest possible manner here, because let's face it, no model fine-tuning went on. I didn't even run the model on my GPU. What I did create was a lot of regex and a rubric to test the results with, and now Claude Code knows more about my nodes than I do. And the things it found have been fixed. Home lab admins have a reading problem Nobody reads the logs for fun Let's face it, the hard part of running a home lab isn't fixing things. It's noticing that something needs fixing. Proxmox, Home Assistant, the NAS, the DNS containers, they all log constantly, and 98% of it is noise you have to wade through to find the 2% that matters. I have monitoring. I have email alerts. I still had a container failing to start on every single boot for longer than I can remember and didn't know. That's the job an LLM is weirdly good at. Not the clever stuff. The reading. It will happily consume 60,000 lines of pvesr.service timer spam and tell you the three lines that weren't spam, and it will do it for less than a dollar. "Training" is a convenient falsehood about context engineering Sure, everyone says they trained an AI on their logs, but what they mean is they gave it context. There are two honest ways to do that, and they fail in opposite directions. The first is pre-digesting: a deterministic Python script boils the journal, the task index, and the guest configs down to six small markdown files (inventory, backups, incidents, activity, timeline, and noise) that Claude Code reads through a CLAUDE.md. No LLM is involved in making the digest, so it only knows what I told it to look for. The second is live access: hand Claude Code the raw log bundle plus two query tools shaped like journalctl and pvesh, and let it investigate per question. It can find anything, as long as its tools can see it. I built both, asked each the same questions in fresh sessions, and graded the answers by hand. Guess which one lied to me first. Claude is a suite of LLMs and tools from Anthropic. I proved the process on fake logs before touching my Proxmox server The proof of the pudding isn't always in the eating The problem with letting Claude Code loose in my server logs wasn't the level of access; it was that I didn't know what was in my real logs. So the first round was to simulate some, as a training exercise. I asked Claude Code to keep the same architecture as my nodes, real VMIDs, guest names, IPs, and ZFS pools, and generate a couple of weeks of log data. Things like a Home Assistant VM timing out on its backup process three nights in a row, a Pocket ID container in an out-of-memory loop at 3am, and an NVMe hitting 78C during a Steam Headless session. I also added a couple of stumbling blocks to see what the model would do. One was about an IP address that nothing in my home uses, and another asked about a keepalived failover that only exists inside my two DNS containers, so it wouldn't appear in the host journal at all. If a model answers those confidently, it's going to be making up things about infrastructure that does exist, and I wanted to be sure. Running the synthetic data was instructional The created log files included almost 64,000 journal lines, which was 98.7% of a per-minute replication timer. I tested that dataset two ways: once with a digester program that Claude Code created to trim junk lines, and once by feeding the full logs to Claude. The digester code Claude built trimmed it down to 21.5 KB, a 273-to-one shrink before any model touched the data. Then each approach was asked the same 12 prompts through Sonnet 5, with a fresh session for each of the 12 questions, so it couldn't lean on prior context. The first run of each got ten of them correct, and they refused the two trap questions, which was good to see. Not to say there weren't any issues. The digester was asked why the node rebooted and answered: "not in the digest." That's a correct refusal, but it showed me that I was missing a rule to look for apt: Installing lines. That was an easy fix in the code, and then it was on to fixing a problem the live run created. When asked about not receiving failure emails, it ran a grep, got zero results, and concluded that, because no results came back, the box didn't have a mail recipient configured. The actual issue was postfix deferring mail on a refused connection to port 25 — something the grep wasn't set up to look for, but it is now. What the actual data from my Proxmox server taught me Real logs are quieter, but worse, somehow Once the tooling was working, I pulled 15 days of journaling through the Proxmox API, in one-day chunks. I also grabbed the task index, 13 guest configs, storage, and ZFS state. The real logs were nearly a tenth the size of the synthetic ones, because they didn't have the per-minute replication timer lines. The first run through the digest tool showed me three regex false positives, which also needed some tweaks before the next stage. Claude found four things I didn't know about my own server Now for the good stuff. Claude Code found a template that failed every time it tried to boot because it's a template, and it wasn't supposed to be set to boot when Proxmox starts. I cloned it with onboot: 1 enabled, and nothing told me to change it. I had a backup job configured at one point, but the logs say that none of the 41 tasks in the index were about backups, and now I've added a backup process. I had two weeks' worth of bounced emails because every failure tried to email me, but was bounced by Google's SMTP server, as I have a residential IP with no relay set up. Really, this is two years of bounced emails. I only pulled two weeks of logs. And one other thing, my Realtek NIC flapped on August 21, causing a NOT CLEAN boot. Nothing to fix, but it's good to know what happened. Claude Code now knows my server better than I do, and I won't let it touch it unsupervised Claude has read more of my server logs in one night than I have in two years, and that's unlikely to change any time soon. My admin posture is to build in resiliency from the start, so the number of possible failures is smaller. Any log reading only ever happens after something breaks — or, I should say, after something breaks and I notice because my logs showed that some things were being quiet about it. Every broken thing in the logs was something I misconfigured. Claude did the reading for me, so I could get on with fixing the issues.