# Did north-orchestration save money? LIVE-DATA verdict — NO, it cost 7–13× more

_Date: 2026-06-25 · real mined data from 2 live north-orchestration sessions (platform project) · ledger: `docs/harvest/north-orchestration-cost-ledger.md` · rates: opus $15/$75/$18.75cw/$1.5cr, sonnet $3/$15/$3.75cw/$0.30cr per-M._

## BLUF
**North-orchestration did NOT save money. It cost ~$261 (paid, lower bound) to deliver ~1,392 LOC — 7–13× what one sonnet agent reading the plan and building directly would cost (~$12–36).** On the flagship run (orders-react, 916 LOC) north delivered **zero usable code** — it failed 2/2, cursor built everything — so the free coder's contribution there was negative (pure tax). The "free coding saves money" thesis is false because coding was never where the money was: it's ~4% of per-task cost (RESULT 12, now confirmed live), and north-orchestration ADDS expensive machinery — an opus orchestrator babysitting a noisy free model, a 12% failure tax, and a cursor fallback — that dwarfs the 4%.

## The hard numbers (measured, not modeled)
| | north-orchestration (measured) | sonnet-straight (modeled, same deliverable) |
|---|---|---|
| paid orchestrator tokens | **67.3M** (opus 67.0M + haiku 1.2M) | ~10–35M (no dispatch/gate/retry round-trips) |
| paid $ | **$261** (lower bound — cursor fallback $ unrecoverable, on top) | **$12 (lean) / $21 (mid) / $36 (heavy)** |
| LOC delivered | ~1,392 (north authored only ~116; cursor authored 916; 360 in-flight) | ~1,392 |
| **ratio** | — | **north = 7.3× (heavy) to 12.6× (mid) MORE** |
| failure burn (pure waste) | **$32 / 8.95M tok / 12%** | $0 |

## Why it lost — three drivers, none of them "the coder"

**1. The orchestrator was OPUS (5× sonnet/token).** 89% of the entire bill is opus `cache_read` (59.7M tok = the standing-context tax of long agentic sessions). Running the SAME workload at sonnet rates instead of opus = ~5× cheaper by itself. North forces an opus orchestrator because a free, noisy, failure-prone model needs a strong supervisor to dispatch, read its verbose agentic output, diagnose failures, retry, and run the fallback. **You cannot run north cheaply — the babysitting is the cost.**

**2. North is unreliable → a 12% failure tax + cursor fallback.** Of 5 north build dispatches, only 2 (short-path mod-cms) succeeded. orders-react was **2/2 phantom-tree failures** (north returned `end_turn` success while the filesystem received only `package.json`). Recovering cost **$32 / 8.95M opus tokens** in diagnosis + discriminator probes + Gate-0 fix loops — and then **cursor had to author all 916 LOC anyway.** That failure tax alone is bigger than the entire coding-line saving north was supposed to provide.

**3. Coding was always a rounding error.** RESULT 12 measured coding ≈ 4% of per-task cost; the opus review gate dominates. Live data confirms: north's free coding saved ~4% of the cheapest line while the orchestration apparatus it requires cost multiples of the whole sonnet-straight baseline. **Even the clean run loses** — RUN B's 2 successful short-path north dispatches still burned 15.8M opus tokens (~$60) to deliver 116 LOC + 1 fixer.

## Apples-to-apples (holding the gate constant)
The opus review gate (2 subagents/run) costs the same whether north or sonnet writes the code, so it cancels in the delta. What remains is:
- **sonnet-straight:** sonnet writes the code in its own turns. Done.
- **north-orchestration:** opus dispatches north → reads north's output → (often) diagnoses a failure → retries → falls back to cursor → re-gates. Every arrow is paid opus token burn that sonnet-straight never spends.
The delta = (≤4% coding saving from free north) − (dispatch overhead + 12% failure tax + cursor fallback) = **strongly negative.**

## Was cursor better?
**As an implementer: yes, on reliability** — cursor delivered orders-react (916 LOC) when north failed twice; composer-2.5 is the dependable coder. But cursor doesn't fix the real problem: the cost is the opus orchestration + long-session cache tax, not the coder. Swapping north→cursor on the coding line is still optimizing the 4%.

## Verdict & recommendation
- **Kill north-orchestration as a money play.** It is 7–13× more expensive than a sonnet-straight build and delivered no usable free code on its flagship task. The free coder is a rounding-error optimization on the cheapest line, bought at the price of the most expensive machinery.
- **Cheapest correct path:** one capable agent (sonnet, or cursor on the cursor sub) reads the plan and builds directly — no dispatch round-trips, no free-model babysitting, no failure tax. Gate with **opus ONLY on high-risk diffs** (money/auth/trust-boundary); use a cheap first-pass reviewer (composer/sonnet) elsewhere — see `2026-06-25-composer-as-reviewer.md`.
- **The real money levers are orthogonal to the coder:** (1) orchestrator model tier (sonnet not opus = ~5×), (2) session length / cache discipline (89% of the bill was cache_read), (3) review routing (opus only where it earns it). North touches none of these.

## Caveats (fair)
- RUN A (HIGH confidence, whole dedicated session) included one-time NEW-rig diagnosis overhead; RUN B (MEDIUM, window-sliced from a mixed 3-day session) is fuzzier on cache attribution. Even discounting RUN A's one-time diagnosis, the structural conclusion holds — RUN B's clean path still lost ~3–5×.
- The $261 is a **lower bound**: cursor fallback/fixer token cost is unrecoverable (separate tool) and sits on top.
- Sonnet-straight is modeled (owner barred running a sonnet agent to measure); three transparent scenarios (lean/mid/heavy) all land $12–36. Even the "heavy" case (as turn-heavy as the north run, just at sonnet rates) is 7.3× cheaper.
- This measures COST, assuming sonnet is capable enough (owner's stipulation). If sonnet quality fell short on a task, the gate would catch it — at gate cost identical to north's flow.