Sovereign AI: How to Build a Local AI Lab That Never Stops Working

The Human

Alex Finn is one of the biggest voices in AI building on YouTube and the founder of Creator Buddy. In January he started buying computers. Three Mac Studios with 512GB of memory each, a DGX Spark, a machine he built around an RTX 5090, and a stack of Mac Minis — all of it running models in his office, none of it renting intelligence from anybody.

He spent months telling people to get into local AI and got made fun of for it. Then two things happened within a few weeks: Fable got banned, gone overnight and back a day later, and GLM 5.2 shipped as the first open-weights model you can run at home that lands anywhere near frontier. People stopped laughing.

"We own everything except for the intelligence," he says. "Why can't we own the intelligence?"

What makes him worth listening to is that he is not selling the all-or-nothing version. He still pays for a Claude Max plan and maxes it out every month. He will tell you plainly that local models are slower and dumber. His argument is narrower and much harder to dismiss: once intelligence costs electricity instead of tokens, you can leave it running forever, and an entire class of work that was never economical suddenly is.

The other thing worth stealing is his method. He had never networked a computer in his life. He still has not loaded a model by hand — his agent does it. He just kept asking the AI how to do the next thing until the lab existed.

‍

"We own everything except for the intelligence. Why can't we own the intelligence?"
‍— Alex Finn, founder of Creator Buddy

‍

‍

Everyone asks which computer to buy first. That is the second question.

The reason to own your intelligence is not that it is smarter. It isn't. It is that when intelligence costs electricity instead of tokens, you can leave it running — and work that was never worth paying for suddenly is.

Alex calls this ambient intelligence: intelligence that is constantly monitoring, constantly reacting, and constantly burning tokens. The mental model he uses is the humanoid robot everyone expects in their kitchen within a year or two, the one doing the dishes and folding the laundry. Low-intellect tasks, done continuously, that nobody would ever pay a person to do. Ambient intelligence is that same robot pointed at knowledge work.

Right now almost everyone's AI is call and response. You have a question, you go to the model, it answers. Ambient intelligence watches and acts before you think to prompt it. That is the part that does not exist yet for most people, and it is why he argues you should be designing for it now rather than when the hardware shows up.

So start with your work, not with a spec sheet. A job belongs on local hardware when it clears four tests. It is always on: the value comes from checking continuously, not once. It is token-hungry: priced per token it would be absurd, which is exactly why nobody is doing it. It is time-agnostic: it does not matter whether it runs at 4pm or 4am, it is worth the same either way. It does not need frontier judgment: a model three months behind the frontier does it well enough that you would still ship the result.

Then run the exercise he gives everybody. His own to-do list lives on pieces of paper on his desk, and that is the format. Spend one day writing down every task you do, as you do it. Managing the community. Writing the posts. Recording the video. Programming. Answering that. Then hand the whole list to the smartest model you pay for and make it tell you what to offload.

‍

‍

• Spend one working day writing down every task you do, in the moment, not from memory.
• Mark every task that would be worth more if it ran every hour instead of once.
• Cross out anything that needs frontier-level judgment to be worth doing at all.
• Paste the list into your best frontier model and run the reverse prompt above.
• Pick the single highest-value survivor. That is your first ambient loop.

Pro Tip: Write the list as you go, not at the end of the day. The tasks you forget are the repetitive ones, and the repetitive ones are the whole point.

Checkpoint: You have a written list of your actual work, and one job on it that is clearly worth more running continuously than it is running once.

‍

"If you now have unlimited 24/7 intelligence, you can create what I'm calling ambient intelligence... You can't do these types of use cases with Opus, with Fable, because you're gonna have a $20,000 bill at the end of the month."
‍— Alex Finn

Memory decides which models you can run. Bandwidth decides how fast they answer.

This is the question Alex gets more than any other: what computer should I buy? The answer starts with one fact. The model is loaded into memory — VRAM if you are on NVIDIA, unified memory if you are on a Mac — so memory sets the ceiling on how big a model you can run at all. Bandwidth is the other half. It governs how much of the model can move at once, which you experience as speed.

That gives you four tiers, and at consumer prices you are picking big or fast, not both.

The computer you already own. The Mac Mini gathering dust, the old laptop. You will not run frontier here, or anything close to it. But Google has put real research into small efficient models, and a Gemma 4-class model runs on nearly anything. That is enough to do embeddings, handle small vertical tasks, or act as the memory system for a personal agent like OpenClaw. Cost: nothing.

