I put Ollama on the Mac mini that already runs all day and moved repetitive classification and short generation onto it, off the cloud.
The local model did not replace Codex, and trying to make it replace Codex would have been a mistake. Work whose correct output shape can be fixed in advance moved local. Design, exception handling, and pre-publication judgment stayed on Codex.
Originally published in Japanese on August 8, 2026. This English version was written in September 2026.
One thing up front, because it is the number people will want and I do not have it: I have not measured the reduction. No percentage, no monthly saving, no tokens-per-second comparison. What follows is a structure and a set of boundaries, not a benchmark.
The work that was too small for the cloud
What I actually want a strong cloud model for is ambiguous work: read several sources, decide the change scope, implement, and plan the rollback. Long context and cross-file, cross-tool reach both matter there.
Daily operations contain much smaller decisions. Sort candidates against criteria. Drop things obviously out of scope. Put a short line of copy into a fixed JSON shape. Pull the same fields out of the same kind of input, over and over.
Each one is trivial. Repeated daily, they accumulate — and every one of them was going to the cloud.
When I reviewed model routing across 66 production runs, the same split showed up: clearly repetitive work and ambiguous, high-blast-radius work belong in different places. This was the next step — taking part of the repetitive end off the cloud entirely.
The machine and the model
An M4 Mac mini, 24 GB unified memory, 1 TB SSD. It was already my always-on host for long agent work.
As of August 8, 2026 it ran Ollama 0.32.5. Update for this English version: Ollama has since reached 0.33.3 (September 2026), so treat the version below as the one I tested, not the current one.
Ollama’s macOS documentation lists macOS Sonoma (v14) or newer, with Apple M series supported for both CPU and GPU and x86 supported CPU-only, and recommends installing the DMG into Applications. I used Homebrew instead, to match how I manage the rest of my CLI tooling:
brew install ollama
brew services start ollamaThe model is qwen3:8b:
ollama pull qwen3:8b
ollama run qwen3:8bOllama’s library page lists it at 8.19B parameters, Q4_K_M quantization, 5.2 GB download, Apache 2.0. That 5.2 GB is the model file size. It is not a claim that the process occupies 5.2 GB while running.
Keep the server resident, not the model
The first thing I separated was the Ollama server process from the model it loads.
The server runs as a Homebrew service, available once the Mac mini boots. Ollama serves its API at http://localhost:11434/api by default, and my programs hit /api/chat from inside the same machine. Nothing is exposed off the box.
The 8B model does not need to stay in memory all day. I set keep_alive to 10m, so it unloads ten minutes after the last request. The next run pays a reload cost; I preferred that to holding memory during hours of inactivity. (Ollama’s own documented example uses 5m; the value is yours to pick.)
My settings are JSON structured output, think disabled, and num_ctx of 4096 under options. This is a configuration for sorting supplied candidates into a fixed schema, not for long reasoning or wide context.
Ollama’s chat API accepts a format parameter set to json or to a JSON schema. A schema-conforming response is not a correct response. My program independently validates required fields, types, and allowed values, and refuses to proceed on anything invalid.
Four layers, and the local model is only one
This is the part that mattered most. Installing a local model did not mean handing it everything.
| Layer | Owner | Responsibility |
|---|---|---|
| 1 | Rule processing | Narrow candidates on anything code can decide: dates, duplicates, counts, eligibility |
| 2 | Ollama | Classify what remains, draft short text, return JSON structured output |
| 3 | Deterministic program | Schema validation, state checks, permitted actions, result storage, halt on failure |
| 4 | Codex | Design, exception judgment, changes, independent verification, final accept or reject |
Ollama does not drive a browser. It returns structured candidates containing classifications and draft copy. A separate program receives those and acts within fixed steps and halt conditions.
Anything rules can eliminate gets eliminated before the model sees it. Duplicates, caps, date windows, missing required information — no language model needs to think about those, and filtering first also shortens the input.
Exceptions and changes go back to Codex. A new format appears. The criteria need revising. Output is unstable. It is unclear whether something should ship. Those are design decisions, not things to force into a local model.
What moved, and what did not
Moved local — work whose correct output shape is decided in advance:
- Sorting candidates into a small label set
- Drafting short, formulaic text
- Returning fixed fields as JSON
- Applying the same criteria across many items
- Producing candidates a human reviews before execution
Stayed on Codex, unchanged:
- Designing and changing the workflow itself
- Judgments that require reading official documentation and multiple sources
- Exception handling where failure is expensive
- Fixing code and documentation
- Final checks on publication, safety, terms, and factual accuracy
- Reviewing whether the local model’s output is sound
Being able to generate prose does not mean article writing moves local. A post on this site connects to past articles, house style, fact-checking, WordPress, internal links, and pre-publication QA. That is a different shape of work from drafting a short line.
What the local model suited was the part where the answer space could be narrowed by a schema.
Usage goes down. The amount is unmeasured.
The mechanism is simple: classification and short generation that used to go to the cloud now go to Ollama on the same Mac mini, so the count and size of cloud requests drop by exactly that much.
Subjectively, there are more stretches of repetitive processing that never call Codex at all, which leaves more weekly headroom for design and exception work.
But I have not measured the reduction, and I want to be blunt about that. I cannot tell you what percentage fell or what it saved per month. Per-task token counts were not compared under matched conditions, and neither were the electricity and maintenance costs of running locally.
What I can state is the mechanism and the impression: fewer repetitive requests leave the machine. Producing a real number would require matched periods before and after, with item counts, cloud usage, failures and re-runs, and maintenance time all observed the same way.
24 GB does not mean everything can move local
The scope described here fits into daily operations. It does not feel like a cloud model.
Reload latency. The first request after an unload waits. Keeping the model resident removes the wait but contradicts the point of freeing memory. I chose freeing memory over responsiveness.
Stale knowledge. You cannot assume a local model knows current official specifications. Changing APIs, prices, policies, and product details have to be fetched as primary sources and supplied as input, or verified on the Codex side.
Maintenance returns to you. Ollama updates, model updates, prompts, schemas, timeouts, retries, logs, halt-on-failure. Moving work off the cloud moves the administration onto your desk.
Speed is unmeasured. Short classification feels usable. That is an impression, not a tokens-per-second or average-latency comparison. I cannot tell you that large models, long context, or heavy parallelism are comfortable on 24 GB.
Local is not automatically safe. Bind to localhost, restrict inputs, pass no credentials, validate outputs, put halt conditions in the executing program. The design work is the same as it is in the cloud.
Start with one classifier
Do not swap out an existing workflow. I started in shadow mode, comparing results and changing nothing.
A good first candidate has short input, about three labels, and no path to publication or an update if it gets the answer wrong. Have Ollama return candidates against a JSON schema and look at them yourself. Do not wire execution up yet.
Watch classification variance, load time, memory, and what the failure output looks like. Once that is stable, hand it to a deterministic program — and still keep a checkpoint before anything publishes or changes the outside world.
A support role, not a replacement
Filter with rules. Classify and draft with Ollama. Validate and execute with a deterministic program. Leave design, exceptions, changes, and final checks to Codex.
Splitting it four ways made it obvious which work I wanted to keep on the strong model. I cannot quote a reduction rate. But the same repetitive requests stopped going to the cloud, over and over.
The point of a local model was never to replace everything. It was to hand the cloud model back the work I actually wanted it doing.