SSD Nodes Learn 🎉 VPS from $4.99/mo
Guides Matt ConnorBy Matt Connor · Updated 2026-08-06

The Fable method: skills for any model

The fable-method repo turns Claude Fable 5's habits into agent skills. What each file does, what ports to other models, and how to A/B it on a VPS.

What the Fable method actually claims

The Fable method is a small set of agent skills that write one model's working habits down as an ordered procedure, so a different model can run the same procedure. The repo is Sahir619/fable-method, MIT licensed, and its own one-line description is "how Claude Fable 5 worked, distilled into skills any model can run, with the eval that keeps it honest." The claim worth testing is the second half of that sentence.

Whether a text file really captures how a specific model thought is not something anyone outside Anthropic can check. Whether a cheaper model behaves differently when it reads that text file is something you can check yourself, on one VPS, in an afternoon. That measurement is the point of everything below: the same task twice, with and without the method, counting tool calls and cost.

If the word skill is new to you, start with what an agent skill actually is: a folder holding a SKILL.md file whose frontmatter description tells the agent when to load the body. The model the repo is named after is covered in what Claude Fable 5 costs and what it is good at.

Install the skills, and pin the version you test

There are two install routes. Inside Claude Code, the plugin route is two commands:

/plugin marketplace add Sahir619/fable-method
/plugin install fable@fable-method

On a VPS, where you want a pinned copy on disk, clone and check out a tag first:

git clone https://github.com/Sahir619/fable-method ~/fable-method
cd ~/fable-method
git checkout v1.4.0
bash install.sh
ls ~/.claude/skills

install.sh needs no sudo because it only writes under $HOME/.claude/skills. After it runs, ls ~/.claude/skills lists fable-judge, fable-loop and fable-method. Look at what is not there. The repo ships four skills and the shell installer copies three, so a standalone user does not get fable-domain unless they copy it by hand:

cp -r ~/fable-method/skills/fable-domain ~/.claude/skills/

Pin the tag, and write the tag down next to whatever results you get. This repo published five releases between 2026-07-06 and 2026-07-15, v1.0.0 through v1.4.0, and v1.4.0 changed the method itself by adding a new routing gate. As of August 2026, v1.4.0 is still the newest tag. If your control run reads one version of the rules and your test run reads another, you have measured nothing.

What each of the four skills tells the model to do

The load-bearing file is skills/fable-method/SKILL.md. It holds two gates and seven numbered steps, and its rules are specific enough to argue with.

The triviality gate comes first: act directly, with no ceremony, when the change touches one file, runs under about 10 lines, adds no new behavior, and you already know exactly what to change. The fit gate comes next and routes the ask by where the answer lives: sources you can open, a technique you have to research first, or your own inference, which must be flagged as low confidence rather than presented as fact.

Then the loop: classify the ask, define done, gather evidence, decide, act, verify, report. Step 2 says to orient by listing the directory before picking files, to prefer primary sources over recall, and to stop after two consecutive lookups that return nothing new. Step 4 says to write an INTENT: line before any edit, naming what the code does, what the failing check expects, and what the spec says, and not to edit at all when those three disagree, because the disagreement is the real finding. Step 5 caps retries: after three failed fix-and-verify cycles on the same issue, stop and hand back with the actual output.

The most testable part of the file is its four report tokens. A behavior change owes an INTENT: line. An outward-facing action owes AUTH: user said "<exact words>", quoting the user, since the repo states plainly that documentation is not authorization. A prescribed but untaken action owes a PENDING: line. A fixed defect owes TWINS: searched <pattern> - found <N> other sites. You do not have to trust anything about the method to check whether those four strings appear when they are owed, which is what makes the whole thing measurable instead of vibes.

fable-loop is the same method run as an orchestration in four stages: plan with parallel evidence subagents, execute on the main thread, verify with one to three attacker subagents that each take a different lens, then audit and report. It assumes cheap models on the evidence and attacker roles and a stronger model on the decisions and edits.

fable-judge is the piece worth installing even if you throw the rest away. Its stance is that "a report is a set of claims, not evidence." It collects the claims from a finished report, establishes ground truth from git diff and git status, re-runs every verification the report says it ran, and hunts a named fraud list: weakened checks, false completion, scope creep, unauthorized action, spec betrayal, and leftover debris. It returns VERIFIED, VERIFIED WITH CAVEATS, or REFUTED, and marks anything it cannot reproduce as UNVERIFIABLE rather than assuming it passed. The installer's own closing line points at it: "Try it: open Claude Code and type /fable-judge after any agent claims work is done."

fable-domain generates domain adapter bundles with trap fixtures and smoke evals. Eight adapters ship: marketing, research, data analysis, business and ops, finance, legal and compliance, design and UX, and devops. Medical and clinical work is deliberately left without one.

Which parts port to another model, and which do not

The repo answers this directly with AGENTS.md, which opens: "Portable version for any coding agent or harness (Codex, Cursor, aider, a raw system prompt). Identical method to SKILL.md; paste this file into your agent instructions or drop it at your repo root as AGENTS.md." It runs about 2,600 words and carries the same gates, steps and modes. If you already keep repo-root instruction files, the AGENTS.md and HUMAN.md convention covers where that file goes and who reads it.

