Amortized intelligence

Amortized Intelligence — the compiler's doctrine

Why this skill exists. Frontier quota expires and sessions die. A Fable session whose judgment exists only in the chat transcript has rented intelligence; a session that leaves artifacts has accumulated it. Same economics as software: the expensive engineer writes the program once, the program runs at near-zero marginal cost. Fable is the engineer; the artifact is the program; Haiku is the CPU.

The one law

Judgment that will be exercised more than once must leave the session as an artifact a cheaper model can run. Frontier tokens are capex; cheap tokens are opex; amortized frontier cost per run → 0 as runs grow. If the session is spending frontier tokens on something recurring and NOT producing an artifact, it is the failure mode this skill exists to stop.

The compile test — run before compiling anything

Compile only when ALL three hold; otherwise just do the task at frontier tier and move on:

1. Recurrence — the task will plausibly run ≥3 more times. Specification cost can exceed doing-it cost; one-offs never amortize.
2. Stationarity — the task's shape is stable; inputs drift slowly, not per-run.
3. Verifiability — "good" can be stated as criteria a cheap model or plain code can check. If good is pure taste that can't be externalized yet, the task isn't compilable yet.

The four artifacts

Build in this order — the eval makes the other three trustworthy.

Artifact	Encodes	Build note
Eval set	What "done/good" means, as ≥5 golden cases with expected outcomes	Build FIRST. Turns "can Haiku run this?" from a vibe into a measurement, and makes recompiling for the next model cheap.
Harness	Control flow: decomposition, retries, tool wiring, verification loop	Highest leverage — moves difficulty out of the model entirely. Prefer deterministic code over prompt text wherever possible. Its job: keep every individual step below the cheap model's ceiling.
Rubric	Taste, converted to an explicit checklist	Enables the loop that substitutes for capability: generate cheap → grade → retry. Iteration + verification ≈ intelligence.
Skill/SOP	The procedure + edge cases as when/then branches	Every branch written down is live reasoning the cheap model never has to do. Prune prescriptive detail that ages badly (old skills over-constrain new models).

The three compile rules

Each one is a documented failure mode when skipped (evidence in references/sources.md).

1. Compile FOR the target model, not on yourself. Artifacts optimized on a strong model often don't transfer down-tier. Put the target cheap model in the loop during compilation: draft artifact → run the TARGET model against the eval → iterate until it passes on the target → ship. The artifact is model-pair-specific; the eval is what stays portable.
2. Don't trust cheap judges. Models attend far less when judging than when generating — a cheap rubric-judge can rubber-stamp everything while looking diligent. Defenses, use all three: drills, not diffs (prove behavior against reality — run the thing, break the thing — never accept output-reading as verification); hidden holdout criteria the executor never sees; periodic frontier audits that sample outputs against intent, not just against the rubric's letter.
3. Amortize the 95%, escalate the residual. Some inputs carry irreducible judgment. Every artifact must state its escalation criteria — when the cheap runner stops and routes to a frontier session. Escalations are not failures; they are the maintenance signal: each one is a candidate new branch to compile back into the artifact.

The maintenance loop — the honest cost

"Infinite zero cost" is wrong. It is software economics: high capex, near-zero opex, plus recurring maintenance that is small but never zero.

• Drift — the world moves; rubrics and SOPs go stale. Schedule frontier audits (sample N recent outputs per period, review against intent).
• Goodhart — cheap models optimize the rubric's letter, confidently. Layer verification: rubric + spot-check + eval regression.
• The flywheel — frontier reviews failures → patches the artifact → the cheap tier is permanently upgraded. Capability ratchets up while marginal cost stays flat.

frontier designs artifact → cheap model runs it → failures/escalations logged
        ↑                                                    │
        └─── frontier reviews failures, patches artifact ────┘

Compile the gate too

The last frontier dependency is usually review: if only Fable can gate-review the cheap workers' output, the system still dies with the quota. Compile gate-review itself as an artifact: per-task checklist derived from the done-conditions + drill procedure + required evidence format + verdict rules + escalation criteria. Then test it down-tier: have a cheap model review the same work using only the artifact, compare verdicts with the frontier review of the same diff, and iterate the artifact until the verdicts match. It ships only when it passes that test.

Session-end ritual — every substantive frontier session

Before closing, ask: what judgment did this session exercise that dies as chat? For each item, either compile it (skill, rubric, harness, eval, memory entry) or explicitly declare it dead on purpose. Then leave a one-line handoff the next session can start from. Never end a frontier session with its deliverable existing only in the transcript.

The other half — runtime routing

This skill governs what must outlive a session. Its complement is a routing doctrine for the live session — which model tier executes now, how work is delegated, where the gates sit. Pair this skill with whatever orchestrator doctrine your setup runs; they compose: routing while working, compiling at design time and at close.

Evidence, benchmark numbers, and the idea's lineage (DSPy/GEPA, FrugalGPT/RouteLLM, harness-vs-model results, the caveat papers): references/sources.md.