I Tested Local LLMs and My MacBook Nearly Caught Fire

Introduction

I’m not a big fan of mainstream AI solutions. Partly because I’m a hipster who refuses to follow the crowd. But mostly because it’s expensive.

So, lately, a good chunk of my technical research has been focused on testing alternative agentic AI solutions—especially local ones.

Some things worked… Others, not so much.

Here’s the story of my adventures with local LLMs.

Configuration Preface

I’m the proud owner of a MacBook Pro M3 Max with 64GB of RAM. Back in my pre-AI days, I’d flaunt it shamelessly, boasting about owning an exceptional machine. Three years later, this poor beast is just powerful enough to do what I’d like with local LLMs.

I run my LLMs on LM Studio and mainly use OpenCode for the agentic part.

The Turning Point

Everything changed with Gemma 4. Specifically, its 26b-4b-thinking version (Bless you!). For the first time, I glimpsed the possibility of doing Spec-Driven Development locally on my Mac.

This is a Google model with 26 billion parameters, a Mixture of Experts (MoE) type with 4 billion active parameters.

If you’re wondering, a Mixture of Experts model is a language model where not all parameters are active at once. This allows running large models on resource-constrained machines without sacrificing too much quality.

For the first time, I could assign agentic tasks to a local model without waiting 3 hours for a result… and with a roughly decent outcome.

A Bit of Practice

By “decent outcome,” I mean:

• Understanding a localized need across 2-3 files.
• Not ignoring the context around the prompt.
• Reasoning about the task.
• And most importantly: producing code that compiles.

To give you a concrete example: without any special skills, Gemma 4 was able to break down a large Angular component into several smaller, modular ones while preserving the correct logic and dependencies…

But…

Angular is a relatively complex framework that has undergone major changes in recent updates.

The most obvious are the introduction of signals between components and the new template syntax:

@for (block of blocks(); track block.id) {
  <mon-joli-component [input]="block"/>
}

And that’s where things got a little tricky.

The LLM had successfully produced code that passed compilation… but using Angular’s old syntax (the one with *ngFor and observables), while the project used the new @for syntax and signals. An awkward mix of both eras.

Skills to the Rescue

So, at that point, I started implementing specific skills (okay, fine, I’d just disabled them earlier to test the bare-metal model).

Solution: a nice AGENTS.md file at the project root. I describe my general best practices + Angular skills (templates, components, services…). (Yes, my rule set is a bit more complex than that, but let’s move on.) Result: the generated code became much more consistent.

A small tip about writing skills: write your own, especially when describing your coding style. These skills represent your personal touch as a software engineer and are the best way to get results that suit you.

But… (Again)

You might be tempted to tell me that splitting a large component into 3 or 4 smaller ones, while nice, isn’t exactly the grand promise of agentic replacement that AI leaders sell us… and you’d be right.

So I decided to push further by preparing a large brief file that included a user story written by my PO, followed by a precise technical analysis of what I expected the LLM to do to implement it. This is something I do regularly when tackling a new user story, and it works very well with more powerful cloud-based LLMs.

This was a moderately complex user story that involved all layers of our app:

• Calling a new route to expose in an existing HTTP service (which I call a repository)
• Mapping the retrieved data to create a new business object
• Enriching a global store
• Using this new data in new components by connecting to the store (via signals if possible)

No data calculations, but a strict need to follow my development guidelines across multiple files.

Another tip: to best prepare my brief, I like writing the entire brief in a .md file that I store in a .scratch folder in my project. I then give it as a reference to OpenCode and let it run. This gives me more control over the quality and consistency of the information provided, and it’s easier to write than in the agent’s prompt window.

First pass in plan mode, and Gemma was able to perform a relatively satisfactory analysis of what it would need to implement. But things got a little messy during the implementation phase…

10 minutes later, my fans were screaming at full speed, my GPUs were flirting with 100°C… And then, Gemma proudly announced: “I’m done!”

Problem: It hadn’t even tried to compile the code. Yet, my skills clearly describe the validation procedure: linting, compilation, unit tests…

And upon reviewing the code, I quickly noticed big red lines everywhere in the newly generated files.

In broad strokes, yes, it had understood. But in the details, the code was riddled with errors and inconsistencies.

Verdict: Having to manually fix everything to make the code work? No, I wouldn’t have saved any time.

A bit of a letdown, then.

My conclusion at this stage is that agentic development is still too complex to be delegated to a local LLM with 26 billion parameters.

But! (Yes, Again!)

Out of curiosity, I took a look at what the neighbors were up to. Chinese LLMs, especially those from Alibaba, are rising fast.