The AI workstation. A DGX Spark is plug-it-in-and-it-is-an-AI-computer: medium unified memory, decent speed, no build required. It went up to roughly $4,800 from $4,000. Alex's read is that with Mac Studio prices where they are, this is the sweet spot for most people starting today.

The high-memory Mac. His three Mac Studios carry 512GB each and cost $10,000 apiece. That much unified memory runs GLM 5.2 — Opus 4.8-class intelligence — on a single machine. The catch is bandwidth: big model, slower answers. The bigger catch is that you cannot buy one. Apple stopped selling the large configurations, the top config is now 96GB, and resale runs three to four times list. He told people in January to buy them before they disappeared and that call was right, which is not the same as it being useful advice today.

The powerhouse GPU. He built a machine around an RTX 5090, a $4,000 chip in a roughly $9,000 build that doubles as the box he games on at night. Lower VRAM, very high bandwidth, so it runs smaller models faster than cloud frontier can answer. A Qwen 3.6 29B on a 5090 gets you about Sonnet 4-level intelligence, unlimited, at speeds frontier cannot touch. It cannot run GLM 5.2 at all — not enough room. The RTX 6000 Pro is the $15,000 version of this tier, and it buys the VRAM back.

‍

• Write down the memory footprint of the model your first job actually needs.
• Decide which you need more: a bigger model or faster answers. You are picking one.
• Run your first loop on hardware you already own before you spend anything.
• If it works and you are starting from zero, price a DGX Spark-class workstation next.
• Skip resale Mac Studios at four times list unless only a 512GB box can run your job.

Pro Tip: A week on the dusty Mac Mini will teach you more about your own use case than any spec sheet will. Alex's position is that the device barely matters at the start: no matter what you already have, get into local AI on it.

Checkpoint: You can name the tier you are buying into, the model you intend to run on it, and the one job it runs first.

‍

A pile of computers is not a fleet until they can reach each other.

Alex runs three Mac Studios, a DGX Spark, the 5090 build, and a stack of Mac Minis. Exactly one of them has a monitor attached. The rest sit on a shelf plugged into an outlet, headless, and he does not expect to look at them again.

What makes that work is Tailscale. It puts every device on one private network, so his agent can sit on Mac Studio 1 and reach into the shell of the DGX Spark — effectively root access — run its CLI, pull a model down from Hugging Face, load it into memory, and start handing it tasks. Without the network you own a room full of expensive single-player computers. With it you own one machine with many bodies.

He had never networked a computer before doing this.

‍

• Install Tailscale on every machine you want in the fleet, including the one you sit at.
• Confirm you can reach each machine's shell from your main box before installing any model.
• Unplug the monitors from everything except the machine you actually drive.
• Keep the tailnet to hardware you own, and keep production secrets off the boxes your agents can reach.

Pro Tip: Be clear-eyed about what you just built. Root access between every box is exactly what makes the agent useful, and it is also the blast radius when an agent goes sideways. That trade is fine on your own hardware on your own tailnet. It is a different conversation the moment customer data lives on those machines.

Checkpoint: From one machine, your agent can list, reach, and run a command on every other machine in the fleet.

‍

Alex has never loaded an AI model by hand. His agent does it.

Knowing which workload belongs on which model is the genuinely hard part of local AI, and it is where most people stall. There is no clean answer yet. Routers exist, but working out what your particular jobs need is trial and error in the dark.

His answer is to not do it himself. He runs two agents: OpenClaw, the personal agent that knows him, and Hermes, which he calls his IT guy. Hermes runs on frontier intelligence and has the run of the tailnet. When a new model ships, the instruction is roughly: go onto the DGX Spark, load up these five models, run an eval on each one, and give me a report on their strengths and weaknesses. He comes back a couple of hours later to a finished report.

Because Hermes knows his businesses and what he does day to day, the report is not a benchmark table. It is a routing decision — run this task on the Mac Studio with this model, run that one on the 5090 — and the dashboard that watches the whole fleet was built by Hermes too.

‍

• Give your best frontier agent a written map of your hardware: machine, memory, bandwidth.
• Have it research current open-weights models per machine instead of picking from memory.
• Make it run evals against your real tasks, not public benchmarks.
• Require the deliverable as a routing table: this task, this model, this machine.
• Re-run the whole exercise every time a notable open-weights model ships.

Pro Tip: Insist the evals run on your own work. A model that tops the public leaderboards and then fumbles your actual inbox is the wrong model, and only your own tasks will tell you that.

