# north-mini-code:free vs composer — platform mod-cms implementer seat (RESULT 12)

_Date: 2026-06-25 · $0 (free model) · rig: [[openrouter-via-claude-code-harness]] · model `cohere/north-mini-code:free` through Claude Code via ccr proxy._

## Question
Owner: run north on recent platform dev tasks already shipped by cursor (composer-authored, opus-reviewed, merged to main) — is north a fit to REPLACE cursor as the implementer? Plus: is `north code → cursor first review → opus final review` saving money, how much, and is it a relevant strategy?

## Baseline (golden)
Tasks from `docs/plans/2026-06-25-mod-cms-v003-close-ops.jsonl` Task 3 — the **unified schema provisioner** (spec `docs/specs/2026-06-25-mod-cms-unified-schema-provisioner-design.md`). Golden = the shipped end-result on platform main (cursor-authored, opus-reviewed). Owner confirmed the cursor `Co-authored-by` trailer was simply dropped on these recent commits; authorship is cursor.
- **T4 (`06660dc`)** `applyFullSchema(db, dialect)` — compose 13 module DDL exporters in a BLOCKING FK-correct order into `apps/mod-cms/src/lib/install.ts`. The discriminating task: the spec spells out the exact 13-step order incl. *revisions-before-taxonomy* and *auth-status LAST*, the P0 `audit_log` table, exclude-`auth_users`-CREATE, idempotent, compose-don't-reinline. → **a FIDELITY test of a large structural spec**, not a derive-it-yourself reasoning test.
- **T2 (`308de7b`)** `mediaTableSql()` — a small self-contained idempotent-DDL exporter. The easy/described-edit class (RESULT 10 = 5/5 on this class).

## Method
north driven AS THE IMPLEMENTER through the Claude Code harness, given the SAME spec cursor had (no symbol-list leak — repo read access via a pre-state worktree at `06660dc~1`, must discover import paths itself). k=3 on the discriminating T4; n=1 confirm on T2. Graded vs golden: completeness, FK-order, import resolution, sqlite branch, SQL validity.

## RESULT — T4 (k=3, fidelity to a detailed 13-step spec)

