Adrianbeta
← All posts

Which local coding model actually fits your machine

· updated

The number that decides whether a local coding model runs on your machine is not its parameter count — it is your RAM. A 7B model and a 7B model can want wildly different amounts of memory depending on how they were quantised and how much context you give them, and a model that does not fit does not run slowly. It fails to load, or it swaps to disk and becomes unusable.

Running models locally is free and private, and it is the part of Adrian that needs no account and no card. Adrian ships a curated catalog rather than pointing you at the whole of Ollama, and every entry carries a download size and a minimum RAM requirement. The groupings below come from that catalog: twenty coding models and twenty-two design models, each with the figures the app uses to decide what to recommend on your hardware.

What "minimum RAM" actually means

The download size and the memory requirement are different numbers, and the gap between them is where most bad advice lives. Weights are the floor, not the total. Three things sit on top of them.

  • The weights themselves, which is the download size you see in the catalog.
  • The context window — every token you feed the model, plus everything it has generated so far, held in memory for the length of the request. This is the part people forget, and in an agentic build it is not small.
  • Everything else your machine is doing. The operating system, your browser, the editor, and the app running the build all want their share.

That is why the catalog's minimum RAM figure is consistently higher than the download size — Qwen2.5 Coder 7B is a 4.7GB download that asks for 12GB RAM. It is not padding. It is the difference between loading a model and being able to use one while your computer does anything else.

Why the sizes are smaller than you expect

Every model in the catalog is quantised — stored at reduced numerical precision so the weights take less memory. Most entries are Q4, some are Q4_K_M, and GPT-OSS 20B ships as MXFP4. In practice this is what makes local coding viable at all: full-precision weights for a 20B model would not fit on a consumer machine, and the quantised build does, at a quality cost that is real but much smaller than the memory saving.

It also means parameter count alone tells you very little. A quantised 22B model can have a smaller memory footprint than a less aggressively compressed 14B one. Compare the actual figures, not the names.

8GB — small models, real but limited

At 8GB you are working with models between roughly 1B and 4B parameters. They are genuinely useful for scaffolding a component, renaming things coherently, or drafting a small utility. They are not going to carry a multi-file feature on their own.

  • Qwen2.5 Coder 1.5B — 1.1GB, the lightest coding model in the catalog.
  • Gemma 3 1B and Gemma 3 4B — 0.9GB and 3.3GB.
  • Llama 3.2 1B and 3B, Phi-3 Mini, Qwen2.5 3B — all under 2.5GB.

Worth saying plainly: of the twenty coding models in the catalog, exactly one runs at an 8GB floor. The rest of that list is design and general-purpose models. If you are on 8GB you can absolutely build with Adrian, but you are choosing from a genuinely narrow shelf on the coding side, and the honest expectation is scaffolding rather than whole features.

12–16GB — the practical sweet spot

This is where local coding stops feeling like a demo. 7B-class coding models fit comfortably, and at 16GB a few genuinely strong 20B-class models come into range. If you are buying or upgrading a machine specifically to run this kind of work, 16GB is the point where the money stops buying disappointment.

  • Qwen2.5 Coder 7B — 4.7GB, 12GB RAM. The catalog's recommended default for builds, and the one to start on if you are unsure.
  • DeepSeek Coder 6.7B — 4GB, 12GB RAM, with solid React and TypeScript output.
  • Ornith 1.5 9B — 6.6GB, 12GB RAM, tuned for tool use and multi-step coding, with vision and a 256K context window.
  • Codestral 22B and GPT-OSS 20B — 13GB each, 16GB RAM. The first is a fill-in-the-middle specialist built for low-latency completions; the second is open-weights with configurable reasoning.

20–32GB — large models on one machine

Above 16GB the catalog opens up to models built for multi-file work rather than single components — repo exploration, coordinated edits across several files, and step-by-step reasoning on logic-heavy problems.

  • Qwen3 Coder 30B A3B — 18GB, 24GB RAM. A mixture-of-experts model with only 3B parameters active at a time, which is why a 30B-class model is usable at this tier at all.
  • Devstral Small 24B — 14GB, 24GB RAM, an agent-scaffold specialist aimed at repo exploration and multi-file edits.
  • Qwen2.5 Coder 32B — 20GB, 32GB RAM, the strongest single-machine coder in the catalog.

128GB and up

The catalog does list frontier-scale local models — DeepSeek R1 671B, Kimi K2.6, GLM-5.1, Qwen3 Coder 480B. These want 128GB of RAM or more and hundreds of gigabytes of disk. They are there for workstations and multi-GPU rigs, not laptops, and for most people the realistic route to a model of that class is an API key rather than hardware.

A long context window is not free

Context windows in the catalog run from 32K to 1000K tokens, and that range matters more in a build system than in a chat. An agent that reads several files, plans, generates, and then re-reads its own output to check it fills a context window far faster than a person asking a question does.

The practical consequence: the minimum RAM figure assumes reasonable use, not maximum. If you are running a model near its stated floor and pushing a very long context, you will feel it. Headroom above the minimum buys you more than the next model up often does.

You are choosing two models, not one

Coding and visual design are different skills, and the models good at them are different models. Adrian assigns a coder and a designer separately, by capability rather than by whatever happened to be installed first — which is why the catalog carries both a coding list and a design list. Budget memory for the pair, not for one, and check the design side too if you care what the result looks like.

The honest part

Structure closes some of the gap. Adrian wraps whatever model you choose in planning, tool use, self-review and a compile check, which is why a 7B model inside a build system beats a 7B model answering in a chat box. It does not close the gap entirely. A small local model supervised by a real pipeline is a good free option, not a secret equal of a frontier model.

Nor is a bigger model automatically the right call. A 32B model that takes four minutes per iteration on your hardware can be worse to work with than a 7B that takes forty seconds, because building is iterative and you pay that cost on every pass. Speed is part of quality when you are going round the loop twenty times.

Where to start

Check your RAM, then take the recommended default for your tier rather than the largest thing that technically fits. Adrian reads your memory, VRAM and free disk on first run and recommends models that will actually load, which is a faster route to a working setup than picking from a list. Running it locally walks through the rest of the setup.

If your machine is on the lower end, the other free route is bringing your own API key — you pay your provider directly and Adrian takes no cut of that bill, and the cost comparison covers when that is the better trade. The hosted plans exist for when you would rather not manage either.