24/7 LOCAL AI MACHINE

I’m a product designer. I am, at best, a mediocre developer — I can read code and I can break code, and until this year I’d never written a program that ran when I wasn’t looking at it.

Late in 2025 I started hearing about OpenClaw and then couldn’t stop. People had wired an AI to their own computer and put it to work: run your business, research any book in your library, generate ideas overnight. One video had a man running several agents like a company, producing digital products faster than any human could.

The claim that got me was about hardware, because it kept repeating: your unused Mac mini is a goldmine. A 16GB M1 can run a capable model 24/7. No cloud, no token bill.

I had exactly that Mac mini on a shelf. This is what happened when I believed them.

One morning in June there was a document in my vault I hadn’t written, and it was better than anything I’d have written myself.

It had a codename, because I let the machine have codenames: OPERATION EMPTY AISLE. Three jobs had assembled it overnight without knowing about each other. One had been searching Creative Market for crypto poster templates and finding none, four nights running, before it would say so out loud. Another had been through my Etsy traffic and found a single astronaut Bitcoin poster accounted for more than half of it. A third read both and connected them.

The argument was clean. Your crypto posters already exist in Figma. The biggest design marketplace in your industry has none of them. Export what you have and list it — no new designs, just platform arbitrage. Three to four hours of work. Three price tiers with reasoning for each. Every claim in a table next to the job that produced it and the date.

I read that and thought: this machine is going to work.

Eleven weeks later, the machine killed it.

A validator picked the play back up, re-ran the research, and came back REFINE — not GO. Creative Market doesn’t have zero crypto assets. It has around 245,000, plus 818,000 poster templates, with free Freepik equivalents holding the price floor at zero. There’s an application gate. And it bans embedded third-party fonts, which is fatal when the typography is the product. At €5–7 a sale minus commission I’d clear about €3–4.

Then the line that actually taught me something: the demand evidence was consumers buying finished prints, not designers buying a system. Right asset, wrong marketplace, wrong buyer.

It proposed the flip — ship the posters as finished printables where the buyer already is, keep the editable system as my own production engine — and noted, unprompted, that this play had now been sent back thirteen times.

I want to be precise about what’s good here, because it isn’t the idea. The idea was wrong. What’s good is that the system wrote every claim next to its source, kept it somewhere findable, went back at it without being asked, refuted its own evidence with better evidence, and counted how many times it had already done that. I’d never have done that. I’d have kept the June version, because I liked it.

The brief above is the machine at its best. Most days it’s smaller than that, and the small thing is what I actually consume.

A report lands every morning at eight. Reliability first — runs since midnight, how many failed, whether anything is quietly broken. Then the overnight pipeline: what the trend scanner found, what the validator did to it, whether a play advanced or got sent back. Then Etsy signals, the day’s money experiment, the job hunt, a practice block, and three suggested actions ranked by what’s blocking what.

Overnight a job scans the remote boards, filters for roles that match me, and writes a tailored cover letter for each — pulling real facts out of my real CV, the companies I actually worked for, the actual portfolio URL. On a good morning there are two roles and two letters waiting. I’ve applied to every role it has ever surfaced. That one is a straight win: it does the finding and the first draft, I do the sending.

Anything worth interrupting me for goes to Telegram — a failed job, an event near me, what I should be working on this week, how many hours I’ve actually put into a project. Those messages are built by plain Python rather than the model, because the model-written versions eventually lied to me.

It’s rudimentary. It’s already more useful than any assistant app I’ve paid for.

A system timer fires a Python script every 60 seconds. The script reads one small config file per skill, works out what’s due, runs exactly one job behind a lock, logs it, and exits.

That’s the engine. No daemon, no queue, no database, no Docker — nothing running between ticks that can die silently. A missed minute heals on the next tick.

Five runners cover the work: one model call and a report (most jobs); pure Python that can’t hallucinate; alerts to my phone; a few Claude jobs for audits; and the build runner, the only one that makes a thing across many sessions and keeps a ledger so work compounds.

