Stop Paying Genius Prices for Intern Work

Somewhere in your business right now, a frontier AI model is answering a question an intern could have handled.

It’s summarising an email thread.
It’s reformatting a spreadsheet.
It’s extracting three fields from a PDF that a work-experience student could do blindfolded.
And you’re paying genius-hourly-rate prices for the privilege, every single time, forever. 🫤

This is the case for running a local LLM for business use, not as a novelty, but as the other half of your AI stack.

I want to talk about fixing that. Apple just made it noticeably cheaper to stop, and almost nobody running a small or medium business has actually worked out how.

Meet Your New Employees: A Local LLM for Business, Paired With the Frontier

Keep this mental model for the rest of the article. Everything below is just the same idea applied to different problems.

Treat your AI stack as two hires. The Architect is Claude, GPT, or Gemini… whichever frontier model you prefer. Brilliant, well-read, good at judgement calls, and billed at a rate that reflects all of that. You don’t ask the Architect to alphabetise the filing cabinet. You ask it to design the filing system once, properly, then leave it alone. 😉

The Intern is a local open-weight model (something like Qwen or DeepSeek) running on hardware that sits on your own desk rather than in someone else’s data centre. Tireless, cheap after the initial outlay, occasionally a bit literal-minded, and never allowed near a decision that actually matters. Give it clear instructions and a narrow task, and it will grind through a thousand of them without complaint, without a per-request bill, and without your client data leaving the building.

Most businesses right now employ only the Architect for everything and then wonder why the invoice looks the way it does. 🤷‍♂️

What Just Landed On Apple’s Doorstep

This is no longer theoretical. On 25 August 2026, Apple quietly refreshed the Mac Studio with the M5 Max and M5 Ultra, and refreshed the Mac mini the same day with the new M6 and M5 Pro. No keynote, just a newsroom post… very on-brand for a hardware update that happens to matter a great deal to anyone thinking about running AI locally.

The numbers that matter, because unified memory is the whole game when you’re hosting a language model at home:

• Mac mini (M6), from $899: up to 32GB unified memory, 170GB/s bandwidth. Fine for small models, not the star of this piece.
• Mac mini (M5 Pro), from $1,699: up to 64GB unified memory at 307GB/s. The sensible entry point for a serious local setup.
• Mac Studio (M5 Max), from $2,499: up to 128GB unified memory. Comfortably hosts most mid-size open models.
• Mac Studio (M5 Ultra), from $5,499: up to 512GB unified memory at 1.2TB/s bandwidth; the highest configuration lands around $15,000 when it ships in late October. Apple’s own bandwidth figure is 50% higher than the previous M3 Ultra generation, and TechCrunch reported Apple’s claim of up to 4.3 times the peak AI compute of the M3 Ultra.

The 512GB configuration is the headline grabber, since Apple markets it as able to hold models with over 600 billion parameters entirely in memory. Fitting in memory and running at a usable speed are two different sentences, though. We’ll get to that.

Is the Intern Actually Any Good?

This is the question that decides whether any of this is worth your time. If the Intern produces rubbish, the cost savings evaporate because you’ll spend the difference fixing its mistakes.

The honest 2026 answer: the Intern has become remarkably competent, with one asterisk* you need to understand properly.

Across most standard benchmarks, the best open-weight models now trail the best closed frontier models by roughly 5 to 15 points, according to tracking from Local AI Master’s 2026 comparison. On some coding benchmarks, open models have briefly taken the top spot before a frontier release reclaimed it. The gap that refuses to close is abstract reasoning, where the difference widens to roughly 17 points on tasks like ARC-AGI-2.

In plain language: the Intern is now really good at recognisable, patterned work and still noticeably weaker at novel problems nobody has seen the shape of before.

Now the asterisk* 😅. A lot of the local models posting the flashiest tokens-per-second numbers are Mixture-of-Experts models.

Imagine hiring what’s advertised as a 35-person consulting firm, except only three of those consultants actually show up to answer any given question while the other 32 stay in the break room. That’s roughly how a 35B-parameter MoE model with 3B “active” parameters behaves. It’s fast precisely because most of its supposed size never gets used on any single task, brilliant for speed, a little misleading if you were expecting 35B of raw capability. One practitioner testing Qwen3.5-35B-A3B on an M5 Max measured 112 to 134 tokens per second while flagging exactly this caveat about what “35B” is actually doing under the hood.

Quantisation (the process of shrinking a model to fit in less memory) also isn’t free. Dropping a model like Qwen3 235B to 4-bit precision costs it roughly 2 to 3 benchmark points, according to testing from Contra Collective. Not catastrophic. Not nothing either. Budget for it.

The Intern’s One Real Weakness, And It’s A Doozy

