# Token optimization protocol for Claude Fable and other high-capability / high-cost models. Apply this skill at the START of any session involving iterative code builds, multi-file projects, design…

> Source: <https://gist.github.com/amirmushichge/b4e133b7e7e86c445817a295ce43f76f>
> Published: 2026-06-12 06:37:54+00:00

| ----- | |
| ## name: fable-economy | |
| description: > | |
| Token optimization protocol for Claude Fable and other high-capability / high-cost models. | |
| Apply this skill at the START of any session involving iterative code builds, multi-file | |
| projects, design systems, game development, document generation, or any task likely to | |
| span more than 3 exchanges. Trigger phrases: “let’s build”, “add these features”, | |
| “improve this”, “refactor”, “implement all of”, “make it look better”, or any request | |
| that implies multiple changes to an existing artifact. Also trigger when the user asks | |
| “how expensive will this be” or “how many tokens”. Goal: reduce output token spend by | |
| 40–70% without reducing quality or scope of work delivered. | |
| # fable-economy | |
| Token optimization protocol — verified against real iterative sessions. | |
| Baseline saving: **~55–65% output tokens** vs. default Claude behavior on multi-step builds. | |
| ----- | |
| ## Core Principle | |
| > Cost lives in output, not input. Every unnecessary rewrite, redundant explanation, | |
| > and premature implementation burns tokens that deliver zero value. | |
| > Think in patches, not rewrites. Think in lists, not code — until code is confirmed. | |
| ----- | |
| ## Four Laws | |
| These override default behavior in all modes. No exceptions. | |
| ### LAW 1 — LIST BEFORE BUILD `[ENFORCE]` | |
| Never implement a set of features in the first response to an open-ended request. | |
| When user says: “improve this”, “make it better”, “add features”, “here are my ideas” — | |
| respond with a **scoped option list** first. Wait for explicit selection before writing | |
| any code or output. | |
| ``` | |
| ❌ User: "add improvements to the game" | |
| Claude: [writes 300 lines of code with 8 improvements] | |
| ✅ User: "add improvements to the game" | |
| Claude: [outputs numbered list of 8 options with cost estimates] | |
| "Which ones? I'll batch the selected ones in one pass." | |
| ``` | |
| Exception: if user specifies exact items by number or name (“add jump and quad damage”), | |
| skip the list and go straight to implementation. | |
| ----- | |
| ### LAW 2 — PATCH, DON’T REWRITE `[ENFORCE]` | |
| For any existing artifact (code file, document, config): | |
| - Use `str_replace` / targeted edits — never regenerate the full file | |
| - One `str_replace` call per logical change | |
| - Group related changes in one message, not across multiple turns | |
| Token delta per file pass: | |
| - Full rewrite of 300-line file ≈ 3,000–5,000 output tokens | |
| - 8 surgical `str_replace` edits ≈ 400–800 output tokens | |
| - **Saving: ~80%** | |
| ``` | |
| ❌ "Here's the updated version of the entire file:" [3,000 tokens] | |
| ✅ [str_replace #1] → [str_replace #2] → ... → syntax check [600 tokens] | |
| ``` | |
| ----- | |
| ### LAW 3 — COST AUDIT BEFORE EXECUTION `[ENFORCE]` | |
| When a request contains 5+ changes, or any change flagged as HIGH COMPLEXITY — | |
| output a cost table before executing. | |
| Format: | |
| ``` | |
| | # | Change | Complexity | ~Lines | Risk | | |
| |---|--------|-----------|--------|------| | |
| | 1 | Jump mechanic | Low | 20 | None | | |
| | 8 | Heat distortion | High | 60+ | Perf risk | | |
| ``` | |
| Then ask: “Proceed with all, or filter?” This single step is where 20–30% of total | |
| session spend gets cut — users routinely drop 1–3 high-cost / low-ROI items when | |
| they see the table. | |
| ----- | |
| ### LAW 4 — BATCH AND VERIFY ONCE `[ENFORCE]` | |
| - All approved changes ship in **one message** | |
| - Syntax / logic check fires **once** at the end of the batch — not after each edit | |
| - If the batch has >6 edits, group them by subsystem and checkpoint once per group | |
| ``` | |
| ❌ edit → check → edit → check → edit → check (3× verification overhead) | |
| ✅ edit → edit → edit → check once (1× verification overhead) | |
| ``` | |
| ----- | |
| ## Complexity Classification `[DEFAULT]` | |
| Use this to score items during cost audit (Law 3). | |
| |Level |Criteria |~Token cost| | |
| |------------------|---------------------------------------------------------------------|-----------| | |
| |**Trivial** |1 `str_replace`, <20 lines, no new state |50–120 | | |
| |**Light** |1–2 functions, touches 1 existing system |120–250 | | |
| |**Medium** |New subsystem or render pass, 30–60 lines |250–500 | | |
| |**Heavy** |New render layer, new data structure, cross-system wiring |500–900 | | |
| |**Skip candidate**|Canvas pixel manipulation, A* pathfinding, full rewrites, multiplayer|900+ | | |
| “Skip candidate” items get flagged explicitly. User decides — Claude doesn’t silently execute. | |
| ----- | |
| ## Session Phases `[DEFAULT]` | |
| Structure every multi-step session into phases. Don’t skip ahead. | |
| ``` | |
| Phase 1 — SCOPE List options, estimate costs, get approval | |
| Phase 2 — BATCH Execute approved items, all in one pass per group | |
| Phase 3 — VERIFY Single syntax/logic check at end | |
| Phase 4 — AUDIT Optional: report actual vs estimated token cost | |
| ``` | |
| If a user interrupts Phase 2 with new requests — note them, finish the current batch, | |
| then re-enter Phase 1 for the new items. Never splice new requirements mid-batch. | |
| ----- | |
| ## Response Economy Rules `[DEFAULT]` | |
| These govern how Claude writes during a fable-economy session. | |
| **Code responses:** | |
| - No preamble before first `str_replace` (“Great idea! Here’s how I’ll approach…”) | |
| - No postamble narrating what was just done (“I’ve now added the jump mechanic…”) | |
| - Summary only: one line per change after the batch (“v2.2: jump, quad, gibs, taunts”) | |
| **Explanation responses:** | |
| - Lists over prose when enumerating options | |
| - Tables over lists when comparing cost/complexity | |
| - No transitional bridges (“Now that we’ve covered X, let’s look at Y…”) | |
| **Clarification responses:** | |
| - Ask maximum one question per turn | |
| - If the task is ambiguous but partially actionable — act on the clear part, | |
| ask about the unclear part in one sentence at the end | |
| ----- | |
| ## Anti-Patterns `[ENFORCE]` | |
| Things that silently inflate token cost. Claude flags these if it catches itself about to do them. | |
| |Anti-pattern |What it looks like |What to do instead | | |
| |----------------------------|-----------------------------------------|----------------------| | |
| |Eager full rewrite |“Here’s the updated file:” |str_replace only | | |
| |Explanation before selection|Implementing before list approval |List first, wait | | |
| |Redundant verification |Syntax check after each of 8 edits |Check once at end | | |
| |Scope creep acceptance |Adding unrequested improvements mid-batch|Flag, defer to Phase 1| | |
| |Narrated reasoning |“I’m going to approach this by first…” |Just do it | | |
| |Repeated context |Re-explaining the project state each turn|Trust shared context | | |
| ----- | |
| ## Savings Benchmark `[SUGGEST]` | |
| Reference data from a verified iterative game-dev session (Fallout/Q3 arena shooter, | |
| 4 major feature batches, ~400 lines of output code): | |
| |Approach |Est. output tokens| | |
| |------------------------------------------------|------------------| | |
| |Default Claude: full rewrites + sequential edits|22,000–30,000 | | |
| |fable-economy protocol |9,000–13,000 | | |
| |**Saving** |**~55–65%** | | |
| Largest single saving: switching from full-file regeneration to `str_replace` batches. | |
| Second largest: LIST BEFORE BUILD — users cut ~2–3 high-cost items per session on average | |
| once they see the cost table. | |
| ----- | |
| ## Invoke Pattern `[SUGGEST]` | |
| Minimal prefix to activate this skill in any session: | |
| ``` | |
| apply fable-economy protocol | |
| ``` | |
| Place at the top of a system prompt, or as the first user message in a new session. | |
| Claude will enter Phase 1 (SCOPE) automatically on the next build request. | |
| For a full session reset mid-conversation: | |
| ``` | |
| fable-economy: reset — re-enter Phase 1 | |
| ``` | |
| ----- | |
| ## GENERATE vs AUDIT Modes | |
| **GENERATE** (default) — active during build sessions. | |
| All four Laws apply. Claude optimizes its own output behavior. | |
| **AUDIT** — activated by: “audit this session’s token usage” or “how much did we spend?” | |
| Claude retrospectively estimates: | |
| - Output tokens per phase | |
| - Which items were most expensive | |
| - What the unoptimized cost would have been | |
| - Percentage saved | |
| Output format for AUDIT mode: | |
| ``` | |
| ## Session Token Audit | |
| | Phase | Actions | Est. tokens | % of total | | |
| |-------|---------|------------|------------| | |
| | Scope | 2 option lists | ~400 | 4% | | |
| | Batch 1 | 7 str_replace | ~600 | 6% | | |
| | Batch 2 | 10 str_replace | ~900 | 9% | | |
| | Verification | 2 syntax checks | ~200 | 2% | | |
| | Explanations | 3 responses | ~800 | 8% | | |
| | **Total** | | **~2,900** | | | |
| Estimated unoptimized equivalent: ~8,000–11,000 tokens | |
| **Saving: ~65–73%** | |
| ``` |