Jobs chain by passing batons — each writes its result where the next one reads it. That’s how three jobs that never met wrote OPERATION EMPTY AISLE, and how an overnight idea arrives as a finished report in my vault rather than a file in a folder I’d forget.

It’s standard-library Python, about 15MB on disk, and it moves to a new computer by copying the folder and changing one line.

Nobody in those videos talks about hardware, which in hindsight is the tell. On 16GB the model is the machine.

I stress-tested local models with Activity Monitor open. Feed it context, give it a real task, watch the memory graph hit the full 16GB and sit there while the model freezes on a question a child could answer. Then try the next one.

This is where I learned what the B in every model name is: billions of parameters, the thing’s capacity to think, and the RAM needed to hold it. Once that clicked, my problem stopped being a software problem and never went back to being one.

The gemma4:12b result is the one I’d underline. In a bare terminal it was fine. Inside the agent framework it died — the framework’s system prompts and memory overhead were enough to push it over. Nobody benchmarks that. The benchmark measures the model, but you run the model plus the harness, and the harness isn’t free. I lost a week to not knowing this.

Two rules came out and never left: the model is unloaded from RAM after every job, and one job runs at a time — not a design preference, the ceiling.

And the honest note underneath: the moment I wanted real thinking I reached for a 397-billion-parameter cloud model. The local models were supposed to be the point, and they were already not the ones doing the work.

For weeks my jobs failed anyway and I assumed the model was too stupid. It was, but that wasn’t why. My cronjobs held the whole task and handed it over, and most of what I wanted was multi-step — “fetch a crypto price” is really open the browsing skill → get the price → write it into the vault, and a small model asked to hold three steps drops one. The fix took an embarrassing amount of time to find: the cronjob becomes a thin trigger that calls a skill, and the skill holds the steps. Same model, same hardware, and failures fell off a cliff. A small model usually doesn’t fail because it’s stupid — it fails because it’s asked to hold too much at once.

The part the videos don’t cover.

I named the machine after Ares, the Greek god of war, because it was going to war alongside me. Later, somewhere around the third clean install, I watched Tron: Ares and renamed it Ares Master Control — the kind of decision you make at 1am when nothing is working.

Installing it in the first place meant using AI to install AI: Grok diagnosed the errors and found the fixes while I typed the commands. That set the pattern for the whole project, where one model corrects another’s work.

About a month in, the agent framework corrupted its own files. Every repair I attempted made it worse, because the thing doing the repairs was the thing that caused the damage. I wiped the machine. Something went wrong again in the second onboarding, so I wiped it again. The third time should have been routine and wasn’t. The lesson is narrower than “AI broke my computer”: a framework with write access to its own foundation will eventually damage it, and it cannot be trusted to diagnose the damage.

That third wipe is where the project changed, because I stopped asking how do I get this running again and started asking how do I make the next collapse survivable. I installed Obsidian and documented as I worked, so that if the machine died again the knowledge would outlive it. I also replanned the whole schedule — merging jobs, dropping ideas that had never worked, and rebuilding the 24-hour timetable around what the hardware could actually sustain rather than what I wished it could.

I brought in Hermes and ran it alongside OpenClaw, and on the identical cloud model Hermes did the better job with fewer errors. Same brain, better harness — the same lesson the 12B model had already taught me, arriving from the other direction. Later I added Grok Build in the terminal, and ended up using each model to correct the others’ work.

Then I did the thing this whole project was for: I let the cloud subscription lapse. €0 a month, a machine that produces something by morning — that was the entire premise. Nothing worked. The local model was too slow to answer through Telegram or the terminal in any usable time, and the scheduled jobs couldn’t run on it at all. When I finally opened it up, all 43 jobs were paused, and 41 had died from one shared setting — a model assignment that didn’t support tool calls — failing instantly with the identical error, every day, silently. The machine had been dead for days and never mentioned it.

