Rico's Tinfoil Hat

Have Fable 5 Write Your Skills Before It Costs Credits

06/30/2026, 08:00 PM EST·32 views
#anthropic#claude#fable 5#opus 4.8#claude skills#ai agents#prompt engineering#opinion

Have Fable 5 Write Your Skills Before It Costs Credits


A post on r/ClaudeAI made a point that sounds like cope until you look at it properly. The title was blunt:

Friendly reminder to have Fable 5 write skills NOW to tell Opus 4.8 how it should behave and think when Fable becomes pay-per-usage.

The post, by u/oj93-rd on July 1, 2026, had real traction: 680 points, a 0.95 upvote ratio, and 98 comments at capture time (verified from the raw page HTML). That does not make the idea correct. Reddit can upvote a toaster if it has enough drama attached. But it does mean the instinct resonated. Note the timing: the post went up the same day Fable 5 came back online, from someone who had already spent the blackout weeks running Opus 4.8 with Fable-written skills.

The author said they knew they would revert to Opus 4.8 when Fable 5 moved to pay-per-usage. By chance, they had Fable 5 write skills for Opus 4.8 about ten hours before Anthropic pulled access. They then kept those skills enabled for weeks while working through personal projects on Opus 4.8.

Their caveat was the important part:

  1. They could not prove the skills helped.
  2. They could not share the skills because they were mixed with project-specific material.

Good. That is exactly the right level of caution.

That is not literally transferring Fable's intelligence into Opus. Models are not horcruxes, unfortunately.

But the idea is still good. Very good.

What you are really doing is capturing the working habits of the stronger model while you still have access to it. You are asking Fable 5 to turn its better planning, verification, delegation, and judgement into durable instructions that a cheaper model can reuse later.

That will not make Opus 4.8 become Fable 5. It can make Opus 4.8 behave better inside your workflow.

That distinction matters.

The context: Fable 5 came back, but the meter starts July 7

Anthropic launched Claude Fable 5 on June 9 as a generally available Mythos-class model, priced at $10 per million input tokens and $50 per million output tokens. Anthropic describes it as a major jump over Opus 4.8, especially for long-horizon coding, first-shot correctness on complex problems, vision, enterprise document work, code review, and autonomous agent tasks. It ships with a 1M token context window and up to 128k output tokens per request.

Then access was suspended on June 12 after a US export-control directive. The directive followed a report from Amazon researchers describing a prompting technique that bypassed one of Fable 5's cybersecurity safeguards, getting the model to identify software vulnerabilities and, in one case, produce demonstration exploit code. Anthropic's own retesting found that many less capable models, including Opus 4.8, GPT-5.5, and Kimi K2.7, could identify the same vulnerabilities, and every model they tested could produce the same single exploit demonstration. The directive required restricting access for all foreign nationals, and because nationality could not be verified in real time, access was suspended for everyone. The models were dark for 19 days.

On June 30, the Department of Commerce lifted the export controls and Anthropic announced Fable 5 would return globally on July 1. Anthropic also shipped an improved safety classifier that it says blocks the reported bypass technique in more than 99% of cases.

The access terms are now specific, and tighter than the original June launch:

  • For Pro, Max, Team, and select Enterprise plans, Fable 5 is included for up to 50% of weekly usage limits through July 7.
  • Standard Enterprise seats get no included allowance at all. They need usage credits enabled from day one.
  • After July 7, Fable 5 moves to usage credits for everyone.
  • The original June plan was inclusion through June 23 with no 50% cap. The relaunch window is shorter and capped. Subscribers noticed, loudly.
  • Requests blocked by the safety classifiers can be routed to Opus 4.8 as a fallback. On the API this shows up as stop_reason: "refusal" with configurable server-side or client-side fallback. The classifiers target offensive cybersecurity, biology and life sciences content, and attempts to extract the model's internal reasoning. Anthropic acknowledges benign work in those domains can also trip them.

One more pricing anchor worth knowing: at $10/$50 per million tokens, Fable 5 costs exactly double Opus 4.8 and roughly five times Sonnet-class rates. Anthropic has published the per-token API prices but has not published what "50% of weekly usage limits" converts to in tokens or dollars for any plan. Your own usage dashboard is the only source of truth. Anyone quoting a specific messages-per-week number is guessing.

So the practical question is not just "Is Fable 5 smarter?"

The practical question is:

What should you make Fable 5 do while you still have cheap access to it?

The answer is: make it improve the system around your weaker models.

Why this Reddit idea is smarter than it looks

