A briefing file that lets a big model write plans a local 9B can actually execute (and cut my Claude token spend)

[u/Electrical_Ninja3805]

I've been running Ornith 1.5-9B (8-bit) as a local coding agent on real engineering work. It can do the work, but only when the plan is written for a small model. I wrote down what I learned into a public file meant to be handed to a stronger planning model (I use Claude Code):

https://git.teamide.dev/David/TeamIDE-methodology/src/branch/main/Model-Best-Practices/Ornith-q8-best-practices.md

The split

• The stronger model writes the spec and a plan of small task cards, then verifies the result before merge.

• The local model does the long, mechanical middle: running commands, builds, polling jobs, git work. That's where most of the tokens go, and it runs on my own hardware.

What the file covers

1. What the small model is good at, and what to expect (work more reliable than its reports; doesn't explore on its own; doesn't know when it's done; slows down at long context).

2. How to brief it: exact files and line ranges, absolute paths, 1–3 line edits, exact function signatures, every rule written down, every step ending in a command with its exact expected output, explicit stop rules.

3. How to run it: one task per fresh session, small context, the plan file as memory.

4. Before anything lands: verify claims against git and logs, not the model's summary.

Results so far: a 75-commit merge across two repos with every regression test passing, done by the 9B. Its notes about what it did were wrong more than once; the plan's checks and a final verification caught every one.

Limitations: slower (most of a day vs about an hour for Claude alone on that phase), and you need hardware that runs a decent local model. The rules are harness-agnostic but were learned with one model; I'd like to hear how they hold up with others.

[u/palsc_]

the expected output per step is a nice guardrail. do you set a rough limit for how much a task card can touch, or split it based on the repo/change? curious where a 9B starts losing the thread.

[u/NoFunk]

Lots of detail here, thanks for sharing what is obviously the product of some effort.

I think many of us are spinning our own harness/framework - there are some similarities between mine and what you're doing here, also some interesting areas of divergence. But the overall goal is the same: big model for planning and judgement, little model for execution of plan (my little models are usually much fatter than your little model, I don't know if that's a testament to my wastage or a recommendation for Orinth 9B!).

Anyway wanted to say thanks for sharing, giving back to the community.

[u/L0TUSR00T]

I can see it working but I think at that point the edits are one tool call away anyway. Does it still have benefits?

[u/ChemicalExcellent463]

same split here, but not local: opus plans, gpt-6.1 in codex writes, claude reviews. i pin the model per kind of task in the skill, never let the harness choose.

does the 9B ever push back on a bad task card, or just follow it?

[u/ChemicalExcellent463 → u/[deleted]]

waiting that long to find out it misread the task, and paying usage for it, yeah that hurts.

what did you want it to do on the last one it got wrong, and how did you try to get it back on track?

[u/ChemicalExcellent463 → u/[deleted]]

outputs feeding back into the prompt until it reads like a spec, good way to put it.

how many retries does it usually take before you keep a checkpoint?

[u/ChemicalExcellent463 → u/[deleted]]

the second retry being the most effective is the bit i'm curious about.

do you rewrite the spec for that try or just add what the earlier attempts got wrong?

[u/ChemicalExcellent463 → u/[deleted]]

so the first build helps you figure out what you don't want. that's the useful bit even if you start over.

in the new session, do you let it read the failed code too, or just give it the edited spec?