Cancelling one subscription proved that what I’d thought was a local, independent system was a folder of dead scripts with a cloud API holding it upright. The only real test of “does this depend on X” is turning X off, and I hadn’t run it once. That week wrote the rules since: one setting must never kill the fleet, the scheduler must not die with the AI, and a machine that can stop without sounding an alarm isn’t an automation system — it’s a liability with a power cable.

Grok Build helped me limp through the crash, but it had no Telegram channel and I needed a builder rather than a chat window. I subscribed to Claude — the entry plan, which felt like plenty of tokens at the time.

I gave it three requirements and refused to move on any of them:

1. Swapping models has to be one line, for the day I own hardware that can run a bigger one.
2. Nothing may depend on a subscription or an app. If a service disappears, the system keeps running without it.
3. It has to be plug and play. Copy the folder to another Mac, and it works.

Over about two weeks the machine was rebuilt from nothing, and that’s the system described here. To be precise about who did what: Claude wrote the code, under my direction. I set the goals, the rules, the constraints and the taste, reviewed everything that shipped, and threw out what missed. I couldn’t have written this myself, and it wouldn’t exist in this shape without me saying no a lot.

The rules that came out of it are still the ones it runs on. Python owns all file I/O and the model writes prose only — it never decides where a file goes and never invents links between notes, because it has no idea what exists, so anything it invents is a dead end. One model, one job at a time, enforced by a lock file rather than a convention. Deterministic before intelligent. The machine drafts everything except the click: it never publishes, posts, emails or lists anything. And nothing gets deleted without asking me, because disabling is reversible and deleting isn’t.

Here is what I actually built. A local model that produces work, and a paid cloud model whose job is to check whether that work is real.

I have Claude cronjobs whose entire purpose is verifying the local model’s reports aren’t fabricated. Not improving them. Verifying they describe something that happened. That job exists because the model my RAM can hold will write me a confident, well-formatted, completely invented report and file it in my vault next to the true ones, where I can’t tell them apart by looking.

The evidence is in this piece twice already. The June brief said Creative Market had zero competitors; it has 245,000.

And here is the second, caught in the act — the footer of this morning’s health report, written by the audit pass:

Read what the first draft had done. It called reliability clean while three build loops had been idle for five days. It had lost the validator’s verdict and the reasoning behind it. It presented Monday’s recommendations as though they were fresh. Every one of those errors flattered me — and the daily report is the one file I read every morning, so that’s exactly where the drift does the most damage. What caught it was a frontier model reading sixteen intermediate files to find out whether my local model had told the truth about itself.

So a deterministic checker runs first and overrules the model on everything countable — placeholders, truncation, missing pieces, wrong counts, scope drift. A regex is exact, instant, free, and never rubber-stamps. But “reliability is clean” isn’t countable, and catching that takes a model good enough to reason, which on my hardware means a rented one.

Sit with the economics. The local model is free and produces output I can’t trust; trusting it costs a subscription. The free tier isn’t free — it has a verification tax, denominated in exactly the currency I was trying to stop spending. I now do more work through the cloud than before I had a local machine, because every local output generates cloud work to check it.

For a while I told myself the problem was me — that the machine produced fine analysis and I was slow to act. That story is wrong. Had I executed the June brief the morning it landed, I’d have lost a weekend listing into a saturated market that bans the fonts my product is built from. My inaction didn’t cost me that weekend. It saved it.

Am I part of the problem? Sure — I’m slow, I get distracted, I let the board go empty. But I’m the rim. The neck is the hardware. A machine that can’t hold a model trustworthy enough to run unsupervised hasn’t automated anything. It has moved the work from doing to checking, and checking is the part that costs money.

I wanted the machine managed the way a company manages work, so I tried the tools that promise that. Paperclip AI wants a model in the 400-billion class and ate 6–8GB of my 16 before any model loaded; I gave it a fair run on my 48GB MacBook Pro and it still failed the tasks. Multica AI was self-hosted, much lighter, and actually ran — but the only model smart enough to drive it was the cloud one, which burned my token allowance almost immediately, and it needed Docker and a database, which broke my one rule.

