thrifty

thrifty

Tiered-delegation task execution for Claude Code. A planner model writes the spec
into sprints, a cheap model executes and self-verifies against the gate — same gate
quality as the strong model, ~64% cheaper (≈⅓ the cost) (benchmarked).

Offload each sprint of work to the weakest model that can do it correctly.

The idea

Most of the work in a task is pattern-following execution, not reasoning. thrifty
concentrates planning in one model and pushes execution down to a cheap one, with the
gate (tests / a checklist) as the trust contract — independently re-run, never
self-reported. This generalizes "tests as the source of truth" to any task, code or not.

Benchmarked architecture

The configuration that won the cost/quality bake-off (spec → working code, 7 tasks across
JS / Python / Go / prose, gate-verified — see eval/RESULTS.md and
experiments/):

spec ──▶ Sonnet  writes contract (pins cross-sprint + genuinely-ambiguous decisions)
                 + sprints.jsonl (one self-contained unit of work each)
            │
            ▼
         Haiku   one cached agent builds every sprint, runs the gate, and self-fixes
            │
            ▼
         Sonnet  a SCOPED patch — only if a specific failure is left (in practice: never;
                 the Haiku agent self-fixed to green on all 7 tasks)

Result: ~64% cheaper than Opus building the same spec, at equal gate quality — on
large, multi-unit builds (the win grows with size). On trivial builds the planning
overhead makes thrifty cost more than a single capable agent, so there's a crossover
below which you should just use one strong model directly (see Usage). Two
things make it work: a single cached agent reuses the contract across turns (cheap, no
cold-call bloat), and the contract pins every decision that crosses a sprint boundary
so the executor never invents a system-level choice (leave one ambiguous and the executor
writes contradictory tests). Opus is not in the execution loop.

Install

thrifty ships as a Claude Code plugin (bundles all six skills):

/plugin marketplace add 2389-research/thrifty
/plugin install thrifty@thrifty

Then trigger it with "thrifty", "delegate this", or "tiered build".

The subagent-based skills (thrifty, thrifty-plan/brief/execute/check) need no external runtime. The lean thrifty-dispatch flow shells out to skills/thrifty-dispatch/dispatch.py, so it additionally requires Python 3 on PATH.

To hack on it locally instead, symlink the skills into ~/.claude/skills/:

for d in skills/*/; do ln -s "$PWD/$d" ~/.claude/skills/; done

Lineage

thrifty generalizes three existing systems to arbitrary tasks:

• speed-run — offload first-pass generation to a fast model; the strong model

• pipelines/local_code_gen — a strong architect pins every cross-sprint decision

• Noospheric Orrery — proof of the philosophy: Sonnet never extracts; Haiku

Where local_code_gen writes 600-line byte-pinned contracts for a tiny local
model (qwen3.6 / gemma), thrifty deliberately sits well above that floor. Haiku
is far stronger, so the contract pins only what is cross-sprint AND genuinely
ambiguous — the seams, not the interiors. Since the planner's (Sonnet) output is the
expensive part, terseness is the goal: pin the few decisions two capable sprints
would otherwise diverge on, and let Haiku infer the rest.

Skills

Planning tiers (who writes the briefs)

• direct — the architect writes the contract and every brief. Fewest moving

• split — the architect (director) writes the contract + terse unit specs;

• hybrid — the architect writes the 1–2 subtle sprints' briefs, delegates the routine rest.

Rough rule: direct below ~5 sprints, split above — but it's per-task, and the subtle
sprints can stay direct even in a split run. Authority follows the tier: the architect
owns the contract (cross-sprint), the brief-writer owns its unit (within-sprint), so a
within-sprint fix stays with a Sonnet brief-writer and only contract defects reach the
architect.

Usage

Say "thrifty", "delegate this", or "tiered build" on a multi-part task.

Which flow runs: the agent should try the lean dispatch flow (thrifty-dispatch)
first — it's the benchmarked, cheapest path — and fall back to the subagent flow below
only when the dispatch runtime is unavailable (python3 / claude -p can't be spawned) or
the task genuinely needs per-unit parallel verification. Cost ordering, measured: *dispatch
< subagent < direct-strong-model on large builds; on trivial builds the planning overhead
makes either thrifty flow cost more than just one capable agent — so below ~a few real
units, skip thrifty. The thrifty skill now points the agent at dispatch by default.

• A gate fails → a Sonnet checker reads the failure and surgically fixes it.
• Assertional criteria (prose, citations, canon, design quality) → a Sonnet

Recommended: the lean dispatch flow (thrifty-dispatch). It is the benchmarked architecture and the one the ~64% cost claim is measured on. Reach for the subagent substrate only when you specifically need per-unit parallel verification — and know it costs materially more (see why below).

Executor-tier caveat: unlike dispatch, this path cannot force the executor model in
code — it asks the orchestrator to dispatch with model: "haiku", which a runtime may
silently ignore (falling back to Sonnet/the default). Verify the actual model each
executor ran on before trusting any cost figure — and note a subagent's self-reported*
model is only a weak signal (a silently-substituted model often still claims to be Haiku);
the authoritative check is observed cost/usage. The ledger's savings line is an estimate,
not a measurement. (See the "Verify the executor tier" step in thrifty's Step 3.)

Status

v0.1 — benchmarked. The lean dispatch flow is ~64% cheaper than Opus building the same
spec, at equal gate quality, across 7 tasks (JS / Python / Go / prose). Evidence:
eval/RESULTS.md (main findings + full journey) and
experiments/ (reproducible scripts + captured cost data).