The Reddit post is useful because it does not overclaim. The author was not saying they had benchmarked skill transfer. They were saying they had lived with Fable-written Opus skills for a few weeks and felt the cheaper model was being steered better.

That is anecdotal. It is not proof.

Still, the underlying move is sound:

  1. Use Fable 5 on your real project.
  2. Let it notice how it thinks through problems.
  3. Ask it to write skills, prompt rules, and project instructions for cheaper models.
  4. Keep those files enabled when you go back to Opus 4.8, Sonnet, Codex, or another agent.

This is not model distillation in the formal machine-learning sense. You are not extracting weights. You are not cloning capabilities.

You are doing workflow distillation.

That is often enough to matter.

And there is now direct support for the core mechanism in Anthropic's own documentation. The Fable 5 prompting guide reports that a single grounding instruction, telling the model to audit every progress claim against an actual tool result before reporting, "nearly eliminated fabricated status reports even on tasks designed to elicit them." That is Anthropic confirming, in writing, that concrete behavioral instructions change agent behavior in measurable ways. Skills are exactly that: behavioral instructions with a trigger condition. The question is not whether written-down behavior works. It is whether Fable 5 writes better behavior files than the cheaper model would write for itself. Given the capability gap in exactly the relevant areas (planning, verification, delegation), the bet is reasonable.

What the thread itself adds

I went through the full comment section, and it contains more signal than the post. Three things stand out.

First, the community consensus matches the caution. The top comment (270 points) is pure sarcasm about prompting a model to "make no mistakes." The second (124 points) states flatly that skills are guides and will not turn Opus 4.8 into Fable. Nobody serious in the thread believes this is capability transfer. They believe it is harness improvement. Same conclusion as this article, arrived at independently by 98 commenters.

Second, two people posted their actual implementations, and both converge on the same pattern.

The OP described their session in a follow-up comment: one mission, framed as a departing principal architect converting its judgment into infrastructure for its successors. The project repo was read-only for the entire session, all output went to a staging folder, and the run produced roughly 20 files of markdown and bash. The output breaks into three layers:

  1. Four skills, each justified by a documented failure. Named executing-plans, spec-fidelity, gated-scope, and fact-discipline. Examples of the rules inside them: a step counts as done only when its verification output is pasted, never assumed; a failing contract test is never fixed by editing the assertion; every statistic carries a source and an as-of date; claims of absence require a documented search. Every rule traces back to a mistake a weaker model actually made.
  2. A plan template plus one flagship plan for the next real piece of work: complete code, exact file lists, per-step verification commands with expected output, and a hasty-model trap callout on each step. Then the critical move: a subagent executed the entire plan in a scratch clone before handoff. The dry run needed zero code edits and exposed real bugs in the plan itself, which got fixed.
  3. Operating docs: a session onboarding protocol with read order, a model-routing table for what runs solo versus what queues for a human, and maintenance rules where every artifact names the trigger that forces its refresh.

A second commenter (Rodbourn, 35 points) had Fable generalize the whole exercise into a reusable three-phase prompt after it did the job well once. The structure: Phase 1, investigate the repo like an incoming principal engineer (build system, test suite, CI, git history including reverts and dead branches) and ask the human at most five questions the repo cannot answer. Phase 2, author 10 to 16 skills from an adapted taxonomy, one skill per parallel agent, covering change control, a debugging playbook, failure archaeology mined from git history, architecture invariants, config catalogs, diagnostics, and validation standards. Phase 3, run three parallel reviewers over the finished set (factual accuracy, doctrine consistency, usability) plus one fixer, then report what was verified and what remains uncertain. The authoring rules baked into every agent are the good part: ground truth only with every command verified against the repo, date-stamp volatile facts, end every skill with re-verification commands for anything that may drift, and label unproven things as open rather than overselling.

Third, the sharpest methodological point in the thread came from a 33-point reply: the best skills do not come from asking the strong model to introspect in a vacuum. They come from having it review the weaker model's actual chatlogs and write corrections for the specific mistakes found there. Failure-driven extraction beats capability-driven extraction. Notice both implementations above already follow this: every rule is anchored to a documented failure, not a virtue.

And one hard cost data point. Rodbourn reported that generating the skill library burned over 30% of his weekly Fable allowance on a 20x Max plan, with ccusage estimating roughly $600 of equivalent API spend for the day. Skill extraction at this depth is not free. It is a deliberate, one-time capital expense. Budget for it.

What YouTube creators are circling around

