DR-010 — Local models, code helpers and triggers¶

Converted from docs/decisions/DR-010-local-models-and-triggers.md to MADR (backlog B25). The text is unchanged; its sections are grouped under the MADR headings below, in their original order within each group.

Context¶

1. Context¶

Atul will set aside one or two old machines (8–16 GB RAM, no GPU assumed) for side projects. The Code + Test harness (mmdep/harness.py) already supports a local model through Ollama (qwen-coder-7b, qwen-coder-1.5b in mmdep/harness_config.json), so a machine only needs Ollama and the repo.

2. Small coding models (CPU, 4-bit quantised)¶

Model	Download / RAM in use	Speed on an older 4-core CPU (typical)	Fits	Notes
Qwen2.5-Coder-1.5B-Instruct	about 1 GB / 2 GB	fast (tens of tokens a second)	8 GB machine	Good for small edits, docstrings, test stubs, classification (preflight). Weak on multi-file reasoning
Qwen2.5-Coder-7B-Instruct	about 4.7 GB / 6–7 GB	slow (a few tokens a second)	16 GB machine	Best of the three for real `cx:1` code items; a 300-line file reply can take several minutes
DeepSeek-Coder-1.3B-Instruct	about 0.8 GB / 2 GB	fast	8 GB	Older (2023); weaker than Qwen2.5-Coder-1.5B; keep only as a comparison

Also worth one benchmark run: the newer small models in the September Technology Evaluation (Qwen3.5 small sizes, Phi-4-mini), because small models improve quickly.

What to expect: small local models can do trivial, well-scoped edits with tests (exactly what cx:1 routing gives them); they will fail more often on anything cross-module. The harness's loop (tests, feedback, regression gate) is what makes them usable: a wrong answer costs time, never a bad merge.

Measure, don't assume: run the same 5 pilot issues on Gemini Flash-Lite, Qwen-Coder-7B and Qwen-Coder-1.5B; record pass rate, attempts and minutes in the harness ledger; route cx:1 to the local model only where its pass rate is acceptable.

3. Code helpers (agents that edit a repo)¶

Tool	What it is	Fit for MMDEP
Aider	Open-source terminal pair-programmer; git-aware (commits each change), works with Ollama and with hosted APIs; has a built-in "run the tests and fix" loop and a repo map	Strong candidate as an alternative engine inside the harness for `cx:2` items (multi-file edits); our harness keeps routing, scope, budget, regression gate and reporting. Adds a dependency (Python package), so only after the built-in engine is measured
OpenCode	Open-source terminal coding agent; many providers including Ollama	Similar role; better for interactive use on the local machine than for headless runs
Built-in engine (ours)	Whole-file JSON replacements for scope files only, test loop, regression gate	Simplest, no new dependency; best for small models, which handle whole-file output more reliably than diff formats

Recommendation: start with the built-in engine (done); add Aider as an optional engine in sprint 3 if cx:2 items need it.

About the example script Atul shared: the loop idea (generate, test, feed errors back, retry five times) is the same as the harness's. The harness adds what an unattended loop needs: a branch per task (never the working copy or main), writes limited to the scope files, a full-suite regression check (not just one test file), timeouts and stdin on every process, a budget and a ledger, a stop switch, and a report. It also avoids the requests dependency.

4. Automation triggers¶

Trigger	How it would work for us	Verdict
Scheduled task / cron	Windows Task Scheduler: hourly plus logon, unlock and network-reconnect events (collector and harness)	In use. Simple, offline-safe, no public endpoint
CI/CD pipelines	GitHub Actions on a self-hosted runner on the laptop or old machine: a workflow on `issues: labeled` (`for:code`) runs `mmdep harness run --issue N`; another on pull requests runs the full suite	Next step. Event-driven within seconds, no public endpoint needed (the runner polls GitHub). Needs a GitHub runner registered by Atul (a token in a hidden prompt)
Git hooks (local)	`pre-commit` / `pre-push` on agent branches: lint, the subprocess `stdin` guard, secret scan	Yes, cheap. Quality gate before anything is pushed; not an orchestration trigger
Webhooks	GitHub/GitLab call a URL on events	Needs a public endpoint; the laptop is behind NAT. Only with the AWS tools server or a hosted relay. Later
File-system watchers (watchdog, chokidar)	Watch a local drop folder (for example `C:\Projects\_mmdep-inbox`) and run a job when a file appears	Useful later for local queues (open work packages delivered as files, factsheet PDFs)
Serverless (AWS Lambda)	Small timed collectors (regulator watch W1–W11) without a machine	Good fit for the watch collectors once AWS is opened (DR-004); not for test suites

Options¶

Not stated separately in the original record.

Decision¶

6. Decisions for Atul¶

LOC-1: Old machines run Ollama (Qwen2.5-Coder 1.5B or 7B by RAM) plus a runner; benchmark against Gemini on 5 pilot issues before routing real items to them?
TRG-1: Next trigger after the scheduled task: a GitHub self-hosted runner with an issues: labeled workflow (event-driven, no public endpoint); local git hooks as a quality gate?

Consequences¶

5. Plan for the old machines¶

Install a light Linux (Ubuntu Server) or keep Windows; install Ollama, Git, Python, the repo.
8 GB machine: qwen2.5-coder:1.5b for preflight and trivial items; 16 GB machine: qwen2.5-coder:7b.
Register it as a second runner (GitLab laptop,docker-style tag oldpc, and later a GitHub self-hosted runner), so tests and harness runs move off Atul's laptop.
Point the harness config at it ("url": "http://<machine>:11434" for Ollama) and run the 5-issue benchmark.