Midnight-PC

01 Why the machine is the project

A workstation you fully control is a different thing from a computer you use. Once you own the boot chain, the session, the services and the network path, every problem becomes yours to diagnose — and there's nowhere to hand it off to.

That's the appeal. It also means the failures are real: a boot that came up with no login screen because the default systemd target was set to multi-user instead of graphical, a local model that took the desktop down with it, a bootloader change that could have left nothing to boot into. Each of those taught me something specific about how the system actually fits together, which is the part I couldn't have got from a tutorial.

I use AI assistants heavily to build things on this machine, and I'd rather say so plainly than imply otherwise. What's mine is deciding what to build, working out why something is broken, and checking that a fix actually holds.

02 How it fits together

The workstation is the platform. Things live on it, and things get built on it — those are two different relationships, and the diagram keeps them separate. Access arrives from a private direction rather than from the open internet, which is deliberate.

03 The stack

Grouped by what each part is for, rather than listed for its own sake.

04 Things that broke

Three real ones, and what changed afterwards.

• The model that took the desktop down with it The 8B model I run locally is a weak agent — it fumbles tool calls and loses track of its own memory. The obvious fix was a 14B at the same 64K context. It didn't fit. Once the KV cache was accounted for, the model exceeded the card's 16 GB of VRAM, and because that memory is also serving the desktop, exhausting it didn't fail quietly — it took the display with it. What changed: the 8B went back to being the standing default, with a quantised KV cache and a short idle unload so VRAM is released instead of held. Heavy local inference no longer runs alongside anything else contending for the GPU. And the wider policy became explicit rather than accidental — a cheap local model for bulk work, with hosted API models reserved for the work the local one can't do reliably. The ceiling is real, so it's documented instead of rediscovered.
• Making bootloader changes survivable This machine boots GRUB chainloading a unified kernel image. It's an arrangement that works well and fails badly: a careless edit, or a regeneration that quietly invalidates the entry, leaves you with a machine that won't boot — and you can't fix it from inside the OS you can no longer reach. What changed: boot changes now go through a scripted process that verifies the resulting boot entry still points at the intended image before the change is treated as accepted, with a filesystem snapshot taken first. That turned the riskiest part of the system into something I can iterate on. It's the same instinct behind Kairo's handling of launcher files — preserve the original, verify the replacement, keep a way back.
• Monitoring that stays quiet Monitoring that alerts constantly gets muted, and muted monitoring is worse than none. The design question wasn't what to watch — it was what the system is allowed to do on its own versus what needs me. What changed: scheduled health checks with exactly one automatic remediation — restarting the audio stack, which is bounded and safe to retry. Everything else raises a notification and waits for a human decision. Credentials for the alert path live outside the repository. The result is a small number of alerts that still mean something when they arrive.

05 Working with AI here

I use two coding assistants on this machine — Claude Code and Codex — and each one started every session knowing nothing about the project in front of it. In practice that meant re-explaining the same conventions and the same current state, repeatedly, to whichever tool I'd opened.

The fix was small and has two halves. Each project carries a written guide that both assistants read, so conventions are recorded once instead of re-typed — with a second filename symlinked to the first, because the tools look for different names. Alongside that, a small local service both assistants can query gives them the same two read-only answers: what this project is, and what has changed in Git recently.

What this is not: a sandbox, or shared autonomous memory between the assistants. Nothing here grants them extra reach, and they don't carry state between sessions. It's a shared, normalised source of evidence and one common interface, so two different tools start from the same facts instead of from whatever I remembered to paste. The benefit is mundane and worth it — less time re-establishing context, and less drift between tools working on the same codebase.

06 Built here, runs here

07 Operating principles

• Cheap by default, escalate on purpose A local model handles bulk work. Paid API models are for the work that genuinely needs them, not the default path.
• A human decides anything with consequences Automation gets a narrow, bounded remit. Everything outside it raises a notification rather than acting.
• Prefer reversible and read-only Verify before committing, snapshot before touching anything structural, and keep a route back from every change.
• Write it down while it's fresh Fixes that aren't documented get rediscovered the hard way. The machine keeps its own runbooks for that reason.

08 Status

This page describes how the machine is set up and why, not how to reach it. Addresses, ports and credentials are deliberately left out.