And in the segment of LLMs that can run on a personal computer (with plenty of RAM and a decent GPU), their results outperform what American companies offer.

Enter Qwen

Qwen is the name of the language models developed by Chinese company Alibaba. They are open-source (up to version 3.7, at least). Their performance is impressive, and this across a wide range of sizes: from a few billion to several tens of billions of parameters.

So I restarted my experiments with their 3.6-35b-A3b model, also a Mixture of Experts.

Same scenario: user story + precise technical brief, plan + execution.

Results: better, but still imperfect.

I should have stopped there.

I probably should have done what everyone else does: get a Claude Code subscription for $200 a month and spend the rest of my days writing in a loop: Develop the feature: [10,000 lines of context], don't make mistakes, be awesome. But the arrogant nonconformist in me refused to admit defeat and had one last ace up its sleeve.

OpenSpec, My Love

If you’re not familiar with OpenSpec, it’s a framework for your agentic tool (Claude Code, OpenCode, Mistral Vibe, etc.) that enables Spec-Driven Development. I’ll probably write a blog post about it soon, but in short, it’s a tool that helps break down your project (user story or feature) into detailed specifications that your agent can follow to generate code more reliably and consistently. The agent goes through three phases:

• An exploratory phase based on the brief you’ve given it.
• A phase of writing specifications and tasks to achieve the desired result.
• A phase of generating code by following the established specifications.

Result: Fewer hallucinations, much more control over the model’s trajectory. The exploratory phase is a crucial moment where you can precisely guide the agent toward its future work.

So, a new test with Gemma + OpenSpec—and there it was!

Detailed specs, a precise plan, and much more reliable execution!

So I’m happy to announce that yes, it is possible to do agentic development in a fairly reliable way, locally, with the right tools and methodologies.

But There’s Still a Ways to Go

Successfully completing a simple user story in near one-shot with a local LLM? Possible. But that doesn’t mean you can cancel Copilot or Claude.

Computation Time

The computation time for my moderately complex user story was long. Exploration, writing, generation… The clock was ticking. And to be honest, if I’d focused a little, I think I could have been a bit faster typing everything by hand or using AI-assisted autocompletion modules in my IDE.

The Heat

My MacBook literally burned.

Several times, I saw spikes of 100°C for short periods on my GPU, and on average, expect 85-90°C throughout an agentic session. Frankly, it’s pretty anxiety-inducing to hear the internal fans screaming in agony while OpenCode burns through tokens—even if Apple’s M1+ processors can apparently handle up to 105°C safely, and 85-90°C is considered “okay” if given time to cool down between sessions.

Still, I think running my MacBook at max capacity for several hours every day is risky for its longevity. I bought a cooling pad to try to limit the damage (I’d also seen this one, but I figured I shouldn’t go overboard). It does help lower the temperature, but not enough to chain dozens of local LLM sessions. On a high-end desktop PC with water cooling, this problem would likely be far less pronounced.

Overall Quality

Even if the results are more than encouraging, it’s clear you won’t be able to ask your LLM to handle ultra-complex, massive tasks the way you could with Claude or GLM 5.

The Cost

Yes, it’s free and unlimited, but the entry price to expect decent results is still steep! As a reminder, I’m running on a MacBook M3 Max with 64GB of RAM, which cost me around €5,000 at the time. That’s expensive, and with RAM prices skyrocketing lately, don’t expect to find a powerful enough machine for good models below that price.

Conclusion

Verdict: I’m still pretty impressed by the tool.

Local LLMs handle simple to moderately complex tasks without breaking a sweat.

And the big plus for some: being able to work on a plane… which I do once a year, so not much use for me.

But beware—delegating everything to your local machine still seems premature.

The heat gives me anxiety. The battery melts like snow in the sun (45 minutes max at full power).

In the end, I think I’ll keep my LM Studio + Qwen 3.6 setup for specific cases of refactoring or simple tasks, since not all development scenarios require a flood of processing power. The results are satisfying in many cases, and it still saves a fair amount of tokens.

Bonus Models

• Ornith

  • A new line of models based on post-training of Gamma and Qwen 3.5, they seem to offer better performance. I’ve been testing them a bit as I write this, and the results are good, though I can’t yet say if they surpass Qwen 3.6.

• GPT-OSS

  • Tested briefly, but significantly inferior to everything discussed here.

• Qwen 3.6-27b

  • This is a dense version of the 35b-A3b model mentioned above. It delivers better results but is more resource-hungry and thus slower… a bit too slow for my use case. If I had a better machine with 128GB of RAM, I’d definitely use this one.