Prompting Claude Fable 5 — Behavioral Patterns and Scaffolding Guide

Source: raw/prompting-claude-fable-5.md — Anthropic platform docs, fetched 2026-06-12.

Official Anthropic guide covering the behavioral differences and scaffolding patterns specific to Claude Fable 5 and Claude Mythos 5. Fable 5 handles tasks that were previously too complex, long-running, or ambiguous for prior models, and the teams seeing the best outcomes apply it to their hardest unsolved problems — testing only on simple workloads undersells its range.

Key Takeaways

• Longer turns are expected. Hard tasks at higher effort settings can run for minutes or hours; adjust client timeouts and harness architecture before migrating.
• high effort is the new default. xhigh for capability-critical work; medium/low for routine tasks. Lower Fable 5 effort still beats xhigh Opus 4.8 on most tasks.
• Brief instructions now steer whole behaviors. A single brevity instruction replaces an enumerated list of patterns; same for checkpoint and progress-grounding behaviors.
• Safety classifiers gate cybersecurity and life sciences. Requests in those domains return stop_reason: "refusal" and should be routed to Opus 4.8 fallback.
• Existing skills may be too prescriptive. Prompts designed for prior models can actively degrade Fable 5 output; review and trim.
• Don’t ask the model to echo its reasoning. Show-your-thinking instructions trigger the reasoning_extraction refusal category. Use thinking blocks via the API instead.
• Fable 5 reportedly pushes back and holds its ground under challenge, unlike Opus 4.8 and GPT-5.5, which tend to cave immediately — a single practitioner’s field report, but a meaningful edge for strategic-thinking and iteration work if it holds up. See Field Reports below.
• Community workflows now lean on Fable-spawned Opus subagents and HANDOFF.md handoff files to save token budget and preserve continuity across human-in-the-loop pauses.
• Fable 5 can design the goal harness itself, not just a plan. Ask it to build the scaffolding a cheaper execution model will run inside, rather than only a plan for a human or another model to read — and keep prompts short with rich context so the model keeps the freedom to find its own solution path.
• A nine-move “front-load the information” framework (blindspot pass, options-first, throwaway drafts, interview-me, show-don’t-explain, decisions-first plans, a running notes file, quiz-me-before-approving, teach-me-first) reframes most Fable mistakes as a missing-information problem you can fix before the mistake happens. See Field Reports below.
• A 7-mistake first-week checklist (treating Fable as a chatbot, vague /goal scoping, unwatched /loop cycles, cramming everything into CLAUDE.md instead of Skills, ignoring the safety-classifier fallback, no /goal failure path, skipping the memory file) complements the nine-move framework above — each mistake maps to a deeper existing pattern elsewhere in this wiki. See Field Reports below.

Behavioral changes requiring prompt updates

Longer turns by default

Individual requests on hard tasks can run many minutes; autonomous runs can extend hours. Restructure harnesses to check results asynchronously (scheduled jobs) rather than blocking. Add this to prevent over-planning on ambiguous tasks:

When you have enough information to act, act. Do not re-derive facts already
established in the conversation, re-litigate a decision the user has already made, or
narrate options you will not pursue in user-facing messages. If you are weighing a
choice, give a recommendation, not an exhaustive survey.

Effort level selection

Setting	Use when
low / medium	Routine tasks, fast interactive turns
high	Default — most tasks
xhigh	Capability-critical workloads

To prevent unrequested refactoring or gold-plating at higher effort:

Don't add features, refactor, or introduce abstractions beyond what the task requires.
A bug fix doesn't need surrounding cleanup. Do the simplest thing that works well.
Trust internal code and framework guarantees. Only validate at system boundaries.

A single-practitioner data point on the low end of this table: one Reddit poster’s tip #0 for a token-conscious workflow was simply “high effort is really enough” — consistent with high as the recommended default above, not a call to abandon xhigh for genuinely capability-critical work. [Reddit signal — r/ClaudeAI 2026-07-02] Source: raw/reddit-1uli8as.md.

Never ask Fable to explain its reasoning

A standing “explain your reasoning” or “show your work” instruction — especially one baked into a system prompt, skill, or CLAUDE.md file that persists across many turns — can itself trigger Fable 5’s reasoning_extraction refusal category and silently fall back to Opus 4.8. This is a distinct, narrower pitfall from the topic-based safety gating described above (cybersecurity, life sciences): it fires on the prompting pattern itself — asking the model to expose its private reasoning — regardless of how benign the surrounding task is.