Checkpoint: You have a routing table you did not build by hand, and you can regenerate it in an afternoon when the next model lands.

‍

"I still haven't loaded an AI model locally in my entire life. My Hermes does it all for me."
‍— Alex Finn

One job, on a timer, running forever. Not a chat window.

This is where owning the hardware starts paying. Alex's fleet works around the clock, and what is actually running is unglamorous on purpose.

Security surveillance. Every hour or so, a local model picks a different API endpoint across his products and runs a quick security check. Anything wrong here? Anything worth flagging? Then it moves to the next endpoint and does it again, forever.

Code review nobody assigned. Every twenty minutes, another model reads a different part of the codebase looking for anything to optimize or clean up.

Database anomaly watch. Another model sits on the database hunting for the weird: usage spikes, accounts behaving strangely, churn risk it can act on by sending the email itself.

Signal scraping. Every hour, models go read Twitter, Reddit, Hacker News, and Product Hunt looking for trends and for the problems people keep complaining about, then hand back business opportunities, software worth building, and content worth writing.

None of it needs to be brilliant. It needs to be relentless, and it needs to be pointed at something you actually care about. And this is not only an engineering trick. Point the same pattern at a community and you get an agent that reads every message, reports back, and turns the week into a guide.

‍

• Take one job from step one and give it a fixed interval: every twenty minutes, hourly, or nightly.
• Write down what it watches, what it flags, and exactly where the output lands.
• Let it run for a week untouched, then read everything it produced.
• Retune or kill the loop if a week of output gave you nothing you acted on.
• Only add a second loop once the first one has earned it.

Pro Tip: Send the output somewhere you already look — the inbox, the channel you cannot ignore. A report nobody reads is not leverage, it is a hobby.

Checkpoint: One loop has run for a week without you touching it, and you can point at something it caught that you would have missed.

‍

Local is not a replacement for frontier. It is a second pair of hands that never sleeps.

Alex gets attacked from both directions for this. He will post that Fable is incredible and get told he is supposed to be the Mac Studio guy. His actual position is narrower than the internet wants it to be: we are nowhere near the point where you can be 100% dependent on local models.

Local models are slower, especially below an RTX 6000. They are not as smart. GLM 5.2 got close to Opus 4.8 and is still behind Fable. And the computers cost real money up front. What local buys you instead is three things frontier cannot. Cost: you pay for electricity rather than a tollbooth on every token. Privacy: your data never leaves the building, which is not true when you build with Claude Code or Codex. Volume: nothing is metered, so nothing has to be justified.

So the split is not ideological, it is arithmetic. Put the always-on volume where tokens are free. Keep the hard calls where the intelligence is best.

Then do the math honestly, because both halves of it are real. His ambient workload on frontier would run thousands of dollars a month: he already maxes out a $200 Claude Max plan that by his read delivers around $3,000 of tokens, and he does more work than that locally on top of it. The step-five use cases would be a $20,000 monthly bill on Opus. The electricity to run the fleet took his California bill from roughly $150-160 a month to about $200-220 — call it $50 or $60 for work that would otherwise be a hiring decision. The part he does not dodge: the computers were tens of thousands of dollars up front.

The reason he thinks that capex is a bet worth taking is the trend, not the moment. Local models were unusable two years ago, six months behind the frontier last year, and roughly three months behind now. He points at Fable leaving subscription pricing for per-token input and output, a change he dated to July 7, as the tell for where all of this is heading. Local models do not have a per-token price. And the hardware you already bought only gets more capable as the models get more efficient.

‍

• List the jobs where being three months behind the frontier costs you nothing. Those go local.
• List the jobs where privacy alone decides it: code and customer data you cannot send out.
• Keep the hard calls on frontier and stop apologizing for paying for them.
• Price your ambient workload at frontier token rates once, honestly, before buying hardware.
• Check your electricity bill a month in and compare it to the token bill you avoided.

Pro Tip: Run the token math before the hardware math. If your ambient workload would only cost $40 a month on frontier, buy nothing and use frontier. The case for owning the hardware only exists at volume, or when the data cannot leave.

Checkpoint: You can say in one sentence each what runs local, what stays frontier, and what the split saves you per month.

‍

"I think six months from now you're having Fable level intelligence running on consumer hardware... So you need to be able to come up with now what use cases you can do with ambient intelligence that runs 24/7."
‍— Alex Finn