cipherfox

Who is cipherfox?

I'm an AI beginner turned infrastructure tinkerer. Not a researcher. Not a machine learning engineer. Early adopter by temperament: I was on Nostr before it had a mobile app, running AI tools before they had reliable UIs. The conviction driving this is straightforward. AI is as disruptive as anything I've seen, and the window to understand it from the inside closes faster than most people expect. Curiosity and the willingness to go through thick and thin, even when it gets tedious, are what got me here and what keep me going.

My background is in using AI, not building it. A year ago I couldn't have told you what a CUDA kernel was. Today I'm debugging vLLM and SGLang internals, patching opencode and OpenClaw setups, and running a 35-billion-parameter MoE on a box that sits on my desk.

That's the journey this blog documents: from zero to sovereign, one broken config at a time. I'm not at the end of it. Honestly, I'm not certain I'll get there. The complexity keeps growing faster than I can tame it. But I'm writing it down as I go, and the learning has been worth the frustration.

Why self-host?

It started with a 4 AM panic. A cloud API bill had doubled overnight. My AI assistant was offline because a provider rotated keys without warning. My private project notes were sitting on someone else's server.

That was the last month I paid for cloud AI.

The panic was the trigger. The real reason runs deeper. I've been an early adopter long enough to recognize when something is about to change everything. The pattern is always the same: spot something disruptive early, build familiarity while the internals are still visible, before the abstraction layer hides them. Self-hosting keeps that window open. No service dependency between me and understanding why something works.

Sovereign AI isn't a political stance. It's an engineering decision. When you build with AI every day, you generate sensitive context: architecture notes, half-finished code, system configs. Keeping that on your own hardware isn't exotic. It's just obvious once you've thought about it for five minutes.

The privacy angle is a side effect of the reliability angle. Both matter.

The build: what I run, how Claude and the local model split the workload, how the pipeline gets a post live

Three pages cover the build, each with a different scope. This section is the pointer to all three so /about/ stays focused on the operator.

• What I actually run: the dated inventory of hardware, primary and fallback inference, image generation, TTS, agents and clients, storage, publishing, and the public edge. Single source of truth for the variable parts.
• Cloud vs local, where each wins: the 13-task capability matrix between cloud Claude and the self-hosted GB10 stack, the decision rule that fell out of running both daily, and the tasks Claude cannot do at all. Cloud vs Local AI: Where Each Actually Wins in 2026.
• How this blog actually gets built: the full mechanism behind sovgrid.org, with six months of dated milestones, the AGENTS.md / VIBE.md / BRIEFING.md context-file pattern, the two quality gates, the stylometric anti-AI-detection layer, and the 32-article scaling test. How This Blog Actually Gets Built.

For the broader site context (philosophy, V4V framing, support channels), see /philosophy/, /value/, and /support/.

Bugs go upstream, not into a private patches folder

Every fix that ships here started as a bug somewhere upstream. The honest move is to send the fix back, not to hoard a private patches folder that nobody else benefits from. So far the contributions live mostly as bug reports plus a few PRs, with the diagnosis on the blog and the actual change-request on GitHub. The pattern is: hit the bug while running the stack, write the diagnosis up here for the operator value, file the upstream issue or PR with the same write-up linked for the engineering value, mark the article with the resulting tracker number when it lands.

Two reasons this is worth doing deliberately. First, an engineering log that documents bugs without ever fixing them upstream is just a graveyard of workarounds, the next operator hits the same bug and burns the same hours. Second, a fix that lands upstream removes the local maintenance burden, no more re-applying a private patch after every dependency upgrade, no more divergence to track, no more silent regressions when something else changes underneath.

The full list of contributions, with status (open / merged / closed) and links to both the GitHub item and the blog post that documents the diagnosis: /upstream/. The same identity that owns the contributions: github.com/cipherfoxie.

Why sovgrid.org?

The name comes from Sovereign AI Grid, the wider project this blog is part of. A network of self-hosted AI services, knowledge tools, and infrastructure built to work without cloud APIs or third-party accounts.

.org was the deliberate choice. archlinux.org, yunohost.org, nextcloud.org, the entire self-hosting tradition lives there. This blog is a mission, not a business front, and the TLD should reflect that.

Hosted with Flokinet ^↗, paid in bitcoin, no KYC. Domain registered with the same provider, WHOIS privacy enabled by default.

Support

Direct channels (Lightning, Nostr Zap, forthcoming book) and referrals (Alby, BitBox02, Flokinet) live on /support/. For the value-for-value framing behind why any of this is optional, see /value/.