Fable 5 Leaves July 12. Make it train its replacement before it does.

Few days back I posted a tweet about making Fable 5 train its replacement before it goes pay per use.

It did over 600K views and 4,600 bookmarks. And my DMs have not stopped since. Everyone is asking the same question: what does the full setup actually look like?

Then Anthropic extended Fable 5 through July 12. Which means everyone who bookmarked that tweet just got a second chance to actually run the play.

So instead of answering DMs one at a time, I am writing the whole thing down.

I run an AI agency at $20K MRR, an AI app studio, and this is the exact play I am running on our own repos before the window closes.

Here is the full breakdown.

What This Play Actually Is

Fable 5 is the most expensive model Anthropic has ever shipped. When the window closes on July 12, it bills at $10 per million input tokens and $50 per million output. Double the price of Opus.

Right now it is included in every paid plan. In a few days, every Fable call becomes a purchasing decision.

The move came out of r/ClaudeAI, and it is the smartest thing I have seen anyone do with the free window:

Have Fable 5 write Skills for the models you will actually keep using.

Skills are the files Claude Code loads to know how to behave in your project. Most people write them by hand, badly, or download packs of them they never needed. This play flips it. The smartest model you will ever have at a flat rate encodes its judgment into files that Opus and Sonnet will run on every future session, long after Fable is behind credits.

Credit where it is due: u/oj93-rd surfaced the idea on r/ClaudeAI, and u/Rodbourn wrote the prompt that turns it into a system. The framing is the genius part. You do not ask Fable to "write some skills." You tell it this:

"You are a distinguished fellow on this project who is retiring. Your final task: build a complete skill library so that junior engineers and smaller AI models can carry this project forward without you."

A retiring senior engineer doing a proper handover. That one framing changes everything about what it writes.

The Problem With How Most People Are Spending the Window

The extension made this worse, not better. Five extra days sounds like breathing room, so people went right back to treating Fable like any other model.

Here is the filter I use: everything you do with Fable this week is either a conversation or an asset.

Conversations die when the session ends. The demo you ran, the clever question you asked, the "look what it built" screenshot. All gone the moment the window closes.

Assets keep working after the model is gone. A skill library is an asset. Every future session of Opus or Sonnet, for months, runs at a higher standard because of work Fable did once, for free.

You have until July 12. Build assets.

Here is the exact setup, step by step.

Step 1 - Pick the Repo and Budget the Run

Two decisions before you touch the prompt.

Pick ONE repo. Your most important, longest-living project. Not a weekend experiment. The play only pays off on a codebase that cheaper models will keep working on for months.

Budget the usage. This is the expensive part, and I am not going to pretend otherwise. The full run burned a bit over 40% of my weekly Fable usage on the 20x Max plan. The prompt literally tells Fable that token cost is not a constraint, correctness is.

That number is why you run this on one repo, not five. And it is still the best trade available this week: 40% of one week's usage for a permanent upgrade to every session that comes after.

Step 2 - Run the Prompt

The full generalized prompt lives on GitHub:

github.com/tomicz/fable-5-train-opus-skills-after-it-retires

Open Claude Code with Fable 5 selected, paste the whole thing, and let it go.

What most people miss: this is not one instruction. It is a three-phase system, and the phases are why the output is good.

Phase 1 is pure discovery. No writing allowed. Fable investigates your repo the way an incoming senior engineer would. The README, the build system, how the test suite actually runs, CI config, and the part I love most: your git history. What changed, what got reverted, what stalled on dead branches. Your repo's scar tissue.

Phase 2 authors the library with parallel agents. One agent per skill, 10 to 16 skills total, adapted to what Phase 1 found.

Phase 3 reviews everything. Three parallel reviewers check the complete set for factual errors, contradictions, and usability, then a fixer applies the corrections. Fable QAs its own handover before giving it to you.

Step 3 - Answer the Five Questions Like It Matters

Here is the part nobody talks about, and it is where the quality of your entire library gets decided.

At the end of Phase 1, Fable interviews YOU. At most five questions, only about things the repo cannot tell it:

→ What is the hardest live problem right now

→ What unwritten rules exist that no doc states

→ Who is this library for, and what do they NOT know

→ What past failures cost the most time

→ What would "beyond state of the art" mean for this project

Do not rush these. Your answers get folded into every skill it writes.

When I say the model encodes judgment, this is the mechanism. The repo gives it the facts. Your answers give it the war stories. The combination is what a real retiring engineer would leave behind, and it is exactly what a Sonnet session six months from now will not have unless you write it down here.

Step 4 - Know What You Are Getting

The taxonomy in the prompt is worth reading on its own, because it doubles as a checklist of everything a well-documented project should have. The core set:

→ Change control. How changes get classified, gated, and reviewed here, with the historical incident behind each rule

→ Debugging playbook. A symptom-to-triage table for YOUR project's failure modes, each trap with its story