[Video walkthrough, 2026-07-02] Source: raw/How_Anthropic_Engineers_Actually_Prompt_Fable_5.md — a YouTube creator’s paraphrase of Anthropic’s official “Prompting Claude Fable 5” docs, not the docs themselves. It attributes the mechanism to Fable 5’s jailbreak/extraction safeguards (Fable 5 sits a tier below Mythos 5, so its classifiers are tuned cautious about requests resembling an attempt to extract the model’s raw private reasoning) and describes the fallback as silent on consumer surfaces (claude.ai, Claude Code) — the request is quietly answered by Opus 4.8 instead, with no distinct in-product notice, versus a visible signal when building on the raw API. Treat the notice-behavior claim as secondhand pending a primary-source check.

What to do instead: if you need visibility into reasoning, use thinking blocks via the API rather than a prompted instruction. Never bake a standing “explain your reasoning” line into a skill, system prompt, or CLAUDE.md — audit existing ones for it (see checklist below).

Independent corroboration (2026-07-09). A separate r/Anthropic field report on post-relaunch prompting (see Field Reports below) hits the same trigger from the opposite direction: removing “explain your reasoning” / “think step-by-step” phrasing was one of five reframing techniques a practitioner used to stop legitimate security-audit prompts from being blocked and silently rerouted.

This is a specific case of a more general technique the same source calls negative prompting — stating explicitly what not to do, the way you’d brief an intern who doesn’t yet know your unwritten rules. It isn’t Fable-specific (the source frames it as working on any model), but Anthropic’s own Fable 5 docs lean on this pattern repeatedly — note how many of the instruction blocks throughout this article (“Don’t add features…”, “Don’t re-derive facts already established…”) are already negative-prompt-shaped.

Strong instruction following

Fable 5’s improved instruction-following means a single short directive replaces a long enumeration. To control verbosity and output structure:

Lead with the outcome. Your first sentence after finishing should answer "what happened"
or "what did you find." Supporting detail and reasoning come after. Readability matters
more than brevity. Keep output short by being selective about what you include, not by
compressing into fragments or arrow chains.

To define when checkpoint pauses are appropriate:

Pause for the user only when the work genuinely requires them: a destructive or
irreversible action, a real scope change, or input that only they can provide.

Grounding progress claims

On long autonomous runs, this instruction nearly eliminated fabricated status reports in Anthropic’s internal testing:

Before reporting progress, audit each claim against a tool result from this session.
Only report work you can point to evidence for. Report outcomes faithfully: if tests
fail, say so with the output; if a step was skipped, say that.

Stating the boundaries

Fable 5 occasionally takes unrequested actions (drafting emails, creating backup branches). Define explicit scope constraints:

When the user is describing a problem or thinking out loud, the deliverable is your
assessment. Report your findings and stop. Don't apply a fix until they ask for one.
Before running a command that changes system state, check that the evidence supports
that specific action.

Early-stopping edge cases

Deep in a long session, Fable 5 can occasionally end a turn with a statement of intent without executing it. For fully autonomous pipelines, add this system reminder:

You are operating autonomously. The user is not watching in real time. For reversible
actions that follow from the original request, proceed without asking. Before ending
your turn, check your last paragraph. If it is a plan, an analysis, or a promise about
work you have not done ("I'll…"), do that work now with tool calls.

Context-budget concern

Avoid surfacing explicit remaining-token counts to the model. If your harness must show them:

You have ample context remaining. Do not stop, summarize, or suggest a new session on
account of context limits. Continue the work.

Prompting patterns for better output

Give the reason, not only the request

Fable 5 uses intent context to pull in relevant information rather than inferring it. Especially useful for long-running agents:

I'm working on [the larger task] for [who it's for]. They need [what the output
enables]. With that in mind: [request].

Readability in agentic conversations

After many tool calls, Fable 5 can produce dense shorthand with references to thinking the user never saw. Add a communication-style instruction:

Terse shorthand is fine between tool calls. Your final summary is for a reader who
didn't see any of that. Open with the outcome: one sentence on what happened or what
you found. Write complete sentences. Spell out terms. Don't use arrow chains or labels
you made up while working. If you have to choose between short and clear, choose clear.

Memory system

Fable 5 performs particularly well when it can record and reference lessons from previous runs. Provide a writable Markdown file and add:

Store one lesson per file with a one-line summary at the top. Record corrections and
confirmed approaches alike, including why they mattered. Don't save what the repo or
chat history already records; update an existing note rather than creating a duplicate;
delete notes that turn out to be wrong.

Bootstrap from prior sessions with:

Reflect on the previous sessions we've had together. Use subagents to identify core
themes and lessons, and store them in [X]. Make sure you know to reference [X] for
future use.

Parallel subagents

Fable 5 dispatches parallel subagents more readily than prior models. Prefer async orchestrator-to-subagent communication over blocking. Long-lived subagents save cost through cache reads and avoid bottlenecking on the slowest one.

Delegate independent subtasks to subagents and keep working while they run.
Intervene if a subagent goes off track or is missing relevant context.

Community extension: let Fable spawn its own Opus subagents. [Reddit signal — r/ClaudeAI 2026-07-02] Source: raw/reddit-1uli8as.md (u/Ok_Significance_9109, score 230). Rather than opening a second, separate Opus session yourself, ask Fable to classify a multi-step plan’s tasks by whether Opus can execute them alone or needs Fable’s supervision, then have Fable spin up the Opus subagent itself and instruct it to perform only the tasks it can fully evaluate and understand (see Claude Code Subagents for the underlying mechanism). Running the delegation from inside Fable’s own context — instead of the user bridging context into a fresh Opus session — saves Fable’s token budget, since Fable doesn’t have to re-explain the task from scratch in a parallel conversation. One practitioner reports the reverse check paid off too: the Opus subagent caught a mistake Fable had made, which Fable then acknowledged.

Classify each task in the plan as Fable-only or Opus-suitable. For Opus-suitable
tasks, spin up an Opus subagent yourself and give it only the tasks it can fully
evaluate and understand on its own. Report back what each subagent did and flag
anything it got wrong.

Handoff files for human-in-the-loop pauses

[Reddit signal — r/ClaudeAI 2026-07-02] Source: raw/reddit-1uli8as.md (u/Ok_Significance_9109, score 230). Distinct from the memory pattern above — which accumulates learned patterns across sessions — this pattern hands off a single in-progress task across a pause. Whenever Fable needs human interaction (a decision only you can make, an approval, information it can’t get on its own), ask it to generate a HANDOFF.md file summarizing where things stand — for itself, or for when a delegated Opus subagent returns and needs to report back. When you come back to the computer, clear the context and start a fresh session seeded from the handoff file instead of re-reading a long conversation history. The poster reports this saves hundreds of thousands of uncached tokens versus resuming inside the original long-running session. Related session-continuity patterns already in the wiki: Matt Pocock’s Skills Repo’s handoff skill, and this vault’s own hot.md cache described in Karpathy’s LLM-Wiki Techniques for Claude Code.

Before you stop and wait for me, write HANDOFF.md: what you were doing, what you've
confirmed, what's still open, and the single next action. If a subagent hands work
back to you, do the same before you report to me.

Field Reports: Practitioner Workflows and Model Comparisons

The sections above are grounded in Anthropic’s own documentation. What follows comes from community and creator reporting during Fable 5’s July 2026 return window — useful signal, but single-source and anecdotal rather than official guidance, in the same spirit as the bracketed Reddit signals in Troubleshooting Claude. Worth testing against your own workflow, not worth treating as settled.

Post-mortem, then classify, then delegate

[Reddit signal — r/ClaudeAI 2026-07-02] Source: raw/reddit-1uli8as.md (u/Ok_Significance_9109, score 230, 48 comments; top comments largely agreed with minor variations, no major dissent). A three-step workflow for getting the most out of a limited Fable budget:

1. Point Fable at your most challenging existing code and ask for a detailed post-mortem.
2. Have it turn the post-mortem into implementation plans, one per related block of issues, ordered by proper implementation sequence.
3. Have it classify each block by whether Opus can execute it alone or needs Fable’s direct supervision, then delegate accordingly using the Opus-subagent pattern above.

Plan with Fable, build elsewhere

[Podcast summary — The AI Daily Brief, 2026-07-01] Source: raw/Fable_Is_Back_-_Here_s_What_You_Should_Try_First.md. The host relayed four tips from creator Any Panuani for using a limited Fable 5 access window without “going bankrupt”:

1. Use Fable 5 for planning, not implementation — delegate implementation to a faster, cheaper model (Any Panuani’s example: GPT-5.5 via a Codex plugin inside Claude Code).
2. Ask Fable for improvement suggestions on your projects, starting with the most important ones.
3. Use Opus and GPT-5.5 to brainstorm what your hardest technical problems actually are, then bring those problems to Fable for solutions — an inversion that spends cheaper models on problem-finding and saves Fable for problem-solving.
4. Use an independent, powerful reviewer (Any Panuani’s example: GPT Pro via “Oracle”) to review Fable’s output — an external check that complements the progress-grounding instruction above rather than replacing it.