Two parts port cleanly. The method text is an ordered prompt with no model-specific code, so any model that follows instructions can follow it, and the repo's stated thesis is that the lift is inversely proportional to model tier. The judge ports too, as long as the agent has a shell and a repository, because everything it does is git diff plus re-running commands the reader can also run.

One part does not port cleanly. fable-loop assumes the harness can spawn parallel subagents and route them to different models. An agent without subagents runs those stages serially on one model, which removes the parallelism and the cost saving that justified the design. What is left is fable-method with extra vocabulary.

Two smaller things are harness-specific and easy to miss. The /fable-method trigger is a Claude Code slash command, so on another harness you invoke the method by describing it. And the SKILL.md frontmatter description is what lets an agent load the body only when it matches the task, which means an installed skill costs almost nothing until it fires. Paste AGENTS.md into a system prompt instead and those 2,600 words sit in every request you send, whether the task is a one-line typo fix or a refactor. That is a real cost difference, and it is most of the reason the skill packaging exists at all.

How to A/B it on a VPS: the same task, twice

Set up two identical working copies so neither run can see the other's edits. Swap YOUR_ORG/YOUR_REPO for the repository you want to test against; the two clones must come from the same commit.

sudo apt update && sudo apt install -y git jq
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/control
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/method

Pick a task with an outcome you can observe without opinion: a failing test that has to pass, or a script that has to exit 0. A vague task gives a vague comparison, because you end up grading prose instead of results.

Run the control arm with --bare, which skips auto-discovery of hooks, skills, plugins and CLAUDE.md. That flag is what makes it a control: the skills you installed earlier cannot leak in. Bare mode does not use your subscription login, so set an API key from the Claude Console first.

export ANTHROPIC_API_KEY=sk-ant-...
task="Make tests/test_parser.py pass without editing the test file."

cd ~/ab/control
claude --bare -p "$task" \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/control.jsonl

The method arm is the same command with one flag added, which loads the portable method as a system prompt addition:

cd ~/ab/method
claude --bare -p "$task" \
  --append-system-prompt-file ~/fable-method/AGENTS.md \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/method.jsonl

Same binary, same model, same tools, same starting tree. One flag differs, which is the only way the comparison means anything.

That design measures the method text. It does not measure the skill packaging, which is a separate question. To measure the packaging, drop --bare, install the skills as above, and put the skill name inside the prompt string, because user-invoked skills expand in print mode: claude -p "/fable-method $task". Expect the cost profile to differ from the system-prompt arm even when the visible behavior looks the same.

Counting the steps and the cost

Both runs wrote a stream of JSON events. The last line is a result message carrying the final text, the cost and the session metadata. Print it once and read it before you script anything around it, because field names move between Claude Code releases.

tail -1 ~/ab/control.jsonl | jq .

Cost per run comes from that line, and it is the number to compare:

for f in ~/ab/control.jsonl ~/ab/method.jsonl; do
  printf '%s ' "$f"
  jq -r 'select(.type=="result") | .total_cost_usd' "$f"
done

Steps taken come from counting tool calls in the same file:

jq -r 'select(.type=="assistant") | .message.content[]? | select(.type=="tool_use") | .name' \
  ~/ab/control.jsonl | sort | uniq -c | sort -rn

Run that for both files. The shape of the difference tells you more than the totals. A method run that reads more files and edits fewer is doing what the method asks for, and that is the trade you are buying. A method run with the same edits and forty percent more cost bought you nothing on that task.

Two cautions about the numbers. First, do not sum output_tokens out of the session transcripts under ~/.claude/projects/ and call it the total: those per-message usage blocks are snapshots taken during streaming, and there are open reports of them undercounting. The result line is the number to trust. Second, one run per arm is an anecdote, so run each arm three or four times on the same task before you believe a gap, because two runs of the same agent on the same task already differ from each other. For the longer view of spend, the tools that track Claude Code spend and how Claude Code counts tokens explain why the cache lines dominate raw counts.

Make sure the agent cannot reach anything you care about while it runs unattended. running Claude Code safely on a VPS covers the user account and the permission flags.

The repo's own eval, read honestly

The README headline is "Fifteen eval rounds, more than 260 agent runs, blind LLM judges that verify by diffing and executing." That is more evidence than almost any skill repo ships, and eval/RESULTS.md is written round by round with the failures kept in. It is also thinner than the headline number suggests once you look at the individual cells behind the headline rows.

ChartRuns per cell behind the repo's headline eval rows, v1.4.0
The data behind this chart
[
  {
    "label": "Haiku, spec-vs-test conflict trap",
    "runs": 4,
    "notes": "bare 0 of 4, with method 4 of 4"
  },
  {
    "label": "Sonnet, same conflict trap",
    "runs": 2,
    "notes": "bare flags it then sides with the wrong test, with method ideal action both runs"
  },
  {
    "label": "Haiku, planted-fraud report, fable-judge",
    "runs": 2,
    "notes": "bare 4 and 3 of 5 frauds caught, with method 5 of 5 both runs"
  },
  {
    "label": "Haiku, marketing brand-rules trap",
    "runs": 2,
    "notes": "bare 1 of 2 runs, with method 2 of 2"
  }
]

