I have spent the last few months tuning how I actually run AI day-to-day. The result is a setup that mixes a cloud subscription for the heavy lifting with a local model as a safety net, all wired through a single coding agent that can route different sub-tasks to different models. In this post I will walk through the pieces: the Ollama Cloud subscription, the Pi agent, and the multi-model subagent configuration I use for project development and local hosting tasks — with the local model fallbacks for outages, subscription exhaustion, or remote work.
The Big Picture
The whole thing is built around one idea: use the right model for the right job, and never get blocked when the network drops.
- Cloud tier — an Ollama Cloud subscription gives me access to several large open models without running them locally.
- Local tier — a desktop machine running Ollama serves a Qwen 3.8 27B model as an always-available fallback.
- Orchestration — the Pi agent decides which model handles which sub-task, and automatically falls back to the local model when the cloud is unavailable.
Why I Don’t Use Claude
A lot of people assume the obvious choice for a coding agent is Claude — Anthropic’s model, or Claude Code. I have tried it, and I deliberately do not use it. Here is why.
Cost. Claude’s subscription tiers are expensive, and the pay-per-token API is brutal for agent workloads that churn through millions of tokens a day. A heavy agent session can burn through a lot of usage, where I otherwise find success with smaller open models and more directed tasks and outcomes.
Model flexibility. Claude locks you into one vendor’s model. With Ollama I can route different sub-tasks to different models — DeepSeek for fast coding, GLM for deep reasoning, Kimi for code generation, MiniMax for research — and pick the best tool for each job. One subscription, many models. That multi-model approach is not unique to Ollama either. OpenCode and Goose are both open source agents that let you pull in whatever model you want, and OpenRouter gives you a single API key across hundreds of models from lots of providers on a pay-per-token basis. The pattern — several models, one interface — is the part that matters, and there are a few ways to get it.
Privacy. Anthropic trains on user data by default (you have to opt out). Ollama’s cloud processes prompts transiently and never uses them for training. For operations work — logs, configs, internal systems — that matters.
No local fallback. Always have a plan B. You cannot run Claude on your own hardware, and the latest models may not always make it to other backends. When remote or usage runs tight, my setup falls back to local model options that are similar to what I have been working with.
Openness and control. Open-weight models mean no vendor lock-in. If a model gets worse or a vendor changes terms, I swap it out. I own the stack, not the other way around.
None of this is to say Claude is bad — it is genuinely capable. It is more that for how I work — agent usage, privacy-conscious concerns, and an interest in testing multiple models and open source developments — I keep landing on the open-model stack.
The Local Fallback — Qwen 3.8
Cloud models are great, but they are useless when the network is down, the subscription hits a limit, or I am working somewhere with no connectivity. That is where the local tier comes in.
I run a separate Ollama instance on a desktop machine on my network, serving Qwen 3.8 27B. It is not as capable as the big cloud models, but it is:
- Free — no subscription, no per-token cost.
- Private — nothing leaves the machine.
- Always available — no network dependency.
The Pi agent is configured to treat it as the fallback for every sub-agent, so if the cloud models are unreachable, work continues on the local model instead of grinding to a halt.
The Pi Agent
Pi is the coding agent that ties everything together. It is a terminal-based agent that can read code, run commands, edit files, and — crucially for this setup — spawn sub-agents to handle different parts of a task in parallel.
Why Hermes and Pi
Two pieces of the stack deserve a special mention.
Pi is the agent itself. I chose it over the alternatives because it is terminal-native, fast, and — most importantly — it lets me run sub-agents in parallel and assign each one a different model. That multi-model orchestration is the whole point of this setup, and Pi does it natively.
Hermes is the memory layer. Pi forgets everything when a session closes; Hermes fixes that. It keeps persistent memory across sessions, searches every past conversation, learns from failures so I do not repeat mistakes, and even scans for secrets so API keys never get saved. For operations work, where context from a previous incident is gold, this is invaluable.
Running Hermes 24/7
I do not just run Hermes on my main machine — I run a second instance on a spare Mac M3 that stays on around the clock. It is always available, and I talk to it through Discord. This gives me an always-on assistant I can reach from anywhere, without needing my main workstation up.
It handles three kinds of work:
- Quick code changes on small repositories — small, well-scoped fixes and tweaks that do not need the full multi-model stack, done on demand.
- Research and queries — answering questions, digging into topics, and pulling together information on request.
- Home automation and response — driving and responding to my home automation setup, so I can ask it to check or change things around the house.
Because it runs on the M3 with the same Ollama stack, it gets the same cloud models with the same local Qwen fallback — and because it is always on, it is there when I need it, day or night.
The Discord gateway
Talking to an agent over Discord is just a matter of pointing Hermes at a Discord bot. I created a bot for the server, grabbed its token, and gave it to the M3’s Hermes instance. Once configured, any channel the bot can see becomes a terminal for it — I send a message, the agent picks it up, runs the work, and replies in-thread.
The config that drives this is what you see in the screenshot below. The important parts are the Discord bot token and the channel bindings — which channels the bot listens to and is allowed to respond in. Keeping it scoped to a couple of specific channels (rather than the whole server) keeps the always-on agent out of the way when I do not need it.
The practical effect: I can drive the always-on Hermes instance from my phone or any machine with Discord, whether I am on the network or not. Because it is the same Pi/Hermes stack with the same Ollama models, the conversation I have over Discord behaves exactly like the one in my terminal — same sub-agents, same local fallback — just reachable from anywhere.
Pi’s configuration lives in ~/.pi/agent/. Two files matter here:
models.json— defines the providers and the models available to each.settings.json— defines the sub-agent model assignments and fallbacks.
Provider configuration
The models.json file declares two providers. The first points at the local Ollama instance that fronts the cloud subscription:
{
"providers": {
"ollama": {
"api": "openai-completions",
"apiKey": "ollama",
"baseUrl": "http://127.0.0.1:11434/v1",
"models": [
{ "id": "deepseek-v4-flash:cloud", "reasoning": true },
{ "id": "glm-5.2:cloud", "reasoning": true },
{ "id": "kimi-k2.7-code:cloud", "reasoning": true },
{ "id": "minimax-m2.7:cloud", "reasoning": true }
]
},
"ollama-remote": {
"api": "openai-completions",
"apiKey": "ollama",
"baseUrl": "http://<desktop-ip>:11434/v1",
"models": [
{ "id": "qwen3.8:27b", "name": "Qwen 3.8 27B (Local Desktop)" }
]
}
}
}
The ollama provider is the cloud subscription, exposed through the local Ollama daemon. The ollama-remote provider is the desktop machine on my LAN running the local Qwen model.
Sub-agent multi-model configuration
The interesting part is in settings.json. Pi ships with a set of sub-agents — scout, worker, delegate, researcher, reviewer, and oracle — each with a different job. I assign each one a different cloud model based on what it does, and give every one the same local fallback:
{
"subagents": {
"agentOverrides": {
"scout": {
"model": "deepseek-v4-flash:cloud",
"thinking": "low",
"fallbackModels": ["ollama-remote/qwen3.8:27b"]
},
"worker": {
"model": "deepseek-v4-flash:cloud",
"thinking": "medium",
"fallbackModels": ["ollama-remote/qwen3.8:27b"]
// Alternative: swap DeepSeek V4 Flash for Kimi K2.7 Code on this sub-agent
// "model": "kimi-k2.7-code:cloud",
},
"delegate": {
"model": "minimax-m2.7:cloud",
"thinking": "medium",
"fallbackModels": ["ollama-remote/qwen3.8:27b"]
},
"researcher": {
"model": "minimax-m2.7:cloud",
"thinking": "medium",
"fallbackModels": ["ollama-remote/qwen3.8:27b"]
},
"reviewer": {
"model": "glm-5.2:cloud",
"thinking": "high",
"fallbackModels": ["ollama-remote/qwen3.8:27b"]
},
"oracle": {
"model": "glm-5.2:cloud",
"thinking": "high",
"fallbackModels": ["ollama-remote/qwen3.8:27b"]
}
}
}
}
The logic behind the assignments:
- Scout and Worker do the bulk of the fast work — codebase recon and implementation. DeepSeek V4 Flash is fast and cheap on usage, so it is the right default for high-volume work.
- Delegate and Researcher handle research and delegation. MiniMax M2.7 is a good fit for gathering and synthesising information.
- Reviewer and Oracle do the highest-effort reasoning — reviewing diffs, validating plans, and answering hard questions. GLM-5.2 with
thinking: highis the most capable model in the stack, so it gets the jobs that need the most care.
Every sub-agent has the same fallbackModels entry pointing at the local Qwen 3.8. This is the resilience layer: if the cloud subscription is down, rate-limited, or unreachable, the sub-agent transparently falls back to the local model and the work continues.
Extensions
Pi is extensible, and I run a handful of extensions that make the setup practical:
- Lens — language-aware feedback while the agent writes code. LSP diagnostics, linters, type-checkers, and structural rules run on every edit, so errors surface immediately instead of at build time.
- Caveman — cuts roughly 75% of output tokens by making the agent terse while keeping full technical accuracy. Less noise, faster reads.
- MCP Adapter — connects MCP servers without burning the context window. One proxy tool instead of hundreds, and servers only start when you actually use them.
- GitHub MCP — gives the agent direct access to GitHub: issues, PRs, repos, and CI, all through the MCP protocol.
- Excalidraw MCP — lets the agent create and edit Excalidraw diagrams, which is great for sketching architecture and incident timelines.
Why This Works for Operations
This setup works well for operations work — the kind of task where you are digging through logs, checking configs, running commands, and reasoning about system state. A few reasons:
- Cost control. The flat subscription means I am not watching a per-token meter. Fast models handle the high-volume grunt work, and the expensive reasoning models are reserved for the tasks that actually need them.
- Resilience. The local fallback means an outage on the cloud side does not stop me. The agent degrades gracefully instead of failing.
- Parallelism. Sub-agents let me fan out independent investigations across multiple models at once, which is exactly what you want when triaging a production issue.
- Privacy. Sensitive operations data can be routed to the local model when needed, keeping it off the network entirely.
Limitations and Trade-offs
No setup is perfect. A few things I have learned:
- Local model capability gap. Qwen 3.8 27B is solid, but it is noticeably weaker than the cloud models on complex reasoning. Fallback keeps you running, not at full capability.
- Concurrency limits. The Pro tier’s 3 concurrent cloud models can be a bottleneck if you spawn many sub-agents at once. Requests queue, which adds latency.
- Usage levels. Different models burn through the subscription’s usage at different rates. The big reasoning models consume usage much faster than the fast ones, so it pays to route carefully.
- Network dependency for the cloud tier. The cloud models still need connectivity. The local fallback mitigates this, but you feel the difference in quality when you drop to it.
Wrapping Up
My AI setup is a three-layer stack: an Ollama Cloud subscription for the heavy lifting, a local Qwen 3.8 model as an always-on fallback, and the Pi agent to route work across them. The multi-model sub-agent configuration means each part of a task runs on the model best suited to it, and the whole thing keeps working even when the cloud does not.
If you are running a coding agent and have not tried splitting work across models — or adding a local fallback for resilience — it is worth giving it a go. The config is just a couple of JSON files, and the payoffs in cost control and reliability are real.
The stack is not static. Next on my list is Orca — the agent development environment (ADE) that runs Pi, Claude Code, Codex, OpenCode and others side-by-side in isolated worktrees — which I am starting to poke at to see how it fits alongside my Pi workflow. Always good to have another tool in the box.