The host’s own take, after testing: they agree with the “hardest technical problems” half of this advice, but disagree that Fable is only noticeably better on hard technical work — see below.

Where Fable outperforms the benchmarks: strategic pushback and writing

[Podcast field report — The AI Daily Brief, 2026-07-01] Source: raw/Fable_Is_Back_-_Here_s_What_You_Should_Try_First.md. Two findings from the host’s own real-world use, offered with different confidence levels in the source itself:

• Strategic pushback. In the host’s experience, Opus 4.8 and GPT-5.5 are both “overly deferential to pushback”: ask either for a strategic opinion while instructing it not to be sycophantic, and it treats that as license to manufacture disagreement — then push back for real, and it caves almost immediately, rewriting to match whatever it infers you want to hear. Fable 5 reportedly did neither: debating with it, the host found it would accept part of a challenge while holding its ground on other parts, which they say made Fable “a thousand times more valuable” for strategic thinking and iteration specifically. A single practitioner’s limited-sample account, not a controlled test — but concrete and falsifiable enough to test against your own strategy sessions. It’s a useful complement to Troubleshooting Claude’s Sycophancy section, which documents sycophancy as consistent across frontier models generally per Anthropic’s own research; this source claims Fable 5 specifically breaks that pattern.
• Real-world writing quality (more tentative). Every’s benchmark testing — cited secondhand in this source, not independently verified here — scored Fable 5’s writing as “clear, but still short of human judgment,” landing between Sonnet 4.6 and Opus 4.8 at xhigh effort. The host’s own non-benchmark, real-world writing use disagreed: better instruction-following and fewer AI-isms than the benchmark suggested, particularly on tasks with a clear rubric or worked examples to match rather than blank-page writing. The host explicitly frames this as tentative and low-rep, not a settled conclusion.

Conserving a metered Fable window: three creator techniques

[YouTube field reports, 2026-07-02/03] Sources: raw/Claude_Fable_5_Is_Finally_Back_-_5_Must-Try_Use_Cases_Before_July_7.md, raw/Claude_Fable_5_Use_Cases_You_MUST_Try_Now_or_lose_next_week.md. Two creators surfaced reusable patterns for the metered July return window (Fable on subscription only through July 7, then usage credits). Single-source and creator-tested — worth trying against your own workflow, not settled guidance:

• Ask Fable to find its own Fable-worthy work. Instead of guessing what deserves the expensive model, point it at your memory and projects and let it nominate: “You are Fable 5, the most capable model available. Look through my projects and memory and list the top five tasks that require deep thinking that are worth running by you.” The returned list skews toward large-corpus analysis and multi-source planning — where a frontier model earns its token cost — and doubles as a triage step before you spend limits.
• Loop on hard-to-verify aesthetic work with a “100 → 120 index” score. For visual / 3D / design output that can’t be unit-tested, pair Claude Code’s /loop with an explicit self-scoring rubric: treat the current iteration as index 100 and require each pass to reach 120 or better before stopping (≈20% better each round). This supplies a verifier where none exists naturally (see Verifier-First Loops) and visibly compounds polish — the gap between a rough first-pass 3D world and the shared, explorable one in the source demo.
• Default to high effort and babysit to avoid rat-holes. Reinforcing the token-economy note above: the 5-use-case creator sticks to high rather than xhigh / Ultra (“your limits are going to run out super fast”), and warns that Fable can occasionally loop on burning tokens — watch it and interrupt rather than letting it run unattended on a metered plan.

Three tactics for a free-token weekend (or any metered window)

[YouTube field report, 2026-07-04/05] Source: raw/Free_Fable_5_tokens_this_weekend_Here_s_how_to_max_them.md. Nate B Jones’s tips for a Fourth-of-July free-token promotional weekend generalize to any metered or budget-conscious Fable 5 window — he frames them as worth using deliberately even without free tokens in play:

1. Go a step beyond “plan with Fable, build elsewhere” — have Fable design the goal harness itself. The community consensus by this point is to use Fable 5 for planning and a cheaper model for implementation (see “Plan with Fable, build elsewhere” above). This source pushes one step further: ask Fable 5 to design a detailed goal — and a full goal harness — for a complicated coding task, then hand that harness to a cheaper execution model (the source’s example: a Codex-based model, “or whatever model I choose”) to actually build it. Fable designs the scaffolding the cheap model runs inside, rather than only a plan the cheap model reads.
2. Pair Fable 5’s front-end design strength with an external tool that can show it off. The source calls Fable 5 “extremely good” at front-end design, but says the best results come from practitioners who wire in external tools that let that strength show through — its example is driving Blender for animation and video, where Blender’s output becomes the visible proof of Fable 5’s design decisions. General pattern: Fable 5’s own text/code output can understate a capability that only becomes visible once piped through a rendering or execution tool built for that medium.
3. Hunt for problems worth a “master’s-degree-at-hyperspeed” prompt, then keep the prompt itself short. Audit your own marketing or product surface for problems that “ping” as unusually hard — the kind that would normally require a subject-matter expert — then give Fable 5 a short prompt with rich, differentiated context and let it work the problem rather than prescribing a linear solution path. The source ties this explicitly to Anthropic’s own prompting guidance and to not over-constraining the model: over-specifying the solution forfeits the degrees of freedom that let a frontier model find a better answer than the one you’d have specified yourself. This echoes the “give the reason, not only the request” pattern above, applied to problem selection rather than phrasing.

Front-load information with a nine-move checklist

[X signal — @itsolelehmann, 2026-07-05] Source: raw/x-bookmarks-recent-digest-2026-07-05.md. Ole Lehmann’s practitioner framework for “working beautifully with Fable,” attributed in the post to an article by Thariq: most of what looks like Fable getting something wrong traces back to the prompt missing information the model needed — not a model failure. Nine moves front-load that information before the mistake happens instead of after:

1. Run a blindspot pass before starting anything new. “Do a blindspot pass. What are my unknown unknowns here? Teach me enough to prompt you better.” See the explore-unknowns skill below for a productized version of this move.
2. Ask for options before deciding what to build. “Here’s my rough problem. Give me 10 ways to solve it, from cheapest to most ambitious. I’ll tell you which ones I like.”
3. Ask for 3-4 rough throwaway drafts when you can’t describe the target but would recognize it — reacting to drafts beats describing from scratch.
4. Let Fable interview you one question at a time, starting with the questions whose answers would change the whole plan.
5. Show, don’t explain — point Fable at an existing doc, design, or piece of code and say “do it like this” instead of describing it from scratch.
6. Front-load the plan’s big decisions, with routine work at the bottom, so the choices worth changing surface first.
7. Keep a running decisions log while Fable works — anything the instructions didn’t cover gets written down as it’s decided, so nothing slips by silently.
8. Quiz yourself before accepting the work. “Summarize everything that changed, then quiz me on it. I don’t approve until I pass.” If you can’t pass the quiz, you don’t understand what you’re shipping.
9. Have Fable teach you first when you can’t judge good output from bad — the source’s example is asking for color-grading options, realizing you can’t evaluate them, and having Claude teach color grading before picking one.

A concrete tool for move #1. [X signal — @dzhng, 2026-07-05] Source: raw/x-bookmark-2073729706789343488.md. Developer David Zhang (@dzhng) fed a blindspot-pass article to Fable 5 and had it generate a reusable explore-unknowns Claude Skill: it scans the codebase, then interviews the user one question at a time to close the known unknowns, then separately sweeps for the unknown unknowns the user never thought to ask about. Published in his skills collection at github.com/dzhng/skills, described as now part of his personal “software factory.” Single-tweet source with no walkthrough of the skill’s actual prompt — check the repo directly before adopting.

Primary source located: the map/territory field guide (2026-07-06)

[Anthropic official blog, 2026-07-06] Source: ai-research/claude-blog-field-guide-fable-finding-your-unknowns.md — “A field guide to Claude Fable 5: Finding your unknowns,” claude.com/blog/a-field-guide-to-claude-fable-finding-your-unknowns, written by Thariq Shihipar, member of technical staff, Anthropic. This is very likely the primary source Ole Lehmann’s nine-move framework above was itself paraphrasing — his post attributed the framework to “an article by Thariq,” and the specific phrasing lines up closely (the literal “unknown unknowns” and “blind spot pass” terms, the quiz-before-merge pattern). This section upgrades that evidence tier: the nine-move list above is no longer just single-source/anecdotal community reporting — it corroborates, closely, an official Anthropic post. One curiosity worth flagging rather than resolving: the digest capturing Ole Lehmann’s post is dated 2026-07-05, one day before this official post’s confirmed 2026-07-06 date — plausibly early/preview access, a same-day conference-talk precursor (see below), or just a digest-capture-date quirk; not treated here as a factual contradiction.