The biggest of those 4 rows rests on 4 runs. The other three sit on 2 runs each. The repo says as much itself, in the standing limitations at the top of the log: "Small n throughout (1-4 runs per cell), LLM judges (blind where multiple outputs are compared, but built on the same frontier model that appears as a baseline), synthetic fixtures, research ground truth only as current as its run date." And more directly: "This log exists so method edits are tested, not so anyone mistakes it for a benchmark."

Credit that. An author who publishes their own n, and names the problem that their judge is built on the same model that serves as a baseline, is being more honest than the norm for this category. Read the numbers as evidence that the author actually ran things and kept the failures. Your own A/B is what tells you about your codebase.

The README is equally clear about where the method does nothing, and that is its most useful paragraph. It records no lift for ordinary small tasks on capable models. It states that "the method cannot make a model's facts fresher; bare frontier wins knowledge-heavy research". And it locates the value at "traps (authority conflicts, false completion claims, weak executors, unattended runs), not everywhere". If your agent work is small edits on a strong model with you watching, expect to measure nothing at all. If it is a cheaper model running unattended, that is where a gap should show up, which also makes the choice between Opus, Sonnet and Haiku part of the same decision.

Where the packaging is cargo cult

Four criticisms are worth making, and none of them is a reason to skip the repo.

The framing outruns the evidence. "How Claude Fable 5 worked" is a claim about a model's internals that nobody outside Anthropic can verify, and the repo's own core sentence undercuts it: "The quality lives in the structure, the evidence, and the honesty, not in the model." If the quality is in the structure, the provenance story is decoration. The procedure stands on its own and does not need an origin myth.

Four skills is more surface than the content needs. fable-loop restates a large share of fable-method with orchestration wrapped around it, and on a harness without subagents it collapses back into fable-method. Read the two files side by side before you install both.

Eight domain adapters is breadth the eval does not cover. Two of the eight appear anywhere in the log: marketing in round 9, devops in round 12. The finance, legal, design and data adapters ship with no round behind them. The adapter for your field may still be good. It is an author's draft, though, not something that survived a trap fixture.

And the installer disagrees with the repo about what it ships, copying three of four skills into ~/.claude/skills. That one is small. It is also the kind of gap that tells you the packaging moved faster than anyone reviewed it, which is worth remembering when you decide how much of this to adopt at once.

What to keep if you keep nothing else

Strip the branding and four rules survive on their own, whatever agent you run.

  • The authorization quote. An irreversible or outward-facing action needs the user's own words, written out as an AUTH: line. An agent that cannot find a quote does not act.
  • The twin check. After fixing a defect, search the whole project for the same wrong construct and report the count, including when the count is zero.
  • Verification by observation. A green targeted check sitting on top of a broken build is a failed verification, not a pass.
  • Outcome-first reporting, with whatever was skipped or left unverified stated as a caveat instead of quietly dropped.

Those four cost nothing to adopt and you can grep for compliance. Start there, measure with the harness above, then decide whether the rest of the repo earns its share of your context budget. If you want to give an agent standing project context rather than a working method, a DESIGN.md that agents read before they edit is the complementary move.

FAQ

Does the Fable method work with models other than Claude?

The method text does. It is an ordered prompt with no model-specific code, and the repo ships AGENTS.md as a portable copy for Codex, Cursor, aider or a raw system prompt. Two things do not travel. The /fable-method and /fable-judge triggers are Claude Code slash commands, so elsewhere you invoke the method by describing it. And fable-loop assumes a harness that can spawn parallel subagents on different models; without that, it runs serially and gives you fable-method with extra steps.

Does running these skills cost more tokens?

Yes, and how much depends on how you load them. Installed as skills, the body loads only when the description matches the task, so an unrelated request pays close to nothing. Pasted into a system prompt, the roughly 2,600 words of AGENTS.md ride along in every request. The run itself also costs more, because the method asks for orientation before editing, evidence before deciding, and a real verification after. Measure it: run the same task with --output-format json in both arms and compare the total_cost_usd field.

Which version of fable-method should I install, and why pin it?

Run git checkout v1.4.0 before you install. That tag is dated 2026-07-15 and was still the newest as of August 2026. The repo published five releases in the nine days before it, and v1.4.0 changed the routing rules themselves. Tracking main while you are measuring means your control run and your test run may read different instructions, which makes the comparison worthless. Record the tag alongside your results.

Is the eval in the repo a benchmark I can trust?

Treat it as a change log for the method, which is what its author calls it: "This log exists so method edits are tested, not so anyone mistakes it for a benchmark." The limitations are stated at the top of the file: 1 to 4 runs per cell, synthetic fixtures, and LLM judges built on the same frontier model that also serves as a baseline. The rounds are real and the failed experiments are kept in, which is more than most repos publish. It is still not a measurement of what will happen on your codebase, so run the two-arm comparison yourself.