My AI setup

This setup didn’t come together in one pass. It took a lot of iterations, research, installing tools, and experimentation to get to something I actually want to keep using. What I ended up with is a deliberate split: an always-on self-hosted control plane doing access and memory, and cloud inference doing the thinking.

The box

The core of the setup is a Beelink SER8 mini PC with an AMD Ryzen 7 8845HS. It’s always on, and I can reach it from anywhere: my phone, a laptop, or an AWS CloudShell session. If I need to bring a service up, restart something, or run a command, I ssh in. It has no discrete GPU, so it isn’t the brain. It’s the head.

Inference

All the actual thinking happens in the cloud. Ollama Cloud at $20 a month runs GLM-5.2 for coding, and I switch to MiniMax M3, DeepSeek V4 Pro, and a few others for other tasks. I keep Kimi K3 from Moonshot around as a paid API swap. Claude Code at $100 a month handles the rest: Fable 5 for planning, Opus 5 for heavy work.

Why not local? The box isn’t strong enough, and even if it were, it couldn’t match the performance of a cloud provider running on real GPUs. I take performance over privacy here. My code goes out to a provider either way, and the speed and quality of cloud models are worth it.

Memory

The one model that runs on the box is an embeddings model. It backs mem0, with Qdrant as the vector store, and gives me persistent memory across sessions. That sounds like a nice-to-have, but it’s the reason I can swap providers mid-task without losing the thread. The memory stays put while the model changes.

The loop

My flow on a feature is consistent. I start with a superpowers brainstorm to narrow down what I’m actually building, getting asked questions until the specifics are clear. Then it fans out subagents for development. I cap the memory on each subagent as a failsafe, because if all of them run their tests at the same time, the box can crash. At the end of a task, an independent superpowers code review runs on its own. Then a pull request on git, and an agent monitors the deployment to AWS.

Remote and mobile

The whole point of the box is that I can work from anywhere. Claude Code’s built-in remote control lets me drive a session from my phone. For OpenCode and Ollama Cloud sessions, I use CodeNomad, which gives me a browser cockpit I can reach from a laptop or a phone.

There’s one tradeoff I keep running into. Any router that lets me mix providers has to change the endpoint Claude Code talks to, and that breaks remote control. claude-code-router is one example, but the problem is general. So I don’t route. The brain stays single provider while I’m remote.

Tried and dropped

I tested Paperclip. The abstraction is great, treat your agents like a company with tickets and approvals, but reading every ticket for context all the time consumed way more tokens and slowed development down. I stuck with vanilla Claude Code and sometimes OpenCode.

I tried Octo (Claude Octopus) as well. It’s a Claude Code plugin that adds external providers alongside Claude to give you multiple model opinions with consensus gates. The idea is solid, but configuring all the providers took real effort, and for what I gained the setup cost wasn’t worth it.

The bill

The bill is $20 for Ollama Cloud and $100 for Claude Code, so $120 a month, plus whatever this 54W box draws in electricity. The reason I keep two subscriptions is redundancy. Both Ollama and Claude have five-hour and weekly limits, and when one hits its limit, I swap to the other. mem0 carries the context, so the swap doesn’t cost me the session.

I’m happy with this setup. It makes me productive, and it lets me keep working on the go. The one thing I’d like is a better way to manage models from different providers without paying for API usage on top of the subscriptions. If you’ve solved that, I’d love to hear how.