Shihipar’s framing: prompting Claude is drawing a map (your prompts, skills, and context) of a territory (the actual codebase, the real world, its constraints). The gap between the two is what he calls unknowns — when Claude hits one, it fills the gap with its best guess at what you want. His claim: Fable 5 is the first model where the quality of the work is bottlenecked by his own ability to clarify its unknowns, rather than by the model’s capability — so surfacing missing information becomes the higher-leverage move than better phrasing.

He splits unknowns into four categories — a classic knowns/unknowns quadrant, applied specifically to prompting:

Category	What it means
Known knowns	What’s already in your prompt — what you’ve told Claude you want.
Known unknowns	What you haven’t figured out yet, but know you haven’t.
Unknown knowns	What’s so obvious you’d never write it down, but you’d recognize it on sight.
Unknown unknowns	What you haven’t considered at all — including whether you know what “good” looks like.

Reducing and planning for unknowns, in his account, is the core skill of agentic coding — and one you can practice specifically by working with Claude, since it can search a codebase and the literature far faster than a human and knows more about most topics, so it can help surface your own blind spots rather than just filling them silently.

His named patterns map onto (and, now primary-sourced, corroborate) Ole Lehmann’s nine moves above almost one-for-one:

• Blind Spot Pass (pre-implementation) — the same move as #1, same “unknown unknowns” phrasing.
• Brainstorms and prototypes (pre-implementation) — targets unknown-knowns territory (design taste, “I’ll know it when I see it”); maps to moves 2-3. Verbalizing criteria during prototyping is cheaper than discovering them mid-implementation, since a small spec change can force a drastically different implementation.
• Interviews (pre-implementation) — the same move as #4.
• References (pre-implementation) — the same move as #5; his specific claim is that source code is a richer reference than a screenshot, because it carries markup and structure a picture can’t.
• Implementation Plans (pre-implementation) — the same move as #6; the plan should foreground what’s likely to change (data models, type interfaces, UX flows) rather than routine work.
• Implementation notes (during implementation) — the same move as #7; a temporary implementation-notes.md the agent keeps mid-task, because unknown unknowns keep surfacing once code is underway no matter how much was planned upfront.
• Pitches and explainers (post-implementation) — genuinely new relative to the nine-move list: building a pitch or explainer artifact as part of shipping, aimed at getting buy-in from people who weren’t in the implementation loop.
• Quizzes (post-implementation) — the same move as #8; his own stated rule matches exactly: only merge after passing the quiz.
• Move #9 (“have Fable teach you first”) shows up in his worked example below rather than as its own named section.

Worked example: editing Fable’s own launch video. Shihipar illustrates the whole loop with a domain he wasn’t expert in — video editing, used to produce Fable 5’s own launch video, edited end-to-end in Claude Code. He asked Claude to explain how Whisper-style transcription works and whether ffmpeg could accurately cut pauses and filler words; prototyped a word-timed UI with Remotion before committing to the approach; and, hitting a wall on color grading (knowing the footage looked “muted” without knowing why, or what “good” grading even looks like), had Claude teach him color grading before choosing between variants — the same “have Fable teach you first” pattern as move #9, now with a named provenance and a concrete production case study.

Same-day companion talk: “Field Guide to Fable,” an AI Engineer conference talk by Shihipar, posted to YouTube the same date (2026-07-06) — not independently watched or transcribed for this ingest.

A portable, tool-agnostic memory-folder variant

[X article — @free_ai_guides, 2026-07-03] A separate practitioner setup guide packages the memory-file idea above into a small claude-context/ folder (a self-updating claude-memory.md alongside a separate claude-instructions.md standing-behavior file), explicitly designed to be portable to non-Claude tools (“Claude, Cursor, VS Code, and any future tool”). See Claude Code Memory Architectures Compared for the full comparison against Claude Code’s built-in Auto Memory and the memarch/Hermes hybrid this variant sits alongside. (Source: raw/x-article-free-ai-guides-2073050543027638443.md.)

Skills behave differently on Fable 5

[X article — @free_ai_guides, 2026-07-03] The same source claims Fable 5 treats a Skill differently from prior models: because Fable actively looks for ways to improve its own work, it “doesn’t just follow a skill — it pressure-tests the output against the skill’s criteria and self-corrects.” The author’s framing: on prior models a skill was a template; on Fable 5 a skill is closer to a quality standard the model checks its own work against. Consistent with this article’s self-checking framing and the system card’s self-verification material (see Claude Fable 5 + Mythos 5), but the specific “skill as quality standard” framing is this source’s own and not independently confirmed elsewhere.

