Darwin explains AI · 08

You gave Darwin a brain. But can it use his hands?

Local AI versus cloud AI: why a model that holds a perfectly good conversation may still struggle to open Notepad — and how to choose the right brain for the job.

Previously in this series — The most dangerous AI feature is unlimited permission ›

Written by Gabriel · founder of BlueberryS, developer of Darwin

It knew exactly what to do. It just didn't do it.

I recently ran into a problem that illustrates, almost perfectly, something many people misunderstand about AI assistants. The task could not have been simpler: open Notepad. Darwin was running on a local AI model with 32 billion parameters — not a toy, but a substantial piece of technology running directly on a personal computer.

Instead of opening Notepad, the model wrote open_app("Notepad") straight into the conversation. It looked like an instruction to open the application, and it even had the right application name in it. There was just one problem: Notepad didn't open. On another attempt it might work; on the next one it might not.

Then I tried the same kind of task with Gemini, and Notepad opened within seconds. Same computer, same Darwin, same tools. A different brain. So what actually happened?

The brain doesn't have hands

This is probably the single most important thing to understand about modern AI assistants. A large language model does not operate your computer. It generates responses, interprets instructions and — when it is trained for it and properly connected — it can ask external tools to perform an action. But opening an application, editing a file, sending a message or running a command takes real software.

That is where Darwin comes in. We build the tools, the integrations, the memory, the permissions and the execution around the model. The model decides what it wants to do; Darwin provides the tools that can do it — within the user's permissions and the application's security controls, which is what the previous article was about.

The intelligence comes from the model. The ability to act comes from the software around it.

And connecting the two reliably is harder than it sounds.

Five people, five tools, one simple instruction

Imagine putting five people in a room and giving each of them a pen, a hammer, a sheet of paper, a drinking glass and a table. Then you say: write your name on the paper. One of them picks up the pen and writes. Another reaches for the pen and then stops, unsure what comes next. A third explains in detail how writing works but never touches the paper. A fourth picks up the wrong tool entirely. They all had exactly the same equipment — the difference was never the tools, it was the ability to understand them and use them.

AI models are much the same. One model understands that opening Notepad means calling a particular tool and handing it the application name in a precise format. Another produces text that merely looks like a tool call. To a human the two may look almost identical. To the software they are fundamentally different things.

Text that looks like a command is not automatically a command — and in a well-designed system it must not be. That distinction matters for reliability, and just as much for security: you do not want an assistant that executes anything that merely resembles an instruction.

"But my local model has 32 billion parameters!"

A fair objection, and 32 billion is a lot. But the parameter count doesn't tell you everything a model can do. Think of two people: one has read thousands of books and can talk about almost anything; the other knows less about the world but can repair an engine, run machinery and carry out complicated practical instructions. Which of them is more capable depends entirely on the task.

Models differ in their training, architecture, reasoning, how they handle context and how well they support structured tool calls. A bigger model is not automatically better at every operation, and a smaller model trained specifically for tool use can beat a larger general-purpose one on exactly that kind of work. So the right question isn't how big is this model? It is: can this model reliably do the kind of work I want Darwin to do?

Why opening Notepad can be harder than answering a question

For conventional software, opening an application is trivial: once the program receives a valid command, it is a straightforward operation. An AI agent adds a step in front of that. The model has to recognise that you want an action rather than an answer, pick the right tool, build the correct arguments and return all of it in a format the surrounding software understands — and it has to do so consistently. A model can understand your intention perfectly in plain language and still fail to produce a valid structured call. That is exactly why an AI that writes beautiful answers is not necessarily an AI that operates software reliably.

To be fair, not every failed action is the model's fault. The cause can be a tool definition, model compatibility, execution permissions, operating-system restrictions or the integration between the model and the application. That's why we test these things rather than assume every failure has the same explanation. But when the same tool works consistently with one model and only sometimes with another, the difference in how those models use tools becomes an important clue.

So are local models bad?

Absolutely not — I wouldn't have built local-model support into Darwin if I thought they were useless. Local AI offers something genuinely valuable: control over where the model processes your information. In a fully local configuration, your prompts are processed on your own computer instead of being sent to a cloud AI provider, which matters when you work with private notes, sensitive documents, personal information or simply offline. And local models have improved enormously. Depending on the model and the hardware, they can handle conversation, summaries, classification, text processing, local knowledge retrieval, coding help and, yes, tool use too.

Local is not automatically the same as cloud

The leading cloud services run on far larger computing infrastructure, and they offer models tuned for complex reasoning, long workflows, programming and sophisticated tool use — capabilities that are hard to reproduce on an ordinary PC. That doesn't mean every cloud model beats every local one; it means you have to compare them on the tasks that matter to you. A local model that is wonderful at summarising private documents may stumble over a long chain of tool calls. A cloud model that handles complex automation well may be overkill for simple classification. And a carefully chosen local model can be excellent at a specific, narrow job. There is no universal winner.

