People keep asking what models I'm actually running. So here it is — the real production OpenClaw stack: 20+ individual OpenClaw installations on a mix of VPS servers, Mini-PCs, a DGX Spark, our own server cluster, and hosting services like Hostinger — with automatic fallback so a single outage never takes the system down.
Founder notes from Jeff Hunter · Real setup, not a demo.
Running real work daily — sales, ops, research, content, dev. Lead agent is named T-800. Yes, really.
Centrally orchestrated from a mix of VPS servers, Mini-PCs, a DGX Spark, our own server cluster, and multiple hosting services like Hostinger.
Codex, Kimi, GLM, Grok, Arcee, Stepfun, plus local Ollama. When one slows, the next picks up.
Every week someone asks the same question: "What models are you actually running across all those agents?" This is the real answer.
Anyone running serious agent work hits a wall with a single-model setup — rate limits, downtime, cost spikes, or a weakness the model happens to have for your task. One subscription is a bottleneck dressed up as simplicity.
Each provider does a specific job. Default routing, primary fallback, context-heavy work, speed-tier volume, and a fully-owned local layer. Every piece is there for a reason.
When any single provider has a bad day — rate limit hit, 5xx spike, maintenance window — the stack falls through to the next layer automatically. Agents keep working. That's the whole point.
Every agent on the cluster has a name. The one that runs the most loaded, mission-critical work is named T-800 — because by the time I'm asking for it, I need something that will not stop until the job is done.
"I'll be back — with the next model in the fallback chain."
The name is a wink. The behavior is not. T-800 doesn't stop when one provider wobbles. It routes through the stack, finishes the task, and reports back. That's the whole promise of this setup in one agent.
The Terminator reference isn't marketing — it's a spec. Relentless execution, resilient to single-vendor failure, and oriented around finishing the job. The name sets the bar for everything else on the cluster.
T-800 is the lead. Twenty-plus siblings handle everything else: inbox triage, CRM, content drafts, research, code, scheduling, support, reporting. Named agents make it easy to reason about who owns what.
OpenClaw handles the routing, tool calls, memory, and fallback logic. The agents are the operators. T-800 is just the one everyone remembers — and the one we point to when we want to explain what this stack is for.
Twenty-plus individual OpenClaw installations — each its own agent, some with sub-agents — running on a mix of VPS servers, Mini-PCs, the DGX Spark, our own server cluster, and multiple hosting services like Hostinger.
The 20+ OpenClaw installations run on a mix of hardware: VPS servers, Mini-PCs, the DGX Spark, our own server cluster, and hosting services like Hostinger. The DGX Spark is the heavy lifter for local inference, but the real point is that no single machine is load-bearing. The stack is distributed by design — if any one box or hosting provider has a problem, the others carry the load.
Each of the 20+ OpenClaw agents is its own installation, each with its own sub-agents. They run across VPS servers, Mini-PCs, the DGX Spark, our own server cluster, and hosting services like Hostinger. Model selection, fallback routing, local inference, and tool orchestration are handled by OpenClaw. If any single machine or hosting provider goes down, the others keep the agents running.
That does not mean every single model is running locally all the time. The DGX Spark is the central server and control plane. Some models run locally on hardware I own, and some are reached through cloud routes, but the orchestration and resilience strategy still flows through one central system.
Twenty-plus OpenClaw installations, each doing real work for different people. Here is who does what.
A clone of Jeff himself — his voice, his knowledge, his take on business and AI. This is the AI Persona version of Jeff that can speak and respond on his behalf in contexts where his perspective matters.
Jeff's coder, dev planner, and the first agent to get any OpenClaw update or test. If something breaks in a new release, T-800 finds it first. Named for the obvious reason: relentless execution.
Jeff's marketer and marketing-asset builder. Beau maintains his own blog at ai.vastaffer.com, builds pages, writes copy, deploys assets, and handles the marketing production pipeline. You are reading his work right now.
Manages all team calls, records meetings, writes meeting minutes, and owns the to-do list for the VA Staffer team. The operational backbone that keeps human work organized.
The free "kimiclaw" agent that comes with the Kimi Code subscription. Kinda useless, but his opinions are diabolical and he makes for a good laugh. Since he is free to run, the team and clients play around with him. Every fleet needs a mascot.
"12 of these agents are for our clients. We build, deploy, and manage their AI Employees as part of our OpenClaw AI Employee service."
Each client gets a dedicated OpenClaw agent configured for their business, their workflows, and their brand. These are not shared instances — each client's AI Employee is its own installation running on its own infrastructure slot.
VA Staffer's team solves hundreds of OpenClaw issues in the Skool Group for members — in comments, DMs, and live sessions. ClawBoy was created to capture that knowledge. He lives with the team (and soon with AI Money Group members), has all the previous troubleshooting guides, tracks how things get fixed, and writes killer step-by-step guides. He has already produced an awesome guide for launching a second OpenClaw and running both together.
Installed on one of Jeff's servers. Not gonna lie — it was tough to get running, and it is at "mostly works" status. But the potential for safety and security use cases is clear. A NemoClaw use case is in progress.
Each tier has a job. Default routing for everyday volume, a primary fallback for when the default degrades, a context-heavy layer for huge codebases and datasets, a speed/value layer for high-throughput work, and a fully-owned local layer as the insurance policy.
GPT-5.3 Spark is the volume workhorse — fast, cheap enough to run constantly, good enough for the majority of agent tasks. GPT-5.4 is reserved for complex work that actually needs the reasoning bump.
When Codex hits a rate limit, has a bad response window, or goes down, the stack fails over to Kimi Code and GLM-5.1. Both are production-grade for agent work, and both are priced so they can absorb real traffic without blowing up a budget.
When an agent needs to reason over a whole repo, a pile of transcripts, or a large analytical dataset in a single pass, it routes to Grok. The context window is the specific feature I'm buying — not general reasoning, not speed.
Some tasks need to run fast, cheap, and a lot. Arcee and Stepfun sit in the stack for exactly that — when a benchmark or a real workload shows they outperform the default on speed-per-dollar for a specific job, routing sends that job their way.
Every other tier depends on someone else's uptime. The Ollama layer depends on me. But this layer is not one thing, it is two: local models running on owned hardware, and cloud-routed Ollama models that expand the stack without changing the control plane.
The stack is only as good as what happens at the moment a provider starts misbehaving. Here's the flow.
OpenClaw picks the tier based on the job — routine goes to Codex Spark, complex to 5.4, huge context to Grok, batch to Arcee/Stepfun, and sensitive or must-not-fail work can pin to the local Ollama layer.
Rate limits, elevated error rates, timeouts, or slow responses trigger the fallback logic. The agent doesn't wait for a human to notice — the routing layer sees the signal and reacts.
Default → primary fallback (Kimi / GLM) → specialty tier if relevant → local Ollama layer. Each hop is a real working model, not a degraded placeholder. The agent keeps going.
When the primary comes back healthy, traffic flows back automatically. No manual switchover. No "I'll fix it tomorrow." The system re-balances itself and the operators don't notice.
"If any one provider has a bad day, the system falls back and keeps the agents online. That's the whole point of building it this way."— Jeff, on why the stack is designed around fallback, not around any one model
Strong opinion, stated plainly: Ollama's Max plan at $100/month — up to 10 cloud models running concurrently — is absurd value for anyone running OpenClaw at scale. And the local runtime on owned hardware is the piece that makes the whole "no single point of failure" claim real.
When you're orchestrating 20+ agents, concurrency is the thing that actually limits throughput. Ten cloud models running at the same time under a single flat $100/month line item is a pricing shape you almost never see in this space — most competitors sell per seat, per model, or per token.
And for my actual stack, that matters because part of the Ollama layer is local and part is cloud. Local gives me ownership. Cloud gives me extra headroom. Together they make Ollama much more useful than people assume when they only think of it as a desktop local-model app.
For a fleet like mine, that plan pays for itself the first time a premium provider hiccups and agents stay productive anyway. It's not a silver bullet, it's a slot in the stack — and it's a spectacularly well-priced slot.
Everything above the Ollama layer is someone else's pricing, someone else's uptime, someone else's terms of service. The local layer is the one piece of the stack that cannot be taken away, throttled, or re-priced by an outside vendor.
That's not paranoia — it's leverage. It means I can negotiate, switch, or walk away from any provider above it without my agents going dark. For any business that depends on agents running reliably, that kind of independence is what makes the rest of the architecture safe to build on.
See the full breakdown on the Ollama Max page.
Strip away the brand names and this is what a serious production OpenClaw stack looks like in 2026.
You don't have to build a T-800 yourself. A managed AI Employee gives you the benefit of this stack — the right model routed to the right task, with fallback and orchestration already wired up — without doing the infrastructure work. Same thinking. Applied to your company.
Beau is Jeff's AI Employee for pages, assets, drafts, deployment, and support materials. He doesn't replace the team — he helps the team move faster by turning ideas into real deliverables that can be edited, deployed, and improved over time.
