The Case for a Local-First Agent Fleet (and When Cloud Orchestration Wins Anyway)

Every one of these conversations eventually turns into a cost model argument, and most of those arguments are wrong in the same way: they assume compute is compute, so where you run it is just a matter of taste. It isn't. If you're one developer running five agents for a few hours a day, the machine already sitting under your desk paid for itself months ago. If you're spinning up two hundred agents for an hour once a week, that same machine is a liability you'd have to buy, rack, and babysit two hundred times over. This post is about drawing that line honestly, not selling you on one side of it.

What "local-first" means when the model call still leaves the building

The first pushback I get about local-first agent runtimes is some version of "the AI still runs in the cloud, so what's the point." That's true, and it's also beside the point. When Bernato's daemon, bernatod, kicks off a coding agent on your machine, that agent still calls out to whichever model API you've configured, exactly as it would if the process were running on a rented VM. The network hop to the model provider happens either way. What changes is everything around that hop: the process that spawns the agent, watches its output, restarts it if it stalls, and hands you a session you can reconnect to from your phone twenty minutes later. That supervisory layer is cheap to run and idle most of the time, which is exactly the kind of job a laptop, a homelab box, a GPU rig, or an old Mac mini gathering dust is good at.

bernatod, plus the web dashboard and the Expo mobile app, is the whole runtime surface. There's no separate compute tier you're renting from Bernato, because there isn't one: the product is local-first by design, Apache-2.0, and free. You reach your agents from anywhere either through a dial-out WebSocket broker (the machine calls out, so you don't open ports or manage a static IP) or LAN-direct routing when your phone happens to be on the same network as the box. Neither path requires your code to leave hardware you control between requests.

The honest cost case for hardware you already own

Here's the part that's easy to make precise. If you're carrying a laptop already, or you've got a spare machine collecting dust in a closet, the marginal cost of supervising five, ten, or twenty agent processes on it is close to zero. You paid for the box once. Electricity is a rounding error next to what a cloud provider charges per instance-hour. And because Bernato doesn't meter agents or bill by the hour, running an agent for four hours today and forty hours next week costs exactly the same: whatever the hardware already cost you, amortized however you like.

Cloud instance-hours and managed container orchestration invert that model. You pay per unit of compute, per hour or per second, which is the right deal when your workload is spiky or shared across a team, and a bad deal when your workload is one person running a steady handful of agents on weekdays. In that second case you're paying a recurring premium for elasticity you never use.

Two topologies, one protocol

The shape of the two setups is genuinely different, not just the billing. A local mesh is a handful of boxes you own, each one dialing out to reach you. A cloud cluster is a handful of instances living inside someone else's rack, reachable through their network instead of yours. The agents themselves don't care which one they're running on. The difference is who owns the metal and who's on the hook when it needs attention at 2am.

Find your own crossover point

Numbers make this concrete faster than argument does, so here's a rough calculator. It's deliberately simple: it assumes a $2,000 machine amortized over 3 years for the local side (ignoring electricity, and treating that as a rough floor, not a real quote), and $0.10 per hour per agent-equivalent for the cloud side (illustrative only, actual cloud pricing varies enormously by provider, instance size, and whether you're using spot capacity). Neither number is a real bid from anyone. What they show is the shape of the tradeoff: local cost is fixed no matter how many agents you run on the box, cloud cost scales linearly with agents times hours.

Notice what happens at the defaults: 5 agents for 4 hours a day lands the cloud estimate within a few dollars of the local one. That's not a coincidence, it's roughly where the crossover sits for a single developer's steady workload. Push either number up (more agents, more hours) and the cloud line climbs while the local line stays flat, because you already own the box. Push both numbers way up, past what one machine can comfortably run, and the local side stops being a single flat number too: you'd need a second box, which is a step function, not a smooth curve. The calculator doesn't model that step, which is exactly why you should treat both outputs as a floor and a rough guide, not a budget.

Where cloud orchestration wins anyway

None of this is an argument that local-first is always correct, and I'd be lying if I said otherwise. There are three places where cloud orchestration is the better call, and none of them are edge cases.

Real elastic burst. If you occasionally need two hundred agents for an hour, say for a one-off migration, a large-scale codebase audit, or a batch of parallel experiments, and then you need zero agents for the next three weeks, owning two-hundred-agents-worth of hardware to cover that one hour is a bad trade. Cloud instance-hours exist precisely for this shape of demand: pay for the spike, pay nothing for the trough. A local fleet can't do that without you buying capacity you'll leave idle 99% of the time.

Zero hardware babysitting. Owning the box means you own its failures too: a dead SSD, a flaky power supply, an OS update that breaks something at 1am. Managed cloud infrastructure abstracts that away, and if your time is worth more than the hardware maintenance tax, that's a legitimate reason to pay someone else to carry it.

Geographic distribution for a team. If your team is spread across three continents and everyone needs low-latency access to a shared pool of agents, a single homelab box in one city is a bad fit no matter how fast its network connection is. Cloud regions exist to put compute near the people using it. A local mesh is, definitionally, local to wherever the hardware sits.

Stating the crossover plainly

Strip away the nuance and the rule of thumb is short: steady, personal or small-team use favors local, because the cost is fixed and you're already paying it. Spiky, large-scale, or team-shared use favors cloud, because the cost is variable and elasticity is the thing you're actually buying. Most individual developers and small teams live comfortably on the local side of that line. Most of the exceptions involve either genuine burst spikes or a team big enough that "who owns the box" stops being a rhetorical question and starts being an actual staffing problem.

Hybrid setups are normal, not exotic

Nothing about local-first commits you to an all-or-nothing choice. It's entirely reasonable to run your steady, day-to-day workload on hardware you own, supervised by bernatod, and reach for burst capacity somewhere else only when a specific job actually needs it. That's not a special mode Bernato ships, it's just an architectural choice you're free to make: local for the baseline, something else for the spike. I'd rather be upfront that this post isn't describing a packaged hybrid product, because it isn't one. It's a framing for how to think about combining the two when your workload genuinely has both a steady part and a spiky part.