Here’s the part almost nobody mentions when they’re excited about running AI at home, and it’s the single most important technical fact in this article. So, keep reading. 😅

Apple silicon is absurdly fast at generating text (one word after another) because that process is limited mostly by memory bandwidth, which Apple has spent three chip generations getting very good at. Before a model can generate a single word of reply, though, it first has to read and digest your entire prompt: every instruction, every document you’ve pasted in, every line of code in context. That reading step is limited by raw compute, not bandwidth, and this is where Apple silicon has historically struggled.

Think of a brilliant but slightly old-fashioned librarian. Once she’s found the right shelf she can recite the contents of any book from memory at blistering speed. Every time you hand her a new stack of reference material, though, she insists on reading the entire stack from page one before she’ll say a word, and that reading process is slow. Hand her a short note, and she’s instant. Hand her your entire case file, and you’re making tea while she works through it.

EXO Labs measured exactly this on the previous-generation M3 Ultra: processing a 15,777-token prompt took 227 seconds, and generation speed collapsed from 21 tokens per second down to under 6 as the context grew. That’s the difference between a tool that feels instant and one that makes you question your life choices while it thinks.

This is precisely why the “cheap AI coding assistant” dream doesn’t fully work yet on local hardware, however tempting the maths looks. Coding agents constantly re-read huge chunks of your codebase before every response… the exact workload that exposes this weakness. Apple knows it, which is why the M5 generation’s headline internal improvement is prompt-processing speed rather than raw generation speed. Early Apple figures claim roughly 4 times faster prompt processing than the previous chip; independent verification wasn’t available at the time of writing, so treat that as a promising claim rather than a settled fact.

The practical takeaway: give the Intern short, focused tasks with modest context, and it flies. Hand it your entire sprawling agentic coding session, and you’ll be waiting.

How The Handoff Really Works

This isn’t a new idea dressed up in new hardware. Researchers have been studying exactly this split for years under names like model routing and LLM cascades. The results are worth knowing because they show what’s actually achievable.

A 2023 Stanford paper called FrugalGPT showed that intelligently cascading between cheap and expensive models could match GPT-4’s performance at up to 98% lower cost. A follow-up open-source project called RouteLLM, from the team behind the LMSYS leaderboard, built a practical router that achieved 95% of GPT-4’s quality while cutting costs by over 85%. The pattern holds. You can send most of your volume to the cheap option without quality collapsing, as long as you’re honest about which tasks belong where.

In practice, the routing decisions fall into three flavours. Classifier routing tags each incoming task before it starts and sends predictable, well-understood work straight to the Intern. Cascade routing tries the Intern first and only escalates to the Architect when the Intern’s confidence looks shaky… particularly useful for background, non-urgent batches. Semantic routing matches a task to a topic and a pre-assigned model based on what that topic has needed historically.

On the tooling side the unglamorous but effective 2026 stack is LiteLLM sitting in front as the routing gateway, talking to Ollama for the local half. Ollama quietly started using Apple’s own MLX framework under the hood from version 0.19 onward, which closed a lot of the old “local AI is slow on a Mac” complaints. You can configure LiteLLM with a blunt rule: anything tagged as containing personal data never leaves the building. That turns your privacy policy into something the software actually enforces rather than something a junior developer has to remember at 5 pm on a Friday.

What belongs with the Intern: bulk data extraction, reformatting, classification, summarising large volumes of text, indexing your documents for retrieval, and answering questions against your own private knowledge base. What stays firmly with the Architect: anything novel for real, multi-step planning, the final sign-off on anything a client will see, and any task where being confidently wrong would be expensive.

The Argument That Wins This: Compliance, Yeah

I’ll be straight before we get to the money, because the money section is going to disappoint some of you slightly. The strongest reason to do any of this isn’t your API bill, but what happens to your data.

When you send a client’s personal information to a cloud AI provider, several inconvenient facts arrive at once. The provider may be based in, or have infrastructure connected to, the United States, and the US CLOUD Act allows American authorities to compel a US company to hand over data it holds, regardless of where that data physically sits. You’ve also created a cross-border data transfer, which under GDPR needs its own careful justification. None of this makes cloud AI unusable. It does mean you’re carrying a small mountain of paperwork and legal exposure that a locally hosted model simply removes at the source, because the data never leaves your building. Is that simple.

The European Data Protection Board’s Opinion 28/2024, adopted in December 2024, is the current authoritative EU guidance on personal data inside AI models. It’s deliberately cautious. It repeats the phrase “case by case” sixteen times and offers no single blanket rule, which tells you how seriously regulators expect you to think about this rather than tick a box and move on. Legal analysts reviewing that opinion consistently land on the same conclusion: on-premise or self-hosted inference is the strongest available position under GDPR, precisely because it removes the cross-border transfer question entirely rather than trying to justify it after the fact.

