1337Hero/qwen3-coder-30b-a3b-codemonkey-GGUF

Qwen3-CodeMonkey v1

A fine-tuned version of qwen3-coder-30b-a3b, optimized for frontend development patterns and DHH-inspired simplicity.

TL;DR: I made Qwen faster but dumber. Q4_K_M hits 137 tps (63% faster gen than base) but drops 10 accuracy points. Your mileage may vary.

🎯 Motivation

I wanted a model that thinks like I do about frontend code:

• Simplicity over cleverness — boring tech that works beats clever abstractions
• Convention over configuration — follow patterns, don't invent new ones
• DHH/Ryan Florence-inspired — majestic monolith vibes for the frontend stack

I work heavily in React/Preact + TanStack Query + Tailwind, and needed a model that could:

• Write clean, maintainable component code
• Avoid TypeScript ceremony and over-abstraction
• Default to proven patterns (no "clever" state management hacks)
• Generate code that a junior dev can understand 6 months later

📊 The Numbers (Honest Edition)

Benchmarked with scaffold-bench My own eval suite that tests real agentic coding work, not trivia or math puzzles. It throws 23 scenarios at the model (surgical edits, audits, scope discipline, verify-and-repair, implementation tasks) with actual tool use and real codebases.

Results (mean of 2 runs, 50-task subset):

Model	Score	Gen TPS	Prompt TPS	Notes
qwen3-code-monkey (Q4_K_M)	66.0% (33/50)	137.3	1219	Fastest, but -10pts accuracy
qwen3-coder-next (base)	76.0% (38/50)	84.4	953	Baseline
qwen3-code-monkey-q8	33.0% (16.5/50)	109.6	1444	One run collapsed early — needs investigation

Translation: Q4 is 63% faster at generation but lost 10 accuracy points. If you're latency bound and can tolerate the trade-off, this might be your jam. If you need max accuracy, stick with base.

What scaffold-bench tests:

• No LLM judge - deterministic code-driven checks only
• Real tool use - read, ls, grep, glob, edit, write, bash
• Real scenarios - surgical edits, audits, scope discipline, implementation tasks against actual codebases
• Categories include: surgical edit, audit, scope discipline, read only analysis, verify and repair, implementation, responsiveness, long context

Sample categories where code-monkey struggled vs base:

• verify-and-repair - iterating through failing tests to green
• implementation - multi-file spec-to-code against existing stacks (wanted to rewrite everything my way instead of following the existing patterns)
• scope-discipline - "make this one change and nothing else" (my training data emphasized refactoring, which backfired)

Q8 caveat: One of the Q8 runs cratered to 8/50 after 64 requests - might be a harness issue, overfit collapse under tighter quantization, or early model failure. Take those numbers with salt until I re-run it.

Full benchmark details: Check out scaffold-bench if you want to run your own evals. All results/*.json files from my runs are in the codemonkey repo.

🛠️ Training Process (And Where I Screwed Up)

• Dataset: ~20,000 Q&A pairs pulled from my frontend philosophy docs (DHH's "majestic monolith" stuff + Ryan Florence's React patterns)
• Fine-tuning: LoRA adapter via Unsloth on Qwen3-Coder-30B-A3B-Instruct
• What I did wrong: Built the whole dataset as plain [question] → [answer] pairs. No reasoning shown, no "wait, should I even do this?" step in the middle. Turns out the model learned the shape of my answers without learning how I got there.
• How it showed up: v1 benched at 32–34/50 vs the base model's 37–40/50. Worse than what I started with. The failures were the giveaway — it would edit files when I asked read-only questions, jump straight to edits without reading anything first, skip searching before acting. Not a knowledge problem. A "doesn't stop to think" problem.
• The speed trap that fooled me: 138 tok/s vs base 84 tok/s looked like a win at first. It wasn't. It was faster because it was thinking less. Trinity-mini sits at the end of that road - blazing fast, fails everything, useless.
• What I'm doing for v2: Q&A alone teaches outputs, not process. Need explicit ... traces in the dataset - short, 2–4 sentences, enough to encode the taboos ("read-only means read-only", "search before you edit", "don't re-add a feature that already exists"). Response-only supervision. Less distilled CoT cosplay, more structural alignment.

Lessons learned:

1. Unsloth works great once you get past the docs
2. 20k rows might've been overkill for the domain specificity I wanted
3. Need to balance domain adaptation with general capability retention
4. Benchmarking early would've saved me a re-train (and $47)

📦 Files

• qwen3-coder-30b-a3b-codemonkey.Q4_K_M.gguf — recommended release artifact (fastest)
• qwen3-coder-30b-a3b-codemonkey.Q8_0.gguf — larger reference GGUF (see caveat above)
• qwen3-coder-30b-a3b-codemonkey.BF16.gguf — optional full-size BF16 source

All quantized from the merged BF16 GGUF (not requantized from Q8).

🚀 Usage with llama.cpp

llama-cli \
  --model qwen3-coder-30b-a3b-codemonkey.Q4_K_M.gguf \
  --jinja \
  -p "Write a React component that fetches user data with TanStack Query and displays it in a card."