How I decide what runs on my machine and what goes to the cloud, what it really costs, and the four things it taught me.
Brahim Bousnguar · September 2026
A Mac mini on a shelf. A Telegram thread on my phone. In between, seventeen agents that each do one thing.
Each agent has a role, a memory, tools and its own chat thread. You don't "change the prompt": you talk to someone else.
The gateway, the agents, the memory and the tools run at home. Only inference leaves — sometimes.
4,448 agent turns since May 2026. It runs, it breaks, it gets fixed on a Sunday evening.
This talk is about the one decision that shapes everything else: what is allowed to leave the house.
A gateway, channels, agents, tools. Nothing exotic — which is what makes it copyable.
OpenClaw holds together three things that would otherwise be three separate projects:
Telegram, Signal. One account per agent, so one chat thread per agent. That's the interface: I don't open a terminal to talk to an agent.
16 Telegram accounts
A folder, an identity, a memory, a model, a tool policy. Adding an agent means adding a folder — not deploying a service.
17 active agents
Home-made MCP servers that expose my own apps, plus the built-in tools: shell, files, browser, scheduled tasks.
4 MCP servers
The right way to think about it: it's not "an AI". It's a switchboard that connects a channel, an agent, a model and tools.
About 273 GB/s of memory bandwidth. That bandwidth, not the core count, decides how fast a local model runs.
It holds a 21 GB model in memory and keeps running containers, a database, web apps.
A 35-billion-parameter model runs comfortably. The ceiling is throughput: only one local agent at a time works properly.
Hence the direct consequence: local is a scarce resource, to keep for what justifies it.
That's what I hadn't understood at first. I thought I was choosing between "free" and "paid". I was actually choosing between two different scarce resources: my machine, or my budget.
For each agent, one question: is this conversation allowed to leave the house?
Everything runs at home — the gateway, the agents, the memory, the tools. The only thing that leaves, when it leaves, is the content of the conversation sent to the model. That's the whole decision.
Personal notes and day-to-day tracking: everything about my private life rather than my work or my code.
ollama/qwen3.6:35b-mlx21 GB in memory
This data must not leave the house. Not because a provider would be malicious — because the question shouldn't have to come up.
Zero cost and stable latency are bonuses. They wouldn't have justified the choice on their own.
This agent is worse than the cloud agents. It follows long instructions less well, it gets lost faster in a chain of tool calls, and it holds 21 GB of memory permanently. I accepted those three things in exchange for one: the text stays here.
Open questions, research, writing, running the fleet itself. It's the agent I talk to when I don't yet know who to talk to.
anthropic/claude-sonnet-5
A generalist spends its time on open, long tasks with lots of tools. That's exactly where a local model falls behind.
And the content — docs, public code, general questions — has no reason to stay at home.
The test I apply: "if this message leaked tomorrow, would that be a problem for me?" If the answer is no, local isn't even a question — you take the best model.
Prototypes, fixes in my repos, technical explorations. It works in a dedicated git worktree and its deliverable is always the same thing: a pull request.
Code is the most demanding use there is: long context, chained tools, zero tolerance for approximation. A local model fails there expensively — it writes plausible, wrong code.
These are my personal repos, public or meant to be. No client code goes through it — that's a rule, not an intention.
As long as Spark was "fixing things", I couldn't trust it. Since it has to produce a branch, a worktree, a PR — something I review before merging — I can let it work unsupervised. The constraint isn't in the model, it's in the process.
| 🏠 Local | ☁ Cloud | |
|---|---|---|
| The criterion | The content must not leave | The content may leave, the task is demanding |
| Model quality | Fine for dialogue, fragile on chained tool calls | The best available |
| Marginal cost | Zero euros | Billed — or included in a subscription |
| Real cost | 21 GB of memory tied up, one agent at a time | A network dependency and a provider |
| Latency | Stable, predictable | Variable, depends on a third party |
| When it fails | It fails with the machine | It fails with the provider |
Of 17 agents, 4 run locally and the rest in the cloud. The ratio isn't a target: it's simply the number of agents that touch private data.
The real numbers, including the one I can no longer measure.
Since the fleet moved to a subscription, my spending dashboard is blind: the subscription reports no cost per token. I can tell you what I paid before, and what I pay now. I can't tell you what the same activity would cost today pay-as-you-go — that would be an extrapolation, not a measurement.
€75 over five months is little. It wasn't the cost that moved me to a subscription: it was not having to think about it at every experiment.
Local costs no euros. It costs three other things, and you need them in mind before choosing.
21 GB tied up while the model is loaded. On a machine that also runs containers and databases, that's not neutral.
One local agent at a time works properly. Two local conversations at once, and both slow down. The cloud is parallel by nature.
The highest cost and the least visible. A local model is wrong differently: it stays plausible for longer.
I moved a local agent to a bigger model, thinking "more parameters, better agent". It was a dense model: it activated every parameter on every token. Turns went up to about twenty minutes and the fans never stopped. The model I use today looks smaller but is sparsely activated: it activates only a fraction of its parameters, and it's several times faster.
The general lesson: for a local agent, the question isn't "how many parameters", it's how many active parameters per token.
Four lessons paid for in real outages, on a Sunday evening, with the agents down.
A local agent had to create a note. The tool succeeded — twenty times. The model couldn't read its own tool results: it called again, got a success, didn't recognise it, and started over. I found twenty identical notes.
Not the model alone: the model with no fallback. This agent had no backup model. When local drops off, it drops off all the way.
It's the same lesson as for tool servers: a success that changes nothing is worse than an error. Local, with no net, you pay for it twenty times.
Months of incidents. Here's what actually failed:
| The symptom | The real cause |
|---|---|
| "The agent stopped answering" | A stuck gateway process. Kill it, don't restart everything. |
"The tool returns fetch failed" | The service listened on one interface, the URL pointed at another. |
| "Everything broke after the update" | Desktop app and gateway on two incompatible versions. |
| "The scheduled task stopped firing" | A renamed agent id, and three config files still on the old name. |
| "The agent errors out immediately" | Node below the minimum required version. Nothing to do with AI. |
In other words: it's operations. Networking, versions, processes, naming. The skills that matter here are the ones you already have — not "AI" skills.
A "smart" agent I asked to look up my data. It suggested commands, I copied them, I pasted the output back. I had become its terminal.
Four home-made MCP servers that expose my own apps. The agent calls a typed tool, gets a computed result, and acts. I'm out of the loop.
4 MCP servershome-made apps
The jump in quality never came from a better model. It came, every time, from a better tool: one that answers a business intent instead of exposing a table, and refuses invalid input instead of ignoring it.
Seventeen chat threads are seventeen places where something can be waiting for an answer. I deleted several that were no longer used — the best maintenance decision I've made.
Every agent has instructions, a memory, skills. They age. An agent you never review ends up applying rules that are no longer true.
Renaming an agent touches its configuration, its scheduled tasks, its sessions and every script that hard-codes its id. It cost me a whole evening, once.
The right reflex: before adding an agent, ask whether an existing agent should just get one more tool. The answer is yes more often than you'd think.
I created agents hoping specialisation would be enough. What was missing was tools — not personalities.
"Bigger" cost me twenty-minute turns. The right question was activation per token, not parameter count.
Several scheduled tasks produced noise I no longer read. I deleted them. An automation you ignore is debt, not a gain.
It's a privacy decision. Sold as savings, it disappoints — because you pay in quality what you save in euros.
A personal lab isn't an enterprise architecture. Three things carry over anyway.
The first question isn't "which model", it's "what is allowed to leave". Once that boundary is drawn, the model choice becomes a consequence, not a debate.
An agent becomes acceptable when its output goes into a review process that already exists. You can review a PR. You can't review "done".
The budget of an agent project goes into exposing existing systems cleanly, not into choosing the model. It's API work, and it compounds.
At home, when it breaks, it only breaks for me. An agent fleet at a company needs monitoring, on-call, traceability and identity management — that is, everything I allowed myself not to do.
Not a cost decision. You pay in quality, memory and throughput for what you gain by not moving the text.
For anything whose leak wouldn't be a problem, taking the best model is the obvious call.
No jump in quality came from a model. They all came from a better tool, better typed, closer to the intent.
Networking, versions, processes, naming. The skills you need are the ones you already have — not "AI" skills.
The slides and speaker notes are online.
heybrahim.com/talks/openclawThe gateway that holds it all together.
heybrahim.com/talks/mcp — why MCP changes the game (in French).
Brahim Bousnguar