For a while my homelab's automation was driven by a single vendor's coding agent,
pointed at a single vendor's model, on a single vendor's subscription. It worked
well. I moved off it anyway — to OpenCode
as the agent and OpenRouter as the model layer — and the
whole estate now runs on a bill of a couple of dollars a month with no lock-in to
any one provider.
This is the honest why: what pushed me, what the new shape looks like, what it
costs, and the trade-offs I walked into — because "just self-host it all" and "use
the cheapest model" are both advice that hides a lot of sharp edges.
What I was optimising for
Three things, roughly in order:
- Not being coupled to one vendor. One agent, one model, one account is a single point of failure for pricing, availability, policy changes, and rate limits. If any one of them has a bad day, my automation has a bad day.
- Cost that scales with use, not a flat seat. A homelab's agent usage is spiky — busy some days, silent for a week. A per-seat subscription charges the same either way. I wanted to pay for tokens I actually burn.
- The option to run locally when it makes sense. A lot of the work — summarise this log, draft this text, triage this list — doesn't need a frontier model at all. I wanted the freedom to route the cheap stuff to a local model and reserve the expensive brains for the hard stuff.
Note that "the model is smarter" is not on that list. The frontier models are
excellent and I still use them. The problem was never quality; it was
structure — one rigid pipe where I wanted a switchboard.
The new shape: agent and model layer, decoupled
The key move is separating the two things that used to be welded together: the
agent (the thing that reads your repo, runs tools, edits files) and the
model (the brain it calls).
- OpenCode is the agent. It's open source, it runs where I put it, and crucially it's model-agnostic — it'll talk to whatever you point it at. That alone breaks the coupling: the tool that touches my code is no longer tied to who provides the intelligence.
- OpenRouter is the model layer. It's a single API in front of dozens of models from many providers. One key, one endpoint, and I can route a request to a frontier model, a cheap fast model, or a free one — and change that choice without changing any code.
Put together, I get a switchboard. The agent stays the same; the brain behind it
is a config value. When a provider has an outage, I reroute. When a new model
lands that's better-per-pound, I try it by editing one line. When a task is
trivial, it goes somewhere cheap or local. Nothing about my automation is welded
to a single company any more, and that's the entire point.
What it actually costs
The headline that made me smile: running the whole estate's agent workload —
the morning briefings, the infra checks, the drafting, the summarising — comes to
roughly the price of a coffee a month, because:
- Most requests are routed to cheap or free models. The boring, high-volume work doesn't touch an expensive model at all. A frontier model is reserved for the genuinely hard reasoning, which is a small slice of the total.
- A lot runs locally for £0. Anything a small local model can handle — and that's more than you'd think for summarise/triage/draft work — runs on my own hardware and costs only electricity.
- I pay per token, so a quiet week is a cheap week. No flat seat ticking over while nothing's happening.
Compare that to a flat monthly subscription and the maths is lopsided for a
spiky, mostly-cheap workload like a homelab's. Your mileage varies enormously with
what you run — if you're hammering a frontier model all day, a subscription may
well be cheaper — but for "lots of small jobs, occasional hard one," pay-per-token
across a switchboard wins.
The trade-offs, honestly
This is not a free lunch, and pretending otherwise would make this a worse post.
Not every model can drive an agent. This is the big one. Agentic work needs
reliable tool-calling — the model has to emit correct, structured calls to
your tools and then actually use the results. Plenty of cheaper and local models
are bad at this: some can't tool-call at all, and some emit the calls but then
ignore what comes back, which is worse because it looks like it's working. I've
had to measure this per-model and keep a blocklist of ones that quietly fail. The
switchboard's flexibility comes with a duty to test each model on real agent
tasks, not just trust a leaderboard.
A silent context limit will truncate you. One local setup defaulted to a small
context window and simply dropped the end of long prompts with no error —
producing confident, wrong output from half the input. Routing across many
backends means each has its own quirks and defaults, and you own the job of
knowing them.
You're now the integrator. With one vendor, the agent and model are tested
together and Just Work. Decouple them and the seam between OpenCode and whichever
model is yours to keep working. That's the cost of no lock-in: you trade a
guaranteed-compatible pair for flexibility plus a maintenance duty.
Free isn't always free. Free model tiers rate-limit, change, and disappear.
Building on them is fine if you treat them as a bonus and have a paid fallback
wired up — but a pipeline that depends on a free tier will eventually break when
that tier does.
Would I recommend the move?
If you value not being locked to one provider and you run a spiky,
mostly-cheap workload, yes — decoupling the agent from the model is the right
architecture even before you count the savings. OpenCode + OpenRouter gives you a
model-agnostic agent in front of a switchboard of brains, and the bill tracks your
actual use instead of a flat seat.
If you want one tested thing that just works and you're hammering a frontier
model constantly, staying on a single-vendor agent + subscription is a
perfectly rational choice, and the integration tax I described is a tax you get to
skip.
For me the deciding factor wasn't the money, though the money's nice. It was that
my automation stopped having a single company in its critical path. The agent is
mine, the routing is mine, and any one provider having a bad day is now a config
change, not an outage. That resilience — plus a coffee-a-month bill — was worth
becoming my own integrator for.
Homelab notes from someone who runs an open-source coding agent over a
multi-provider model switchboard, mostly on cheap and local models, and treats any
single vendor in the critical path as a bug to design out. The OpenCode link above
is a referral; the opinion isn't for sale, the tool's just genuinely what I run.
🤖 Drafted with AI assistance from my own homelab notes, logs and repos, then reviewed and edited before publishing.
Top comments (0)