So I asked for the direct version: a board where the cronjobs file their own tickets, no company, no login, nothing leaving the machine. Its entire database is one markdown file. Five columns; machine-generated ideas land in PROPOSED and nothing leaves without me. A card carries a written win condition, and the agent builds exactly the card and nothing else — before that constraint existed the model picked its own scope and produced sprawling work that never finished, every time.

The win conditions are the most transferable thing here. The card that examined the crypto play didn’t say “research the market.” It said:

“Tied to a signal or labelled a guess.” That’s the whole anti-hallucination strategy in eight words, and it’s why the June brief had a table of sources instead of confident prose — and therefore why the August validator had something concrete to refute. You don’t stop a model inventing things by telling it not to. You make the citation part of the definition of done.

When review fails the critique is written to disk and the next attempt has to read it — a rework, not a blind retry. Past an attempt cap the card comes to me with its full history instead of looping forever.

Not everything survived the same treatment. A cronjob meant to generate Blender and Godot assets to sell failed horribly and I killed it: no amount of scaffolding fixes a model that doesn’t have the reasoning.

I’d read about people building pixel-art rooms where you watch your agents work, and wanted one badly enough to spend real money on it. The first version was basic; the second was good — for a while, which is its own lesson. The model starts strong and as the session runs on it makes more mistakes, and then I’m spending tokens undoing damage rather than building. That’s how I ended up on the higher plan. The token treadmill is the subscription treadmill wearing a different hat.

The third screen is the one people remember. It’s a pixel-art Greek stoa drawn entirely in code with no image assets, where the system’s state becomes a place. The characters are Greek gods, one per potential agent. Ares walks the real circuit as a job moves — to the editing bench when the reviewer sends work back, back again when it’s reworked, then carrying a finished scroll to a chest. Failures make it rain. Each report filed adds an amphora. It reads only the logs the engine already writes, makes no model calls, and costs nothing to leave open. The kanban board lives on the same page: create an issue, and when it moves to In Progress you watch an agent pick it up.

Nine characters are coded and waiting. Only Ares ever appears, because only one job runs at a time.

And the detail that tells you everything: the jobs are so small that the task usually finishes before Ares has crossed the room. The animation is slower than the work. A beautiful stage with almost nothing happening on it, which is the fairest picture of this project anyone could draw.

It holds. Hundreds of runs a week, most weeks without failures — though not all; one week had sixteen, and a job crashed on startup every day for a week before it was caught. That’s the honest claim: failures happen, the alerter catches them, and they reach me at breakfast instead of killing the fleet in silence for weeks.

The number that changed my behaviour: the machine is busy 4.8% of the day. I was planning more daily reports at the time. Throughput was never the constraint, and without measuring I’d have optimised hard in the wrong direction while feeling productive.

The number that can’t see me: the tracker says zero job applications. I’ve applied to every role the machine has ever found me — that job is the clearest win in the system; it finds the roles and drafts the letters, I send them. But nothing writes back when I apply in a browser, and some board work got finished in Figma and never recorded. The machine’s records log the machine’s activity, not mine. Read them as a performance review and you get a confident, well-formatted, wrong answer — which is, one level up, the same failure as the reports themselves.

And the behavioural evidence, which I trust more than any counter: across the whole project these models have generated hundreds of ideas for me. I’ve liked two or three, and implemented those. I read the reports occasionally. I read the Telegram messages every day.

The machine works. The premise doesn’t, and I’d rather say so than write an advert.

Most of what it generates is not good. It hallucinates — invents ideas and data that aren’t real and presents them straight, in the same confident format as the true reports. It ignores instructions, including explicit ones about what not to do, no matter how carefully I write them, and I have rewritten them many times. The June brief is the clean example: a confident, well-sourced, beautifully structured document, wrong on the single fact the whole play rested on.

