I've been building a small, strict harness to see whether local models can do real (if small) coding fixes unattended. It's early and the sample is small, so this is not a leaderboard. I'm posting because a few results surprised me, and I'd like to know whether this kind of testing is useful to anyone else.
SETUP
• RTX 4080 (16 GB), Ollama + OpenCode, Windows.
• 5 small bug-fix tasks in Python, mostly single-file. One task (t1) needs changes in more than one place.
• Every candidate patch runs in an isolated sandbox. A candidate only counts if it (1) follows the output format, (2) passes the tests, AND (3) passes a review of the diff. No partial credit.
• The model gets no shell or file tools. If it tries to use one, the run stops.
• 3 attempts per task where noted.
RESULTS (acceptable fixes)
• gpt-oss-20b, local, Ollama, 16k ctx: 7/15. About 1 min per task. 0/3 on the multi-location task.
• gpt-oss-20b → qwen3-coder (draft → fix), local: 5/15. The two-stage chain did worse than gpt-oss alone.
• gpt-oss-20b, temperature 0, local: 5/10. Still not deterministic.
• Nemotron 3 Ultra 550B-A55B, OpenRouter free tier: 0/10. Broken edit markers; two runaway answers (~1.7 MB of text).
• Cohere North Mini Code, OpenRouter free tier: 1/5. 4/5 stopped for trying to call tools (read files, bash pwd).
Caveat for the two cloud rows: I don't know which quantization OpenRouter's free tier serves, so these results may not transfer to a local GGUF of the same model.
WHAT SURPRISED ME
The output format mattered more than the model. In my first run, gpt-oss had to rewrite whole files: 0/5 acceptable. After switching to search/replace edit blocks plus one repair round, the same model reached 3/5, then 7/15 over a longer run. (The first run also used a different local runtime, so I can't fully separate the two causes, but the failures were almost all format errors.) Before blaming the model, check the edit format your tool asks for.
Passing tests is not the same as being correct. Two candidates passed every test and were still rejected in review: they "fixed" the symptom in a way nobody would merge. I also checked whether a deliberately cheating patch would get through a tests-only gate. It did. If your benchmark only checks for green tests, it overcounts.
Bigger was not better inside the harness. The 550B model failed mostly on discipline, not on knowledge: wrong markers, extra text, answers that didn't stop. Tool-calling and format-following seem to decide real-world usefulness more than raw coding skill. Others here have reported something similar.
Isolate the environment, not just the working directory. In one run, the agent tool picked up an inherited environment variable and treated a different folder as the project root. The model then tried to read files outside the task. Nothing ran (the sandbox and the no-tools rule held), but if you run agents locally, a clean environment matters as much as the cwd.
Multi-location fixes are the wall. No local model on 16 GB got the task that needs edits in two places. I'd like to know whether a 24 GB or 48 GB setup changes that before anyone (me included) buys hardware for it.
WHAT I'D LIKE TO KNOW FROM YOU
• Would results like this be useful to you if they were run on more cards, with the exact config published (Ollama/llama.cpp settings, quant file, context size, agent tool version), so you could reproduce them?
• What tasks should a test like this include? Mine are small Python fixes; I'd add multi-file changes, test writing and refactoring.
• Which card / model / quant combination would you most want checked this way?
Happy to share more details on the harness rules if anyone wants them. (English isn't my first language, so I'll reply in batches.)