The Testing Academy · Field Guide · Frontier Models
Do this on your last day with Fable.
Tomorrow Fable 5 leaves your subscription and moves to pay-per-token credits. On a normal Claude plan, that arithmetic means one thing: it is gone for good. You cannot keep the smartest model available, but you can extract its intelligence into assets that outlive it. Five moves, each built so a cheaper model can use tomorrow what only Fable can create today, with the reasoning behind every one.
The Last Flat-Rate Day
Today is the last flat-rate day for a frontier model, and most of the advice on how to spend it is wrong. One test ranks everything, and it points at extraction, not conversation.
Thesis · extraction, not conversation
Spend it on what a cheaper model can't rebuild.
The lists going around say build a website, ship a few demo apps, generate a month of content. Every one of those fails the only test that should rank your day.
Spending the final hours of a frontier model on work a mid-tier model handles is like hiring a surgeon to take blood pressure. Opus, the everyday model that stays in your plan, rebuilds a website, a demo app, or a batch of posts next week for nothing. So the strategy for today is not to have a nice conversation, it is to make Fable write down everything it knows about your business before it leaves. Extraction over conversation. What you extract while you have access is what you keep once it is gone.
Why it mattersAn output gets consumed once; an asset compounds. The final hours of the smartest model should buy things that keep their value after the model behind them is out of reach.
Concept · the one test
The one test: can a cheaper model redo this tomorrow?
One question sorts everything you could do today. If the answer is yes, skip it.
Ask it of every task: can a cheaper model redo this tomorrow? A website, a demo app, a batch of posts, Opus rebuilds any of those next week for free, so they fail the test. What a cheaper model cannot redo tomorrow is anything that requires Fable-level judgment to create but only ordinary intelligence to use: a standard written down, a roadmap already reasoned through, a knowledge vault already distilled, a skill that fires on its own. Those keep their full value after the model is gone.
Why it mattersThe test is the whole strategy in one line. Run it before every task and the day sorts itself: throw away the disposable, keep only what needs this model to make and any model to use.
Precedent · the teacher dies, the students run
Distilled intelligence outlives the model.
This pattern is old. The most copied training dataset of the llama era was pulled straight out of a frontier model.
That dataset was built by extracting 52,000 answers from a frontier model and training a small open one on them, total generation cost under $500. The frontier model that taught it was later retired. The teacher is dead; everything trained on it still runs. Your day is the same shape at a smaller scale: pull the judgment out now, store it where a cheaper model reads it, and the insight keeps working long after the model that produced it is out of reach.
Why it mattersEvery teacher leaves. What you extracted is what you keep, and it does not depreciate when the model is re-priced or pulled.
The Five Moves
Each move turns Fable-level judgment into something a cheaper model can execute: a standard, a roadmap, a vault, an unattended loop, and a recorder that captures how it thinks.
Move 1 · plant judgment in your workspace
Make Fable write your standards down.
The highest-value artifact a frontier model leaves behind is a standard. An answer helps you once; a standard upgrades every answer that comes after it.
Your CLAUDE.md, your skills, your learnings files, your memory setup: this is the layer every future model reads before it touches your work. Today, Fable writes that layer at a level Opus can follow but could never author. The criteria line is the point, a cheaper model cannot invent a quality bar, but it applies a written one perfectly. Run this in every project you care about.
You have deep context on this project. Before your access changes, write the standards a cheaper model will follow after you. Update CLAUDE.md with: - the decision criteria you use here (what "good" looks like, and the quality bar each output must clear before it ships) - our conventions: stack, structure, naming, testing, review gates - the traps specific to this codebase and how to avoid them Write it so an ordinary model can apply the bar without re-deriving it. Criteria over examples. Then list what you were unsure about.
Why it mattersOpus does not need to be brilliant, it needs to follow a brilliant document. The standard is the multiplier every later session inherits for free.
Move 2 · the consultant audit
Point that judgment at the business.
Fable's verified edge is judgment on hard, messy problems. On the hardest coding benchmark tier it scores more than double the next model, and the gap widens as difficulty rises.
So give it the hardest messy problem you own: your business. Open a session with access to your projects, your numbers, whatever context you can feed it, and have it act as the consultant. The deliverable rule carries the value: the reasoning gets written down today, while the model that can produce it is flat-rate, so tomorrow Opus just executes it. A roadmap is only as good as the knowledge underneath it, which is the next move.
Act as a senior consultant with full access to this business. Here is the context: [projects, numbers, constraints, goals]. Find the highest-leverage problem I am not solving, reason through it end to end, and produce a roadmap a competent but ordinary model can execute step by step next week: - the decision and why, with the tradeoffs you weighed - the sequence of steps, each with a done-condition - the risks and how to detect them early Write the reasoning down, not just the plan. Assume the executor is capable but not brilliant.
Why it mattersThe reasoning is the asset, the plan is just its shadow. Capture the thinking today and any model can carry out the roadmap tomorrow.
Move 3 · the second brain
Deep research, mined into an atomized vault.
Research is where the extraction runs deepest: long multi-step synthesis is Fable's widest measured lead over every other model.
Spend a slice of today on volume: deep research runs on your niche, your competitors, your customers' problems, the methods you keep meaning to study. Then mine every run into an Obsidian vault, the free note app where each note links to related notes, one insight per note. Do not summarize into one long report. A hundred linked one-insight notes get retrieved and reused; a 40-page report gets stored and forgotten. The vault becomes the context every future session reads.
Take this research run and mine it for my Obsidian vault. Do NOT write a summary report. Output atomized notes, one insight per note: - a short, specific title per note (the claim, not the topic) - the insight in 2-4 sentences, self-contained - [[links]] to the other notes it connects to - the source it came from Aim for many small linked notes over one long document.
Why it mattersRetrieval beats storage. A linked note surfaces exactly when a future task needs it; a long report sits unread.
Move 4 · fire the goals
Spend the unattended hours you actually lose.
Fable's signature capability is holding one job for hours without losing the plot. That endurance is exactly what stops being flat-rate tomorrow, so today it goes to work.
Two commands in Claude Code do it. /goal sets a finish line instead of a prompt: you describe what done looks like, and the model keeps working turn after turn while a second, smaller model checks the condition after every turn and only stops when it is met. Dynamic workflows are the scale layer: the model writes an orchestration script that runs dozens of subagents in the background, in parallel, cross-checking each other while your session stays free. A /goal holds the finish line, the workflow does the fan-out.
Two rules make this safe instead of expensive. First, demand pasted proof in the finish line: the judge reads only the conversation, it cannot run your tests or open your files, so the condition asks for the green run pasted, never promised. Second, cap every run, in turns or wall-clock, written into the condition, because one unattended loop without a cap can bill $6,000 by morning. And mind the meter: Fable burns weekly limits roughly twice as fast as Opus, and only half your weekly limit applies to it in the first place. Pick the two or three goals with the most locked-up value, not ten.
/goal Ship feature X to a passing state. DONE only when: the full test suite output is pasted into this chat showing 0 failures, AND the lint run is pasted clean. Do not claim success without the pasted output. HARD CAP: stop after 25 turns or 90 minutes, whichever first, and report where you stopped. # then let the model author and run the fan-out: > Write a dynamic workflow that splits this across parallel subagents and cross-checks their findings, then run it.
Why it mattersEndurance is the one thing you literally lose tomorrow. Proof plus a cap turns an unattended frontier loop into banked work instead of a surprise bill.
Move 5 · the skill recorder
A skill that records how Fable thinks.
Every time Fable cracks a hard problem today, its approach evaporates when the session ends. This move installs a recorder.
The first four moves extract what Fable knows. This one extracts how it thinks, automatically, for the rest of the day. Create the skill file, then wire it into CLAUDE.md so it fires without being asked. From then on, work Fable hard on your real backlog, the gnarly bug, the architecture decision you have been circling, and every solve leaves a note behind: Fable's reasoning, sitting in your repo, readable by every model that comes after. This is the compounding move, and it is the one to install first.
--- name: extract-approach description: After solving any non-trivial problem, document the approach so a less capable model can replicate the thinking. Fires after a hard bug, an architecture decision, a tricky build, or any solution that took real reasoning. --- Write one under-a-page note to learnings/<date>-<slug>.md: - the problem, in one line - the approach: how it was decomposed, in plain steps - the judgment calls: what was deliberately NOT done, and why - the reusable rule: the one-line principle to apply next time Write it so a weaker model reading it cold could follow the path.
## Learning law
After every non-trivial solved problem, invoke the
`extract-approach` skill before moving on. Do not wait to be
asked: a matching solve is an implicit trigger. A solution
without its learnings note is unfinished work.
Why it mattersIt converts all your remaining Fable time into permanent assets, automatically. If you only have an hour, install this first: every solve after it distills itself into your repo.
Keep the Playbook
The order to run the moves in when time is short, and why this exact situation will keep repeating.
Playbook · the order, and the pattern
Run them in this order, then keep it.
If time is short: move 5 first, because it runs itself; then move 4, because it runs alone; then 1, 2, 3.
Install the recorder first so every later solve is captured automatically. Fire your highest-value goals next so the unattended hours are working while you do everything else. Then plant the standards, run the consultant audit, and build the second brain. After tomorrow, this situation repeats the pattern of the last stretch: a frontier model appears, gets re-priced, gets pulled, sometimes comes back, eventually retires. One major model was removed with no notice, resurrected after the backlash, then retired anyway six months later. Outputs you do not save while you have access cannot be reconstructed once it is gone. Keep this playbook, and the next time a frontier window opens, you will not spend it on demo apps.
Why it mattersEvery teacher leaves; what you extracted is what you keep. The playbook is reusable because the cycle is: it will happen again with the next model.