I want to be exact about where the wall is, because “local AI isn’t good enough” is useless advice. The running model needs 2.7GB at rest, and processing pushes the machine to 12–14GB of its 16. That is the edge of the hardware, not a tuning problem. For the visual, design-led work I care about, nothing under roughly 400 billion parameters has been worth having. Smaller models may well help a developer with code; I haven’t seen their reasoning hold up well enough to build with.

Two more things against myself. I don’t think I’m representative — I had a spare Mac, months of evenings, and a tolerance for wiping a computer three times that most people would be right not to have. If you’re reading this to decide whether to try it, factor that in.

And this piece expires. Everything here is true in August 2026. The models will get smaller and better, the frameworks lighter, and there’s a decent chance the specific wall I hit moves within a year. I’d be pleased if it did.

Test the dependency by turning it off. Not by reasoning about it. One lapsed subscription disproved six months of my assumptions in an afternoon.

Thin cronjob, fat skill. Structure substitutes for intelligence — up to a ceiling. It makes a small model reliable. It cannot make it insightful.

Put the citation in the definition of done. “Tied to a signal or labelled a guess” did more for output quality than any prompt engineering I attempted. A model that must cite has to go and look.

Budget for the verification tax. A local model you can’t trust unsupervised isn’t free — it generates cloud work to check it. Price the checker before you price the machine, and be honest about which one is doing the job.

Have something re-examine old conclusions. The best output of the whole project was a job going back to an eleven-week-old brief and refuting it. Machines are good at the revisiting humans skip, because we like our old ideas.

Audit the thing that reports on itself. My daily report drifts toward “everything’s fine” if nothing checks it, and that’s the one file I actually read. The deterministic checker can’t do this one — “reliability is clean” isn’t countable, so catching it takes a model good enough to reason.

Silent failure is the enemy, not failure. Forty-one dead jobs and a machine behaving as though everything was fine. Uptime you can’t see isn’t uptime. Build the alarm before you build the agent.

The harness costs as much as the model. Same model, two frameworks, wildly different results — in one case the difference between working and dying. Benchmark the whole stack or you’re benchmarking nothing.

Your logs are not a record of you. Anything you do with your hands, outside the machine, is invisible to it. Don’t let a system that can only see itself tell you how you’re doing.

Assume the quality drifts. My local jobs got worse over days with no code change, and cloud models start strong then degrade as the chat gets compacted — forgetting things, reintroducing bugs already fixed, burning tokens on damage repair. Build for drift, not for the capability you measured once. And never let the thing that broke it diagnose it.

What I pictured was a company in a box: dozens of agents producing sellable work while I slept. What’s on my desk is the infrastructure for that, running well on hardware that can’t fill it. The engine heals itself. The board already feeds multiple agents. The reject loop already turns failure into rework. Nine characters are already coded in.

None of that is waiting on code — it’s waiting on RAM, and I mean that as a technical claim rather than a shrug. The running model needs 2.7GB at rest and processing pushes the machine to 12–14GB of its 16. That’s the edge. For the visual, design-led work I care about, nothing under roughly 400 billion parameters has been worth having — and a model that size wants a 512GB Mac Studio to sit in, which buys better output and still runs one job at a time. Better answers, identical shape, four more digits. Fix the hardware and the verification tax disappears; don’t, and no amount of better prompting or better discipline closes the gap. I’ve tried both.

Robin Sloan has an essay arguing an app can be a home-cooked meal — software that never has to scale, made for one household. That’s what this is. It isn’t good the way a product is good; it’s good the way something made in your own kitchen is good, which is smaller and more durable.

The posts promised a 16GB Mac could run an autonomous money machine. It can’t — including in the expensive way, where the machine runs perfectly and produces work that needs a paid model to certify. But a 16GB Mac runs the scaffolding for one beautifully, and scaffolding built carefully enough isn’t wasted work. It’s a position.

When something genuinely capable arrives at a size I can own, the machine will be sitting there, still running, waiting to be handed a better brain.

That’s a happy ending. Just not the one from the posts.