For the mechanics of building a skill (SKILL.md format, progressive disclosure, testing, distribution), see The Complete Guide to Building Skills for Claude — unchanged by Fable 5. The same source adds three sourcing methods worth noting as a quick-start menu: build from a past conversation (ask Claude to extract your patterns from a chat where it did good work and generate a SKILL.md), from scratch via the built-in Skill Creator (interactive Q&A), or from reference material (feed Claude examples of work you like — reports, code, design specs — and have it extract the pattern into a skill, sharpening it via feedback over time).

Field report: 7 first-week mistakes (AI Guides, 2026-07-03)

[X article — @free_ai_guides, 2026-07-03] A single-author 3-week field test lists seven Fable-5-specific mistakes from the practitioner’s first week. Most map directly onto guidance already established elsewhere in this wiki — listed here condensed, with pointers rather than re-explanation:

1. Treating Fable like a chatbot (quick back-and-forth instead of autonomous /goal//loop work) — burns premium pricing on standard behavior. Fix: match the model to task complexity (see Cost & Intelligence Levers Lever 4).
2. Vague goals (“improve test coverage” ran 20 minutes and tested edge cases nobody cared about) — the core discipline already documented in Verifier-First Loops and the scaffolding checklist above.
3. Not watching the first /loop cycle (14 cycles run on a broken starting point, tokens wasted) — matches the “default to high effort and babysit to avoid rat-holes” guidance in the Field Reports above.
4. Everything crammed into CLAUDE.md (a 3,000-word file loaded in full every session) instead of Skills that load only when relevant — the same discipline documented in Context Management in Claude Code’s “Skills vs MCP for context” framing and Claude Code Memory Architectures Compared’s “keep CLAUDE.md under ~200 lines” rule.
5. Ignoring the safety classifiers and being confused by an Opus 4.8 response — already documented in Claude Fable 5 + Mythos 5’s safeguard model; that article’s 2026-07-06 addition adds this source’s practical billing detail (a rerouted response is not charged at Fable rates).
6. No failure path in /goal (a stuck test looped 40+ minutes) — the exact failure mode the verifier-first checklist and Should You Build a Loop?’s failure-mode catalog exist to prevent.
7. Skipping the memory file (re-explaining business context every session, ~5-10 minutes wasted each time) — the cost the Memory system section above and Fable 5 Memory Loop are built to eliminate.

Single-source and anecdotal, in the same spirit as the other Field Reports above — useful as a first-week checklist, not a new mechanism. (Source: raw/x-article-free-ai-guides-2073050543027638443.md.)

Reframing security-audit prompts around the post-relaunch safety classifier

[Reddit signal — r/Anthropic 2026-07-09] Source: raw/reddit-1us4ezz.md (u/MuddaFrakker, score 26 / 21 comments). Single-operator anecdote, but concrete and falsifiable — worth testing against your own security-adjacent prompts, not settled guidance. The poster reports Fable 5’s safety classifiers turned hyper-aggressive after Anthropic redeployed the model following the June 2026 US government pause: standard security audits now often trigger the filters and silently downgrade the task to Opus 4.8. This corroborates rather than adds to two claims already established elsewhere in this article — the safeguard-reroute-to-Opus-4.8 mechanism itself (see Safety classifiers in Key Takeaways above) and the no-Fable-price-charge-on-reroute billing detail (see the 7-mistakes field report above, sourced independently). What’s new here are five concrete reframing techniques for staying under the classifier’s threshold on legitimate security work:

1. Frame the ask as a compliance/structural check, not a vulnerability hunt. Terms like “vulnerability” or “exploit” reportedly get flagged fast. The poster’s working example: swap “Run a security audit to find vulnerabilities in the ledger API” for “Perform a structural integrity and compliance review on the ledger API to ensure strict adherence to double-entry routing rules.”
2. Don’t ask it to “list everything wrong.” An open-ended defect hunt reads to the classifier like blind zero-day scraping. Instead, give explicit pass/fail criteria and ask for a localized patch on failure — the poster’s example: replace “Find all bugs in the reconciliation engine” with “Review reconciliation.ts. Verify it passes: 1) every transaction ID matches an existing invoice, 2) the sum of credits equals debits before writing to the database. If it fails, provide a localized patch.”
3. Don’t ask for a categorized list of exploitable code snippets. The poster reports Fable 5 is specifically trained to refuse compiling that kind of list — it’s exactly the shape of output that helps build an attack script. Ask it to draft a patch or give a high-level summary of the logic failure instead; let it fix the problem rather than document the exploit.
4. Remove “explain your reasoning” / “think step-by-step” phrasing. Independent corroboration of the reasoning_extraction refusal mechanism already documented above: Fable 5 handles this natively now, and an explicit ask can itself trigger a refusal classifier.
5. Avoid long, rigid, prescriptive step-by-step instructions. Beyond the instruction-following efficiency argument made elsewhere in this article (see Strong instruction following above), the poster’s specific claim is that heavily prescriptive steps can read as suspicious to the safety classifier itself — a distinct failure mode from simply being a less-effective prompt.

