skip to content
▣ i-built-a-control-panel-for-llama-cpp.md — READING

~/blog/llama-cpp · August 1, 2026 · 4 min read

I Built a Control Panel for llama.cpp Because One-Click Apps Hide the Wrong Thing

#llama-cpp#local-llm#open-source#tools

GitHub stars GitHub forks GitHub issues License MIT Last commit

The easy local-LLM apps sell you one number: how fast you can go from download to a chat box. It’s a good number. It’s also the wrong one to optimize your whole tool around, and I got tired of paying for that trade every time I actually wanted to run a model well.

So I built LlamaForge, a graphical control panel for llama.cpp. If the badges above show a star count, that’s the repo. Go break it and tell me what’s wrong.

The setting you never see is the setting that was chosen for you

llama.cpp is the engine under most of the friendly desktop apps. It exposes something like 220 server flags: context length, KV-cache type, speculative decoding, tensor split, rope scaling, sampling, flash attention, the lot. That is not bloat. That is the difference between a model that fits your card and runs fast and a model that swaps to CPU and crawls.

The one-click apps make a decision here, and the decision is to hide almost all of it. They pick defaults, wrap them in a nice window, and call the absence of choices a feature. For a lot of people that’s exactly right. For anyone who has watched a 30-billion-parameter model go from unusable to genuinely fast because they set one cache flag correctly, it’s maddening. You didn’t get simplicity. You got someone else’s guess, frozen into the UI, with no dial to turn.

I don’t want the guess. I want the dial. That’s the whole disagreement in one sentence.

What the panel actually does

LlamaForge runs in your browser and gives you the engine with the flags left on.

Every model on the machine shows up in one list with live GPU meters, VRAM used and free, temperature, utilization. Expand a row and you get all the knobs, grouped and searchable, next to a GGUF metadata card that tells you the architecture, quantization, trained context, and layer count of the file you’re about to load. Save hot-reloads with no restart. A load that fails shows the real error inline with a suggested fix instead of burying it in a log you have to scroll.

Discover searches Hugging Face and rates every quantization against your actual VRAM before you download, FITS, TIGHT, or CPU OFFLOAD, so you stop grabbing a file that was never going to run. Build and Update tracks how far behind upstream llama.cpp you are and rebuilds with flags auto-detected for your CPU and GPU. There’s a Refine button that benchmarks knob variants with real completion requests and keeps the fastest one, which is the kind of thing I used to do by hand with a spreadsheet and swearing.

None of this is magic. It’s llama.cpp doing all the real work. LlamaForge is the surface that stops me hand-editing models.ini and pasting hundred-character llama-server command lines at eleven at night.

It is also an endpoint, on purpose

The panel serves your local models over both major APIs, the OpenAI-compatible /v1/chat/completions and an Anthropic-compatible /v1/messages shim, with streaming and tool use. One click wires up Claude Code, Codex, or pi.dev to point at your own machine. So the same models you tune in the list become the backend your coding tools talk to, scoped to localhost, with every file it touches backed up first. That was the point I actually wanted to reach, and the friendly apps make it hard because they treat the server as an implementation detail rather than the product.

Who should not use this

I’m going to talk myself out of a few installs here, and I think that’s honest.

If you want a double-click installer, no compile step, and a chat box in ninety seconds, LlamaForge is the wrong tool and I mean that plainly. Use LM Studio, Ollama, or Jan. They are good at the thing they are good at, and that thing is not what I built. LlamaForge assumes you’re willing to run one setup script and build llama.cpp for your own machine, both guided from the dashboard, but still yours to run. It’s an early preview. Windows with an NVIDIA GPU is the primary target, with Linux and Apple Silicon supported and rougher. Things will break.

If you read all that and you’re still here, we want the same thing. The whole project is MIT, it’s independent, and it is not affiliated with llama.cpp or ggml-org, who do the hard part and deserve the support. Clone it, forge a model into shape, and open an issue when a knob does something stupid. That’s the version of easy I actually care about.