What does "32B" actually cost to run?

Another misunderstanding I run into often: the model can be downloaded for free, so local AI must be free. The weights may indeed be free to download, depending on the licence — but running them takes computing power, and that is never free.

A powerful workstation can handle demanding models, but powerful hardware costs money, so does the electricity, and eventually the hardware needs replacing. For some usage patterns a suitable cloud subscription or API plan comes out cheaper; for others — especially people who already own suitable hardware and run substantial local workloads — running locally makes real financial sense.

Local doesn't automatically mean cheaper. Cloud doesn't automatically mean more expensive.

It depends on what you run, how often you run it and what hardware you already own.

Privacy is the strongest reason to go local

For me, the most compelling argument for a local model isn't saving a few euros. It is control. When you use a cloud model, the information a request needs is sent to that provider. That doesn't mean cloud providers handle data irresponsibly — many offer serious privacy, security and enterprise controls — but there is still an outside service involved. With a local model, the inference happens on your own machine. And Darwin's local memory is independent of whichever brain you pick.

One distinction is important, though: a local model does not automatically make the whole application offline. If you use external email, web search, cloud speech recognition, voice generation or other connected services, the relevant information still travels to those providers. Privacy depends on the complete workflow, not on the model name shown on the screen — which is why I think users should know which services they are switching on and what each of them actually does.

You don't have to choose one brain forever

This is one of the architectural decisions I consider most important in Darwin: the memory belongs to Darwin, not to the model. Imagine employing someone for several years. You teach them about your company, your projects, your preferences and the way you work — and then one day you decide to swap their brain for a different one. In a typical AI chat product, changing providers can mean leaving a large part of that context behind.

Darwin keeps its long-term memory separate from the selected model. When you switch from a local model to Claude, Gemini or an OpenAI model, what Darwin knows stays available. The new brain may interpret or use that knowledge a little differently, but the memory doesn't vanish just because the brain changed. You can even give different agents different models: a specialised agent can use a local model for private text work, another can use a stronger cloud model for complicated multi-step operations, and a coding agent can use a model built for development. The point isn't to have the biggest brain everywhere. It is to have the right brain for each responsibility.

Which brain should you choose?

Here is how I would approach it:

• Private notes, summaries and routine local text workA capable local model
• Offline conversations and local knowledge workLocal AI
• Opening applications, working across tools, everyday JARVIS-style tasksA model with proven, reliable tool calling
• Complex automations and multi-step processesA capable model, tested on the whole workflow
• Software development and debuggingA coding-oriented model with the right tools
• Sensitive work where data must not go to a cloud modelLocal processing — with external integrations reviewed separately
• Heavy daily use without buying high-end hardwareCompare subscription and API costs against your real usage

These are not rigid rules. A sufficiently capable local model can be excellent at tool use, and cloud models make mistakes too. Always test the things you actually care about. If opening applications matters to you, don't judge a model by how intelligently it talks about software — ask it to open the same application several times, then try a longer request with several steps, and watch whether the tools were really called, whether the task finished and whether the result is right.

An AI that explains what it would do is not the same as an AI that has done it.

What I would recommend to a new Darwin user

Don't start by asking which model has the most parameters; start by asking what you want your assistant to accomplish. If privacy and offline work come first, begin with a suitable local model. If you want Darwin to operate applications, run workflows and handle complex tasks, choose a model known to work well with structured tools — and check it in practice. And if you're not sure, start with one of the supported cloud models, learn how the tools and permissions work, and experiment with local alternatives afterwards. You don't have to give up on local AI, and you don't need to buy an expensive graphics card before you know what you actually need. Start with the work. Choose the brain afterwards.

The brain matters. But it isn't the whole assistant.

It is tempting to believe an assistant becomes great simply by connecting it to a powerful model. But the model is one component. The tools, the memory, the permissions, the integrations, the execution controls, the error handling and the experience of using it matter just as much. A brilliant brain with no reliable way to act is still limited — and giving a model more powerful tools doesn't automatically make it more competent, or safer.

That is why we keep developing Darwin itself rather than just adding support for the newest models: the infrastructure that turns those brains into useful assistants — tools that perform real actions, memory that survives a change of model, and boundaries that stay important no matter how capable the chosen model becomes. The goal was never to build one more place to talk to an AI. The goal was an assistant that actually helps you get things done — and sometimes, choosing the right brain makes all the difference.

Gabriel — Founder of BlueberryS, developer of Darwin AI Assistant.

Further reading — Part 04 · I cannot touch your files ›
Part 07 · The most dangerous AI feature is unlimited permission ›