Send-to-user tool (agentic UIs)

For long asynchronous agents, define a tool that delivers messages to the user verbatim without ending the turn. Tool inputs are never summarized, so content arrives intact:

{
  "name": "send_to_user",
  "description": "Display a message directly to the user. Use this for progress updates, partial results, or content the user must see exactly as written before the task finishes.",
  "input_schema": {
    "type": "object",
    "properties": {
      "message": { "type": "string", "description": "The content to display to the user." }
    },
    "required": ["message"]
  }
}

Defining the tool alone is insufficient — pair it with elicitation language:

Between tool calls, when you have content the user must read verbatim (a partial
deliverable, a direct answer to their question), call the send_to_user tool.
Use send_to_user only for user-facing content, not narration or reasoning.

Scaffolding migration checklist

• Adjust client timeouts and streaming for multi-minute turns
• Restructure blocking harnesses to async / scheduled-job check-ins
• Move effort to high as default; add xhigh selectively
• Add progress-grounding instruction to long-run system prompts
• Add boundary-stating instruction to prevent scope creep
• Add autonomous-pipeline instruction for non-interactive runs
• Review existing skills for over-prescription and trim
• Audit skills for show-your-reasoning / echo-thinking instructions — remove them
• Configure Opus 4.8 fallback for stop_reason: "refusal" responses
• Reframe security/audit prompts as compliance/structural-integrity language (not “vulnerability”/“exploit”) before running them through Fable 5
• Implement send_to_user tool for agentic UIs that need mid-run messages
• Provision a Markdown memory file for long-horizon agents
• Classify multi-step plan tasks as Fable-only vs. Opus-suitable before delegating; let Fable spawn its own Opus subagents for the latter
• Have Fable write a HANDOFF.md before any human-in-the-loop pause so a resumed session starts cheap

Related

• Claude Fable 5 + Mythos 5 — Launch Overview
• 4.6)
• OpenAI GPT-5 Prompting Guide — Cross-Vendor Reference
• Canva AI 2.0 Case Study (Fable 5 in production)
• Dynamic Workflows in Claude Code
• Claude Code Subagents
• Matt Pocock’s Skills Repo — Engineering + Productivity Skills
• Troubleshooting Claude — Common Failure Modes and Recovery Moves
• Cost & Intelligence Levers for Agent Workflows — the economics of when a Fable-5-shaped problem is worth the frontier price
• Mythos 5 Federal Shutdown (June 2026) — the export-control event and redeployment that the 2026-07-09 field report says preceded the hyper-aggressive classifier tuning
• Refusal Calibration and Constitutional AI — the mechanism-level counterpart to the reframing techniques above

Try It

1. Pick your hardest current task and give it to Fable 5 at xhigh effort — paste the full specification in one turn, not drip-fed.
2. Add the progress-grounding instruction to any autonomous pipeline system prompt.
3. Audit existing Claude Code skills for show-your-reasoning or echo-thinking lines and remove them.
4. Add a memory Markdown file (lessons.md) to any long-horizon agent and include the memory system instruction.
5. For agentic UIs: implement send_to_user and pair it with the elicitation language in the system prompt.
6. On your next multi-step plan, classify each task as Fable-only vs. Opus-suitable, then ask Fable to spin up the Opus subagent itself instead of starting a second session yourself.
7. Before stepping away mid-task, ask Fable to write a HANDOFF.md — resume from that file instead of the full conversation history next time.
8. On your next complicated coding task, ask Fable 5 to design the goal harness (not just a plan), then hand that harness to a cheaper execution model to build against.
9. Audit your marketing or product surface for one problem that “pings” as unusually hard — the kind that would normally need a specialist — and pose it to Fable 5 in a short, context-rich prompt rather than a prescribed step-by-step one.
10. When prompting Fable 5 for security-adjacent work, reframe it as a structural/compliance review with explicit pass/fail criteria rather than an open-ended vulnerability hunt — see the reframing field report above for the specific before/after phrasing.