opencode VS llama.cpp

Dax, the creator of OpenCode — an open-source coding agent, of all the people one might expect to disagree — put the case for hand-coding cleanly in a recent interview about Spec-Driven Development:

Pipa is our agent for studio operations at Lunch Pail Labs. She lives in Slack, is powered by E2B sandboxes, and uses OpenCode for the harness.

One reason I liked OpenSpec more than others, such as Kiro and SpecKit, is that OpenSpec is highly portable between coding assistants, codebases and stages of development. I've plugged OpenSpec into all sorts of projects, from infrastructure to Python libraries. I also work on diverse codebases, with a variety of AI friends that OpenSpec supports: OpenCode, Codex and Claude Code.

Beyond the big names, I would also keep an eye on OpenCode and T3 Code. OpenCode is a solid open-source, terminal-first option if you want a model-agnostic agent and bring your own provider setup. T3 Code is interesting for the opposite reason: it gives you an open-source GUI on top of the agents you may already pay for, like Claude Code, Codex CLI, OpenCode, or Cursor.

Brought to you by the infamous creator of OpenCode, who will exfiltrate all your data, then feign ignorance:

https://github.com/anomalyco/opencode/issues/10416

In my build, MTP came from mainline llama.cpp, not ik_llama. ik_llama got me to ~47 (engine + quant), but I couldn't get MTP running there — my build rejected the -mtp flags and ignored the model's nextn tensors. Mainline llama.cpp added MTP fairly recently (PR #22673, merged 2026-05-16), and that's where it worked for me. (There may well be an ik_llama path I missed — this is just what got it going on my box.)

That script grew up. Today I'm releasing LlamaStash, the first public release of a fast, cross-platform, terminal-native launcher for llama.cpp with zero overhead.

LlamaStash spawns the unmodified upstream llama-server. So three different questions follow from that, and there is a benchmark suite for each.

llama.cpp includes a benchmarking tool called llama-bench https://github.com/ggml-org/llama.cpp/blob/master/tools/llam...

ik_llama includes llama-sweep-bench https://github.com/ikawrakow/ik_llama.cpp/blob/main/examples...

When comparing hardware, the output of these tools is very helpful to let others put it into context. The post says the output is "reading speed" but knowing the prefill and token generation speeds would be a lot more helpful.

lol the same way we implement all of the reduced precision fp8, fp4 types today: by storing them in the corresponding uint:

https://github.com/ggml-org/llama.cpp/discussions/15095

# Build llama.cpp with Metal backend git clone https://github.com/ggml-org/llama.cpp cd llama.cpp && cmake -B build -DGGML_METAL=ON && cmake --build build -j # Community-quantized GGUFs (Google ships safetensors; unsloth ships GGUF) huggingface-cli download unsloth/gemma-4-31B-it-GGUF \ gemma-4-31B-it-Q4_K_M.gguf --local-dir . huggingface-cli download unsloth/gemma-4-26B-A4B-it-GGUF \ gemma-4-26B-A4B-it-Q4_K_M.gguf --local-dir . # Benchmark: 200 generations of 512 tokens, log per-call timing ./build/bin/llama-bench -m gemma-4-31B-it-Q4_K_M.gguf -n 512 -r 200 -o json > dense.json ./build/bin/llama-bench -m gemma-4-26B-A4B-it-Q4_K_M.gguf -n 512 -r 200 -o json > moe.json

git clone https://github.com/ggml-org/llama.cpp.git cd llama.cpp cmake -B build # Build project (e.g., -j4 for 4 cores, or -j$(nproc) for all cores) cmake --build build -j