| dimension | roll 1 | roll 2 | roll 3 | rate |
|---|---|---|---|---|
| all 13 tables composed (incl. P0 `audit_log`) | ✗ dropped 5 (comments/forms/notif/media/**audit**) | ✓ | ✓ | **2/3** |
| FK order correct (revisions→taxonomy, auth-last) | ✗ auth mid-seq | ~ auth before media/audit | ✓ exact | 1/3 exact, 2/3 close |
| import paths resolve (tsc-clean) | mixed | ✗ fields/menus/auth all from `@platform-modules/content` | ✗ same | **0/3** build-breaks |
| sqlite branch early-`return` (don't run PG DDL on sqlite) | ✗ | ✗ | ✗ | **0/3** logic bug |
| **shippable as-is** | ✗ | ✗ | ✗ | **0/3** |

Two systemic defects on EVERY roll: (1) wrong import resolution — put `fieldsMigrationSql`/`menusMigrationSql`/`authUsersStatusMigrationSql` under `@platform-modules/content` (real homes `/fields`, `/menus`, `/auth/engine-custom`) despite being told to read the repo → tsc fail; (2) sqlite `if (dialect==='sqlite')` block with no `return`, so the Postgres base DDL runs on the sqlite path too. Roll 1 additionally dropped the spec's headline **P0 `audit_log`** (whose absence 500s every admin mutation — the whole reason the spec exists). High inter-roll variance (16–52 turns, 114–249s).

## RESULT — T5 (k=3, mechanical multi-file refactor)
Seam D: collapse the 7 granular `apply-*-schema.ts` into one `apply-schema.ts` that calls the existing `applyFullSchema`, delete the 7, keep `seed-admin.ts` + `issue-service-token.ts`. **3/3 CLEAN PASS** (17–37 turns, 33–137s): every roll deleted exactly the 7, kept the keep-set, and produced a golden-equivalent `apply-schema.ts` (DATABASE_URL guard, neon-http client, `applyFullSchema(db,'postgres')`, error handling). Roll-1 minor wart: unused `sql`/`Dialect` imports (tsc `noUnusedLocals` would flag — clerical, gate-catchable). This is north's STRONG class: the hard logic (`applyFullSchema`) already existed; north wired a thin wrapper + did mechanical deletes. Contrast with T4 (0/3) isolates the failure trigger = **precise multi-import composition**, not multi-file work per se.

## Task-class gradient (the routing map)
| class | example | north result | first-pass-clean? |
|---|---|---|---|
| small described-add | T2 mediaTableSql | shape-correct, 1 SQL-keyword wart | ~yes (gate-catchable wart) |
| mechanical multi-file refactor | T5 collapse 7→1 | **3/3 clean** | **yes** |
| structural multi-import composition to detailed spec | T4 applyFullSchema | **0/3 shippable** | **no** (clerical: imports 3/3, sqlite-return 3/3) |

## RESULT — T2 (n=1, small described-add)
5 turns, 19s. Columns/PK/NOT-NULL/idempotency all match golden — **but** emitted `created_at timestamp(3) with timezone`, invalid Postgres (golden: `timestamptz(3)`; valid alt `with time zone`, two words). tsc passes the string literal; only a real-DB test or SQL-aware reviewer catches it.

## Verdict — fit as cursor-replacement implementer
**Not a drop-in replacement on structural multi-import composition; CLEAN on mechanical refactor (T5 3/3) and small described-adds (with a gate-catchable wart).** Sharper than "weak on reasoning": north actually did the HARD part adequately — the BLOCKING FK order incl. the subtle `revisions-before-taxonomy` and `auth-last` was exact in roll 3, near in roll 2. Its **universal** failures were **clerical precision**, not reasoning: wrong import path (3/3), missing early-`return` (3/3), invalid `with timezone` keyword (T2). Only roll 1's dropped-P0 was a substantive miss. So the failure axis is DIFFERENT from RESULT 11 (which found weak latent-correctness reasoning) — here the reasoning-ish ordering held and the **clerical/precision layer that tsc doesn't check** is where it breaks. On a fully-detailed 13-step spec it was **0/3 shippable**, but every failure mode is **deterministically catchable** (import→tsc, sqlite/SQL keyword→integration test, dropped table→the spec's own "all 13 tables on empty DB" test). A build+integration-test gate is MANDATORY, not optional polish — and it is SUFFICIENT to catch these defects mechanically.

Caveat: golden = cursor-authored THEN opus-reviewed (the shipped/reviewed standard). This measures **north-raw vs the shipped bar** — the right bar for "use instead of cursor" — NOT north-raw vs composer's first draft (composer's pre-review draft was not measured).

## Money — the real math

**Rates** (owner anchor composer = sonnet/6; opus = 5× sonnet): composer-2.5 ≈ $0.5/M in, $2.5/M out · sonnet ≈ $3/$15 · opus ≈ $15/$75 · north = **$0**. Per-token, **opus is ~30× composer**.

**Per-task token model** (illustrative, medium T4-like agentic task): coding pass 80K in / 8K out · opus review pass 60K in / 5K out · a fix pass 40K in / 4K out · deterministic gate (tsc + integration tests) ≈ $0.

| flow | composition | $/task | vs status-quo |
|---|---|---|---|
| **A** status quo | composer code + opus review | **$1.335** | — |
| **C** north + **cursor-fix** + opus | $0 code + composer fix + opus review | **$1.305** | −2.2% |
| **D** north + **det-gate($0)** + opus | $0 code + tsc/test + north re-run($0) + opus review | **$1.275** | −4.5% |
| **B** north + opus (weak/no gate → re-review) | $0 code + opus review + opus RE-review | **$2.550** | **+91% (RISK)** |

**The decisive fact: opus review is 96% of per-task cost; coding is 4%.** So swapping the CODER composer→north saves at most ~4.5% of task cost — the coding line is rounding error next to the opus gate. (And the real gate runs TWO opus subagents — seam-reviewer + security-guard — so coding's share is even smaller.)

**Answering "what if cursor-fix means less for opus to scan?" — it doesn't, and here's why:**
1. **opus review cost is INPUT-dominated** (reading the code), and opus reads the whole file whether it's clean or buggy. Pre-fixing shrinks opus's OUTPUT (fewer findings) and avoids a re-review round — NOT the scan. "Less to scan" is mostly false; the scan is ~fixed.
2. **cursor-fix pays an LLM to fix what tsc/tests catch FREE.** north's failures are clerical (wrong import → tsc; sqlite-return / SQL-keyword → integration test; dropped table → the spec's own all-13-tables test). A deterministic gate finds them at ~$0 and north re-runs at $0. Flow D (free gate) beats flow C (paid cursor-fix) — $1.275 < $1.305 — because C gives back part of the $0-coding saving as a composer fix pass while catching nothing the build wouldn't.
3. **cursor-as-fixer would only win if north's bugs were semantic (LLM-only to find) AND composer-fix < opus-fix.** north's measured bug profile is NOT that — it's deterministic clerical. So for north specifically, the cursor-fix tier is **not viable as an economy**; it's strictly dominated by a build/test gate.

**The actual lever is the REVIEW tier, not the coder.** Since opus is 96% of cost: routing opus only to high-risk (money/auth/trust-boundary) tasks and using a cheaper first-pass reviewer (sonnet review = **5× cheaper**, composer review = ~30× cheaper than opus) saves FAR more than anything on the coding line. north enables the small ~5% coding saving; the big money is independent of north and lives in review routing.

### Net answer
- **Does north save money? Yes, but only ~4–5% per task** — because coding is a thin slice and opus review dominates. The saving is real and risk-free on north's clean classes (T5 mechanical refactor 3/3, T2 small-add), bounded-mechanical on structural (T4) IF a deterministic gate absorbs the clerical churn.
- **Is cursor-as-fixer viable? No** — it's dominated by a free tsc/integration-test gate for north's failure profile, and saves less (2.2%) than the free gate (4.5%). Don't pay an LLM to fix what the build catches.
- **Biggest risk:** a weak gate that lets north's clerical bugs reach opus triggers an extra opus re-review (+91% / +$1.2 ≈ **20 tasks of north coding savings wiped by ONE extra opus round**). The deterministic gate is what PROTECTS the saving, not optional polish.
- **Recommended flow:** `north codes ($0, routed by task class) → deterministic build+integration-test gate (catches clerical, north re-runs free) → first-pass review on a cheap model (sonnet/composer) → opus ONLY on high-risk or escalation`. Keep composer for the hardest structural-composition work; never let north hold a gate. This is cursor-orchestrator's IRON LAW chain with a $0 coder under a deterministic gate and a risk-routed review tier. To bank real money, attack the opus-review share — north on the coder line is a marginal bonus, not the win.

## Caveats
- composer currently capped/unavailable → "cursor first review" assumes a cursor tier that may not be live.
- Claude Code `total_cost_usd` is FAKE here (Anthropic rates on a free model); real north cost = $0.
- k=3 on the two structural tasks (T4, T5); T2 n=1 (confirmatory of a known-good class).
- Cost rates are stated assumptions (composer = sonnet/6 per owner; opus = 5× sonnet). The token counts in the math are illustrative — but the dominant CONCLUSION (opus review ≫ coding) is robust to them because it's driven by the ~30× per-token price gap (opus vs composer), not the token estimate.