The EU AI Act adds its own layer. The original text set general obligations for 2 August 2026. An amending “Digital Omnibus,” in force from 27 July 2026, pushed the higher-risk deadlines out to 2 December 2027 and 2 August 2028 depending on category. If your business touches anything in a sensitive category, that’s useful breathing room, but it’s breathing room to prepare, not permission to ignore it.

Hosting a model locally does not make you magically compliant. You still need a proper legal basis, a data-protection impact assessment, and sensible security controls around the machine sitting in your office. What local hosting buys you is the single biggest risk factor removed before you’ve written a word of policy. For a small business without an in-house legal team, that is not a small thing.

Let’s Talk Money Anyway, The Honest Version

Right, the bit that made you click to this article 😉. Here’s the honest version, not the version that sells more Mac Studios.

The breakeven maths depends entirely on how much you’re currently spending and how much of that volume can actually move to the Intern. Industry estimates from practitioners at Prem AI put the rough threshold at around 1 million tokens processed per day. Below that, cloud APIs usually stay cheaper once you honestly account for the time spent maintaining your own setup. Above it (and especially if you’re consistently spending $300 to $500 a month or more), the hardware starts paying for itself within roughly three to twelve months, depending on the model.

Electricity, reassuringly, is not where this falls apart. A Mac Studio running eight hours a day costs somewhere around $11 a month in the US, roughly double that across most of the EU where electricity prices run higher. Genuinely trivial next to a five-figure hardware purchase.

Here’s where I want to inject some Matt-Levine-grade honesty. Forbes ran the actual numbers on the coding-assistant use case (the one everyone gets most excited about), and the result is a little deflating. A $200-a-month coding subscription against a roughly $4,800 128GB Mac Studio only breaks even around year three, while running models that are measurably weaker at exactly the agentic coding work you bought the subscription to do. For that specific, context-heavy, prefill-punishing workload, the honest conclusion is that you’re buying privacy, not savings.

The picture flips for the workloads this article is actually about. Bulk extraction, summarisation, classification, RAG over your own documents… these are exactly the tasks where local models perform well and where the token volumes tend to be enormous, because you’re often processing the same kind of document hundreds or thousands of times a month.

When You Should Absolutely Not Do This

I’d be doing you a disservice if I only told you the flattering half of the story, so here’s the unflattering half.

Running your own model is genuine maintenance work, not a one-off purchase you forget about. Realistic estimates put ongoing upkeep (updates, monitoring, the odd 11 pm troubleshooting session) at somewhere between five and ten hours a month, even for a stable setup. Multiply that by whoever’s hourly rate is doing the work and quietly add it to your cost calculation. It never shows up in the marketing material.

Storage adds up too. A 70-billion-parameter model can run to around 140GB at full precision, closer to 40GB once quantised, and you’ll want more than one version around while you test whether a new release is actually better or just newer.

Security doesn’t take a holiday just because the model lives on your premises. Prompt-injection attacks work the same against a model in your office as one in the cloud, and tools like Ollama and LM Studio don’t ship with the safety filtering that commercial cloud providers build in by default. Running locally moves that risk onto your side of the fence; it does not remove it.

And if your actual bottleneck is variety rather than volume, such as lots of different, unpredictable, low-frequency requests rather than the same document type processed a thousand times, the Intern doesn’t have enough repeated pattern to be efficient at. In that case, you should probably stay put.

The Actual Playbook

If you’ve read this far, here’s what I’d would do, in order.

1. Measure before you buy anything. Two to four weeks of logging what you’re actually spending and on what kind of task, before a single euro goes on hardware.
2. If you handle client personal data, treat this as a compliance purchase first. A Mac mini M5 Pro or entry Mac Studio pays for itself in reduced legal exposure alone, independent of the token maths.
3. Split the work using the Architect and Intern framework, not vibes. Bulk, repeatable, low-stakes work to the Intern. Anything novel, high-stakes, or client-facing stays with the Architect.
4. Build a small test set before you trust anything. A few hundred real examples per task type, checked properly, before you let the router make that decision unsupervised at scale.
5. Revisit the split every quarter. Open models are improving month to month right now, and last quarter’s “keep this with the Architect” call might be safely handed to the Intern by next quarter.

The Bit Where I Tell You What I’d Do

If you’re an SME sitting on client data and a growing AI bill, I’d buy the hardware for the compliance case and treat the token savings as a really nice bonus rather than the headline reason. If your main draw is a cheaper coding assistant specifically, I’d wait, since the current generation of local hardware is still measurably weaker at exactly that workload, however good the spec sheet looks.

Everything else, such as the boring, repetitive, high-volume grinding that makes up most of what actually costs you money every month, hand it to the Intern. That’s just finally paying the right price for the right work.