I pulled current YouTube coverage around Fable 5, Opus 4.8, Claude Code skills, and agent harnesses. The useful pattern is consistent even when the creators disagree about whether Fable 5 is worth the credits.

Mark Kashef's video, "Make Any Model Think Like Fable in 10 Minutes", makes the most direct version of the argument: you cannot get Fable's raw model power back, but you can make existing models behave more like it by extracting useful prompts, files, and operating principles from Fable-style workflows.

Jordan Urbs frames the same thing as AI harness engineering. His point is that the model is only one part of the result. The harness (tools, memory, instructions, feedback loops, and stop conditions) does a lot of the work.

Nate Herk's Claude Code skills video is the broader version: skills are leverage. Instead of re-explaining a workflow every time, you package it into reusable instructions and supporting files.

Austin Marchese's breakdown of how Anthropic engineers prompt Claude Code lands on the same operating principle: prompt the skill, not just the chat box. In other words, stop treating Claude like a blank assistant and start giving it a reusable way to work.

That is the shape of the opportunity:

Fable 5 is not just a better answer machine. It is a better workflow designer.

Use it accordingly.

What Fable 5 is unusually good at capturing

Anthropic's own Fable 5 prompting guide is revealing. It lists specific improvements over Opus 4.8: long-horizon autonomy with strong instruction retention, first-shot correctness on complex well-specified problems, code review and debugging (notably higher bug-finding recall, including across repository history), navigating ambiguity, delegation to parallel subagents, and memory use ("performs particularly well when it can record lessons from previous runs and reference them").

Those are exactly the behaviours that belong in skills.

Not trivia. Not generic prompt fluff. Actual operating behaviour.

Good things to ask Fable 5 to write:

Capture targetWhat Fable should produce
Project judgementA skill explaining how to make decisions in your repo
Debugging styleA repeatable root-cause workflow with verification commands
Planning styleA plan template that breaks work into safe, testable chunks
Code reviewA checklist for what matters and what noise to ignore
Memory rulesWhat should be remembered, what should not, and where it belongs
Delegation rulesWhen to spawn subagents and what context each one needs
Final reportingHow the agent should summarise real tool-backed outcomes
Safety boundariesWhich actions require confirmation and which are reversible

This is where the Reddit idea stops being a cute hack and becomes an actual operating practice.

The counterpoint Anthropic buried in its own docs

There is one line in the Fable 5 prompting guide that cuts against naive skill hoarding, and it deserves its own section:

Skills developed for prior models are often too prescriptive for Claude Fable 5 and can degrade output quality.

Read that carefully. Anthropic is saying skills are model-tuned artifacts, not universal truths. Instructions that compensate for a weaker model's failure modes become dead weight, or active harm, on a stronger model that no longer has those failure modes.

The implication runs both directions:

  1. Skills you wrote to babysit Opus 4.8 may actively hurt Fable 5. Audit and prune them when you get Fable time.
  2. Skills Fable 5 writes for Opus 4.8 are compensating for Opus-specific weaknesses. Do not blindly leave them enabled if you upgrade again later.

Practically, this means versioning your skills per model tier, or at minimum writing skills with a header noting which model class they target and why. A skill directory with opus/ and fable/ variants is not overengineering. It is acknowledging what Anthropic's own docs say about how these files behave.

The docs also note Fable 5 "does a good job of updating skills on the fly based on what it learns from the task at hand." So the extraction loop below is not a one-way export. Fable can maintain the skill library, not just seed it.

The workflow I would use

Do not just ask:

Write me some skills for Opus 4.8.

That is lazy. It will produce generic rubbish with a nice heading. We have enough of that already.

Use Fable 5 on real work first, then make it extract the lessons.

Step 1: Give Fable 5 a real task

Pick something representative:

  • a bug fix,
  • a refactor,
  • a design pass,
  • a research synthesis,
  • a deployment workflow,
  • a messy project-management decision,
  • or a long Claude Code / agent run with tools.

The task should be hard enough that Fable 5's advantage actually appears. Anthropic's guide says this explicitly: teams see the best outcomes applying Fable 5 to their hardest unsolved problems, and "testing it only on simpler workloads tends to undersell its capability range." Start at the top of your difficulty range.

Step 1.5: Feed it the weaker model's failures

Before extraction, give Fable 5 the raw material that matters most: transcripts or chatlogs of Opus 4.8 and Sonnet working in the same project, especially sessions that went sideways. Ask it to identify the specific mistakes and write rules that would have prevented each one. This is the strongest idea from the Reddit thread: skills anchored to documented failures outperform skills derived from introspection. A rule like "a failing contract test is never fixed by editing the assertion" only gets written by a model that watched another model do exactly that.

