I benchmarked local models for agentic coding (not chat): does the model call a tool with well-formed arguments, survive a multi-call loop, read a folder, edit a file and verify its own change. Public leaderboards measure single-shot answers, so I built a harness around the question I keep coming back to: which GGUF should I load before I start working? Every model runs the same harness: 18 tool-calling, 72 code and 72 agent tasks, three runs per task (seeds 42/43/44), sampling pinned identically (temp 0.2, top-p 0.95, top-k 40, min-p 0.05, KV q8_0, one slot), each model with its own profile so it competes in its best real configuration. Every exclusion is counted with a reason. 2× RTX 5080. model (thinking off) tools code agent speed global ----------------------------------------- ----- ---- ----- ----- ------ MiniCPM-V-4.7-35B-A3B Q4_K_M 100% 83% 90% 26ms 0.85 qwen36-35b-distill-mxfp4_moe 94% 74% 92% 19ms 0.84 Qwen3.8-27B-UD-Q3_K_XL 100% 79% 90% 36ms 0.82 Ornith-1.5-35B-A3B-APEX 100% 75% 92% 32ms 0.82 Qwen3.8-27B-Heretic-Q4_K_M 100% 86% 92% 85ms 0.81 Qwen3.8-27B-NEO-CODER-MAX-MTP 100% 79% 91% 46ms 0.81 gemma-4-26B-A4B-it-UD-Q5_K_XL 89% 86% 87% 33ms 0.80 Qwen3.8-Flash-Next IQ3_XXS (125B, Strata) 91% 84% 91% 40ms 0.80 The 125B is not the top of this board, which surprised me. A 35B MiniCPM-V and a 27B Qwen3.8 are level with it on agent tasks, and the 125B wins nothing on its own. Size is not the lever for agentic coding; tool-calling reliability is, and the 27B class already saturates it. Thinking mode is a tax that only pays in hard code: turning it on moved the 27B from 0.79 → 0.93 on code and 0.90 → 0.96 on agent, at 36 ms → 629 ms and +253 median tokens per call. On easy tasks it costs and does not pay; on the expert tier it is the difference between passing and failing. So it stays off by default and on for the hard tier. The engine made no measurable difference either. The same harness against a different engine (the community MoE streaming engine BigMoeOnEdge) scored 0.920 against 0.923 on the same 72 agent tasks with the same model, at the same throughput. It did surface a bug in that engine's router hook, where a generated turn comes back as an empty message, so I filed it with a backtrace: github.com/Helldez/BigMoeOnEdge/issues/334 Limitations: consumer GPUs, tasks written for this harness (reference solutions never leave the machine), one machine, one quant per model. The pool is re-measured when conditions change, and every row states the task set it really ran. What model am I missing, and what would you measure differently? Live scoreboard (re-measured rows, retired models kept as record): https://jordimarsal.github.io/ggufbench/ Repo (harness, tasks, adapters, receipts): https://github.com/jordimarsal/ggufbench Author of ggufbench.   submitted by   /u/Joralk_ [link]   [comments]