→ Failure archaeology. Every major dead end, rejected fix, and revert, mined from git history, so nobody re-fights a settled battle

→ Architecture contract. The load-bearing design decisions, why they were made, and the known weak points stated plainly

→ Build, run, config, validation, docs. The operational runbooks that make the project boring to operate

Then the advanced layer, and this is where the prompt earns its stars. Skill 13 is a decision-gated campaign for your hardest live problem: numbered phases, exact commands, expected observations at every gate, and the wrong paths explicitly fenced off. It is a battle plan for the thing that is currently hurting you, written by the smartest model you will ever run on that repo.

Every skill follows the same authoring rules: written for a zero-context mid-level engineer or a Sonnet-class model, copy-pasteable commands, verified against the repo before stated, and each one says when NOT to use it.

That last rule matters more than it looks. Wrong runbooks are worse than none.

Step 5 - Review, Prune, and Hand It to the Cheap Models

The run ends with Fable giving you the skill inventory, what it verified by spot-check, and what remains uncertain. Read that report.

Then do two things before you trust any of it.

Review the judgment calls. Fable encodes its opinions, including ones you might disagree with. Ten minutes of review protects hundreds of future sessions.

Prune without mercy. If it wrote 16 skills and only 10 are load-bearing, delete the rest. Skills load into context. A bloated library makes every future session dumber, which is the exact problem this play exists to solve. If you read my Claude Code skills article from this week, you already know: the builders getting the most out of skills are running fewer of them, not more.

Then the payoff. Open a fresh session on Opus or Sonnet, give it a real task, and watch it pull the debugging playbook or the change-control rules before touching your code. That is Fable's standard, running on a model you can actually afford after July 12.

One more move while you are in there: do not just have Fable write new skills. Point it at the skills you already have.

I ran this on my own library before writing this article. The results:

→ My skills came out 30% shorter on average, with everything still working

→ One skill dropped from 210 lines to 80 with zero behavior change

Shorter skills are not just cleaner. Skills load into context, so every line of fat you cut is context you get back on every single session. An overloaded skill library makes Claude dumber, not smarter.

The prompt is one line: "Read every skill in this project. Optimize each one for brevity and correctness without changing behavior. Show me a diff per skill before writing."

Same play, same window. Fable's judgment, applied to files that outlive it.

When To Run This

Not everyone has the usage budget for the full run. Priority order by plan:

→ On a Max plan: run the full prompt on your most important repo, today. You have the budget for exactly one or two of these before July 12.

→ On a standard paid plan: run it on your single most important repo and accept that it may eat most of your week. It is still the best use of that week.

→ Almost out of usage: skip the full run. Have Fable rewrite your CLAUDE .md instead, informed by your git history. One file, a fraction of the cost, and it still outlives the window.

What To Watch Out For

→ The 30% usage number is real. Budget for it, run it on one repo, and do not start the run the day your weekly limit resets to zero.

→ Answer the five questions properly or skip the play. Lazy answers produce a generic library, and a generic library is what you could have downloaded from a skills pack for free.

→ Review before you trust. Fable verifies commands against the repo, but it also encodes judgment calls. Those are yours to accept or reject.

→ Temper the "Fable brain in Sonnet" expectations. A skill library transfers process, not intelligence. You are keeping the standards, the playbooks, and the war stories. Nobody is getting Fable's reasoning in a cheaper model through one magic file, whatever the timeline is telling you this week.

What This Actually Means

The window closing is not the story. The story is that for a few more days, you can point the best model Anthropic has ever shipped at your own project and have it leave permanent upgrades behind.

This is also the direction everything is heading. Frontier models will keep launching at prices most builders cannot run daily. The builders who win will not be the ones who can afford the biggest model every day. They will be the ones who know how to extract a model's judgment into assets while they have access, and run those assets on models they can afford.

Most people will spend the next few days generating conversations. The builders who spend them generating assets will still be collecting the returns in December.

2026 is going to be UNFAIR for builders who move early on this.

TLDR

→ Fable 5 is extended through July 12, then it goes pay per use at $10 per million input and $50 per million output

→ The play from r/ClaudeAI: have Fable write a complete skill library so Opus and Sonnet carry its standards after it is gone

→ The framing is the unlock: Fable acts as a retiring senior engineer doing a full handover

→ Three phases: it investigates your repo, interviews you with five questions, writes 10-16 skills with parallel agents, then reviews its own work

→ Full prompt is free on GitHub (credit u/oj93-rd for the idea, u/Rodbourn for the prompt)

→ Budget for it: the run can eat 30% of your weekly Fable usage. Worth it.

→ Review the output, prune what is not load-bearing, and hand the library to your cheaper models

→ Assets over conversations. Everything else expires on July 12.

LFG.

Links

• github.com/tomicz/fable-5-train-opus-skills-after-it-retires