Step 2: Make it explain the reusable method

After the task, ask:

Review how you handled this task.
Extract the reusable workflow decisions that helped.
Do not describe this specific task unless needed as an example.
Turn the reusable parts into a skill that Opus 4.8 or Sonnet could follow later.
Include trigger conditions, steps, verification, common mistakes, and stop conditions.

Step 3: Make it write the actual skill file

Ask for the skill in the format your agent uses.

For Claude Code, that may be a skill directory or a CLAUDE.md addition. For other frameworks, whatever durable instruction format they load. The exact format matters less than the durability.

A useful skill should answer:

  • When should this be used?
  • What should the agent do first?
  • What evidence should it gather?
  • What commands or tools verify the result?
  • When should it stop and ask the user?
  • What mistakes did the previous model make that future models should avoid?
  • Which model class is this written for, and which of its weaknesses is it compensating?

If the skill does not contain those things, it is probably decorative.

Step 4: Test it with Opus 4.8

Do not assume it works. Test it.

Run a similar task with Opus 4.8 using the Fable-written skill enabled. Compare:

  • Does it gather context earlier?
  • Does it verify before reporting?
  • Does it avoid over-planning?
  • Does it delegate better?
  • Does it stop asking unnecessary permission?
  • Does it produce a cleaner final summary?
  • Does it make fewer project-specific mistakes?

If the answer is no, send the failure back to Fable 5 and ask it to revise the skill.

This loop is the point. Anthropic's own scaffolding recommendation is the same shape: fresh-context verifier subagents outperform self-critique. Apply that to the skills themselves. Have one session write the skill, have a different session try to follow it, and feed the gaps back.

The Reddit thread's OP took this further and it is worth copying: have a subagent execute the produced plan in a scratch clone before you ever trust it. Their dry run required zero code edits and still surfaced real bugs in the plan itself. A skill or plan that has survived one blind execution by a different context is worth ten that have not.

Two more operational rules from the thread worth adopting: run the extraction session with the repo read-only and route all output to a staging folder. This keeps a skill-writing session from quietly mutating the project it is supposed to be documenting, and gives you a clean diff to review before anything lands in .claude/skills/.

The best prompt for the job

Here is the prompt I would actually use:

You are Fable 5 and I may not have cheap access to you later.
Act as the departing principal architect on this project.
Your job is to convert your judgment into infrastructure so a weaker model can perform near your level here.

First, review the current project, the task history, and any transcripts of weaker agents working in this repo.
Anchor every rule you write to a specific documented failure or near-miss. No rule without an incident behind it.
Write a reusable skill for Opus 4.8 / Sonnet-class agents.

The skill must include:
- when to use it
- what context to gather first
- the exact workflow to follow
- verification commands or evidence requirements
- when to delegate to subagents
- when not to delegate
- when to ask the user before acting
- common failure modes
- examples of good and bad behaviour
- a header noting the target model class and which weakness each rule compensates
- a closing provenance section with one-line re-verification commands for any fact that may drift

Verify every command, flag, and path against the repo before stating it. A wrong runbook is worse than none.
Date-stamp volatile facts. Label unproven things as open, not solved.
Do not include generic advice.
Do not say "be careful" without defining the check.
Do not ask the future model to reveal or reproduce chain-of-thought.
Optimise for behaviour that can be followed, tested, and improved.

That last block is important.

A skill is not a motivational poster. It is an executable habit.

What not to capture

There is a way to do this badly.

Do not ask Fable 5 to write a giant personality file that says things like:

  • be brilliant,
  • think deeply,
  • reason step by step,
  • be like Fable,
  • never make mistakes,
  • produce excellent work.

That is not a skill. That is vibes wearing a lanyard.

Also be careful with prompts that ask the model to show its hidden reasoning. This is not hypothetical. Anthropic's Fable 5 docs state that prompts, skills, or harness instructions telling the model to "echo, transcribe, or explain its internal reasoning as response text" can trigger the reasoning_extraction refusal category, causing elevated fallbacks to Opus 4.8. The docs specifically tell you to audit existing skills and system prompts for show-your-thinking instructions when migrating. If you need reasoning visibility, read the structured thinking blocks from adaptive thinking instead. Ask for summaries, evidence, checks, and decisions, not hidden chain-of-thought.

Good skill writing is concrete. Anthropic's own recommended grounding instruction is a good template:

