Local Model or Cloud Model? I Use Both, on Purpose.

For two mornings in a row, the same three briefs landed in my Slack before I was up. On Thursday they were written by a model running in a data center. On Friday they were written by a model running on a Mac Mini in my house. I didn't plan it as a test. A computer went to sleep when it shouldn't have, and I ended up with a useful look at what a local model does well and where a cloud model still earns its bill.

What a Local Model Is, in Plain Terms

Most people meet AI through a website or an app. You type, your words travel to a company's servers, a very large model answers, and someone pays for that by the message or by the month. A local model is the same kind of thing, shrunk until it fits on a computer you own. Nothing leaves the house. There is no bill per message. The trade is that it's smaller, so it writes less and catches less, and it only runs as fast as your hardware allows.

Most of the talk about local models is about writing code. That isn't what I use mine for. Outside of code, the jobs a local model handles well are the plain ones:

• Summarizing something you hand it: a feed, a page, a set of notes.
• Turning raw data into a tidy, readable message.
• Sorting and labeling. Which bucket does this belong in?
• Pulling specific details out of a longer text.
• Short first drafts where you will do the editing.

Where it falls behind is the long, layered work: reading widely, holding a lot in mind at once, and writing with judgment about what matters.

The Use Case: Briefs I Read with Coffee

I run a small, self-hosted assistant called OpenClaw on a Linux box at home. It works on a schedule. Every morning around 6:30 it runs a handful of jobs. Each one looks things up, writes a short brief, and posts it to its own Slack channel. One covers Formula 1. One covers the St. Louis Blues, the Cardinals and the Kansas City Chiefs. One covers the day's weather.

These are light jobs. Nobody is waiting on them and nothing breaks if one comes out a little thin. I had recently pointed them at Gemma 4, an open model from Google, running on the Mac Mini, with Claude Sonnet 5 as the fallback if the local model didn't answer. The heavier jobs, like the one that reads and sorts my inbox every two hours, stay on the cloud model.

The Morning the Mac Mini Overslept

On Thursday the Mac Mini was asleep. It woke for a few seconds each time the assistant knocked, started answering, and dozed off again mid-sentence. The assistant waited, gave up, and handed each brief to the cloud model instead. One brief, about Mizzou football, never arrived at all. On Friday the Mac stayed awake and the local model wrote everything.

That gave me the same three jobs, one day apart, one on each model. I've let it run since. The local model has now written the briefs on eleven mornings and the cloud model on two. The news is different every day and two cloud mornings isn't much, so read this as a pattern, not a benchmark.

Two Minutes Instead of Twenty Seconds

Cloud shows both mornings. Local shows the typical morning out of eleven, with the shortest and longest in parentheses.

The cloud model was roughly three to seven times faster and wrote two to three times as much. For a message that posts before I wake up, two minutes versus twenty seconds makes no difference to me. It would matter a great deal if I were sitting there waiting.

Some of that gap is my setup. The Mac Mini isn't a dedicated machine. It's the computer I work on every day, and Gemma 4 shares it with everything else I have open. On a machine set aside for the model, the local times would be shorter.

The cost runs the other way. Each cloud brief used between 133,000 and 292,000 tokens, the unit these services bill by, and almost all of that was reading, not writing. The local runs cost nothing per message.

What the Difference Reads Like

Numbers undersell it. Here's the Chiefs section of the sports brief from the cloud model's second morning, next to the local model's the day after.

The facts are the same on both sides. The record, the 30-27 win, the two injured receivers, the Tyreek Hill rumor. The cloud version connects them. The injuries are why the reunion is being floated. The local version files each one under a label and moves on.

The cloud model isn't spotless either. On its first morning it wrote that the Blues' puck drops “tonight,” then argued with itself about the date in the same sentence: “wait, today's the 1st — opener is tomorrow.” That made it into the posted message.

The F1 brief shows the same thing on a single story. Both models reported that Esteban Ocon is leaving Haas.

Where it mattered most, they matched. Both F1 briefs end with the latest race result and the championship standings, pulled from a small script, and both models reproduced every position, gap and point total identically. Handing a local model structured data and asking it to lay that out cleanly is exactly the kind of job it's good at.

It Felt Wordier. The Count Says Otherwise.

A week and a half in, I was sure the local briefs were getting longer. So I counted. They aren't. The F1 brief has landed between 411 and 595 words every morning it ran. Weather has stayed between 40 and 87. Sports bounced around the most, from 121 to 258, and it isn't climbing.

What changed is the sports brief. The Cardinals' season ended and I took them out, so the same space now covers two teams instead of three. Each team went from about 58 words to about 76. The model also started opening every bullet with a bold label. Here's the Chiefs section from the first local morning and the latest one.

It reads longer. It isn't, not by much. Each team gets more room and the labels make it look busier. The whole brief was 149 words on the first morning and 147 on the latest.

Using Both, on Purpose

I'm keeping the split. The briefs stay on the local model. They're short, they repeat every day, nobody is waiting on them, and if I want the long version of the Ferrari drama I know where to find it. The inbox job stays on the cloud model, because sorting a hundred emails correctly is worth paying for.

The cloud model also stays on as the fallback. Thursday showed why. A model that runs at home comes with a failure a cloud service doesn't have, which is the machine it lives on. Mine came down to a setting. The Mac wasn't set to stay awake for network requests. I fixed that and it hasn't overslept since.

It did go quiet one more time. A week later the local model was timing out and needed a restart. The cloud model wrote every brief that morning and nothing was missed. On the eleven mornings the local model was up, it posted 43 of 44 briefs. The one it missed was an F1 brief it started and never finished.

So have a backup. Mine is a cloud model that picks up when the local one doesn't answer. These are sports scores and weather, and I'd still rather not lose a morning. If the job were critical, I wouldn't run it without one.

Where This Is Going

If you're curious about local models and you don't write code, start where I did. Pick one small, recurring thing you already read every day and let a local model draft it. Then read it next to what a cloud model gives you for the same job. You will see quickly which jobs need the bigger model and which ones never did.

The other thing to sort by is time. If nobody is waiting, two minutes is nothing and the local model can take as long as it needs. If someone is sitting there, or the answer is only useful right now, that's a job for the faster model. I ask two things of a job before I pick. How good does it need to be, and how soon does it need to be there.

I started out asking whether a local model was good enough. It depends on the job, and on who is waiting for it. For most of what I read before breakfast, it is.