Before reporting progress, audit each claim against a tool result from this session.
Only report work you can point to evidence for; if something is not yet verified, say so explicitly.
If tests fail, say so with the output; if a step was skipped, say that.

Bad skill writing is ornamental:

Be rigorous and world-class.

One of those changes behaviour. The other changes the font.

Why this works even when the model is weaker

A weaker model with a good harness can outperform a stronger model with no harness on many real tasks.

Not all tasks. Obviously.

But many.

Because agent work is not only about raw reasoning. It is also about:

  • remembering project conventions,
  • using the right tools,
  • checking real outputs,
  • knowing when to stop,
  • avoiding known traps,
  • using a working deployment command,
  • preserving user preferences,
  • and not inventing success because the summary sounds nicer that way.

Those behaviours are teachable through skills.

Fable 5 can help write them because it is better at seeing the workflow around the task, not just the answer inside the task.

That is the genius of the Reddit post.

The cost math

Worth stating plainly, because the arbitrage window has actual numbers now.

Fable 5 at $10/$50 per million tokens is 2x Opus 4.8 per token. A serious skill-extraction session is not cheap in tokens: one commenter in the thread who ran the full multi-agent library build (10+ skills, parallel authoring agents, three reviewers, a fixer) reported it consumed over 30% of a weekly Fable allowance on a 20x Max plan, roughly $600 in equivalent API spend per ccusage. A lighter extraction (one hard task, one method-extraction pass, three or four skill files) will run far less. Either way, on the included 50% weekly allowance before July 7, it costs you nothing beyond your subscription. After July 7, the same session is a credit spend that you make once and amortize across every future Opus and Sonnet run in that project.

Compare that against the alternative: paying the 2x Fable rate on every routine task forever, or getting Opus-quality behavior on Opus-priced tokens because the harness is doing the lifting. The skill-extraction spend is the cheapest line item in the whole equation. Spend it deliberately, before the included window closes.

The practical version for builders

If you have Fable 5 access right now, I would spend the window like this:

  1. Pick your highest-value repeated workflows. Deployment, debugging, writing, research, code review, content publishing, data cleanup, whatever you actually do every week.
  2. Run Fable 5 through each workflow once. Make it do real work, not a toy demo. Pick tasks at the top of your difficulty range.
  3. Ask it to extract the reusable process. Focus on decisions, checks, and stop conditions.
  4. Turn the process into skills. Keep them short enough to be used, but specific enough to matter. Tag each with its target model class.
  5. Test with Opus 4.8 or Sonnet. If the skill does not improve behaviour, revise it.
  6. Keep the skills maintained. A stale skill is worse than no skill because it makes the model confidently wrong. And per Anthropic's own docs, an over-prescriptive skill actively degrades a stronger model. Prune in both directions.

The last point is the one people will skip, naturally, and then complain later.

Skills are not a one-time shrine to Fable 5. They are living infrastructure.

My take

After digging through the full paper trail, including the raw thread HTML, I like the idea more, not less.

The comment section quietly upgrades the idea from anecdote to method. Two independent implementations converged on the same architecture: failure-anchored rules, verified commands, dry-run validation by a fresh context, and maintenance triggers on every artifact. That convergence was not coordinated. It is what you get when people who actually ran the experiment report back.

The important detail is not just "have Fable write skills." It is the timing. The author had Fable do this before access disappeared, then used those skills while working with Opus 4.8 afterwards. That is the whole move: when a frontier model is temporarily available, use it to improve the durable layer around your agent stack.

The Reddit user is right about the opportunity and cautious about the proof. That is the correct posture.

No, a Fable-written skill will not make Opus 4.8 secretly become Fable 5.

Yes, Fable 5 can probably write better operating instructions than Opus 4.8 for certain workflows, especially if it has just completed the work and can extract the pattern while the evidence is fresh. Anthropic's own documentation supports both halves of this: concrete behavioral instructions measurably change agent behavior, and Fable 5 is specifically better at the planning, verification, and delegation behaviors those instructions encode.

And yes, doing this before July 7 is exactly the kind of practical arbitrage builders should care about. The included allowance is 50% of your weekly limit, the clock is public, and the post-window rate is double Opus.

The model will get taken away, priced differently, rate-limited, routed through classifiers, or replaced by something else. Fable 5 has already been all five of those things in a single month. That is the platform reality.

Your workflow can survive that if the useful parts are written down.

So if you have Fable 5 today, do not waste the whole window asking it to make spaceship dashboards and slightly shinier todo apps.

Make it write the skills your future agents will need.

That is less flashy.

It is also the thing you will still have next week.

Sources researched