---
name: prompting-claude-fable-5
description: Prompting and scaffolding patterns for Claude Fable 5 and Claude Mythos 5 (the generation after Opus 4.8). Use when writing prompts, system prompts, agent harnesses, or skills targeting Fable 5 / Mythos 5; when migrating prompts from Opus 4.8 or earlier; when a task mentions Fable 5, Mythos 5, "fable model", effort levels, adaptive thinking, long-horizon agents, or the refusal/fallback stop reason. Contains ready-to-paste instruction snippets and the anti-patterns that degrade Fable 5 output.
metadata:
  author: Socialure (The Founding Engineer)
  version: 1.0.0
  source: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5
  status: Ready for fleet review and release. Authored from official Fable 5 / Mythos 5 prompting documentation.
  created: 2026-06-27
---

# Prompting Claude Fable 5 (and Mythos 5)

Fable 5 / Mythos 5 are the generation **after Opus 4.8**. They are built for long-horizon, ambiguous, end-to-end work that takes a person hours-to-weeks. Best results come from pointing them at your *hardest unsolved* problems, not from testing only simple workloads (which undersell their range). They also handle routine tasks fine.

**The headline migration shift:** Fable 5 follows instructions well enough that you steer with a *brief* instruction instead of enumerating every behavior. Many prompts/skills written for older models are now **too prescriptive** and actively degrade output. When migrating, the move is usually to *delete* instructions, not add them.

---

## 1. Effort is the primary control

`effort` trades intelligence vs. latency vs. cost. Defaults:

| Effort | When |
|---|---|
| `xhigh` | most capability-sensitive workloads |
| `high` | **default for most tasks** |
| `medium` / `low` | routine work — still strong; often beats `xhigh` on *prior* models |

- Lower the effort if a task completes but takes longer than needed, or you want a snappier interactive feel.
- At higher effort Fable 5 gives excellent verification + rigorous output, but can over-gather context and over-tidy. Counter unrequested refactoring with the snippet in §3.

## 2. Longer turns by default — fix your harness FIRST

Single hard requests can run **many minutes**; autonomous runs can go **hours**. This is the #1 thing teams trip on. Before migrating:

- Raise client timeouts; enable streaming; add user-facing progress indicators.
- Restructure blocking harnesses to **check runs asynchronously** (scheduled jobs) rather than blocking until return.

Keep Fable 5 from overplanning on ambiguous tasks:

```text
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. This does not apply to thinking blocks.
```

## 3. Strong instruction following — steer briefly, don't enumerate

A short instruction replaces a long list. Ready-to-paste snippets:

**Prevent unrequested cleanup/refactor at higher effort:**
```text
Don't add features, refactor, or introduce abstractions beyond what the task requires. A bug fix doesn't need surrounding cleanup and a one-shot operation usually doesn't need a helper. Don't design for hypothetical future requirements: do the simplest thing that works well. Avoid premature abstraction and half-finished implementations. Don't add error handling, fallbacks, or validation for scenarios that cannot happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs). Don't use feature flags or backwards-compatibility shims when you can just change the code.
```

**Brevity / lead-with-outcome (replaces enumerating every verbosity pattern):**
```text
Lead with the outcome. Your first sentence after finishing should answer "what happened" or "what did you find": the thing the user would ask for if they said "just give me the TLDR." Supporting detail and reasoning come after. Being readable and being concise are different things, and readability matters more.

The way to keep output short is to be selective about what you include (drop details that don't change what the reader would do next), not to compress the writing into fragments, abbreviations, arrow chains like A → B → fails, or jargon.
```

**Checkpoint behavior (pause only when it matters):**
```text
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. If you hit one of these, ask and end the turn, rather than ending on a promise.
```

## 4. Ground progress claims during long runs

Long autonomous runs can fabricate status. This near-eliminated it in Anthropic's testing:

```text
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. Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that; when something is done and verified, state it plainly without hedging.
```

## 5. State the boundaries (it can over-act)

Fable 5 occasionally takes unrequested actions (drafting an email, creating defensive git-branch backups). Constrain explicitly:

```text
When the user is describing a problem, asking a question, or thinking out loud rather than requesting a change, 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 (restarts, deletes, config edits), check that the evidence actually supports that specific action. A signal that pattern-matches to a known failure may have a different cause.
```

## 6. Parallel subagents — lean in

Fable 5 dispatches parallel subagents more readily and reliably manages long-lived ones. Prefer **async** orchestrator↔subagent comms over blocking; long-lived subagents save cost via cache reads and avoid bottlenecking on the slowest one.

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

## 7. Give it a memory system

Fable 5 excels when it can record + reference lessons. A Markdown file is enough:

```text
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 history:
```text
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.
```

## 8. Give the reason, not only the request

It performs better when it knows *intent* — context lets it connect the task to relevant info instead of guessing:

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

## 9. Readability when talking to the user (agentic convos)

After many tool calls Fable 5 can emit dense arrow-chains, deep impl detail, or references to thinking the user never saw. Add a communication-style addendum:

```text
Terse shorthand is fine between tool calls (that's you thinking out loud, and brevity there is good). Your final summary is different: it's for a reader who didn't see any of that.

If you've been working for a while without the user watching (overnight, across many tool calls, since they last spoke), your final message is their first look at any of it. Write it as a re-grounding, not a continuation of your working thread: the outcome first, then the one or two things you need from them, each explained as if new. The vocabulary you built up while working is yours, not theirs; leave it behind unless you re-introduce it.

When you write the summary at the end, drop the working shorthand. Write complete sentences. Spell out terms. Don't use arrow chains, hyphen-stacked compounds, or labels you made up earlier. When you mention files, commits, flags, or other identifiers, give each one its own plain-language clause. Open with the outcome: one sentence on what happened or what you found. Then the supporting detail. If you have to choose between short and clear, choose clear.
```

## 10. send-to-user tool (long async agents)

For long async runs, give the agent a way to surface a message verbatim **without ending its turn** (deliverable, numeric progress, direct reply to a mid-loop question). Tool inputs are never summarized, so content arrives intact.

```json
{
  "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 is **not enough** — without a system-prompt instruction Fable 5 rarely calls it. Pair with:
```text
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 with that content. Use send_to_user only for user-facing content, not for narration or reasoning.
```
Do **not** route narration/internal reasoning through it — over-calling defeats the purpose.

## 11. Rare: early stopping

Deep in long sessions it may end a turn with intent-only text ("I'll now run X") and no tool call, or ask permission it doesn't need. "continue" / "go ahead end to end" fixes it. For autonomous pipelines, add:

```text
You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task, so asking "Want me to…?" or "Shall I…?" will block the work. For reversible actions that follow from the original request, proceed without asking. Offering follow-ups after the task is done is fine; asking permission after already discussing with the user before doing the work is not. Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or a promise about work you have not done ("I'll…", "let me know when…"), do that work now with tool calls. End your turn only when the task is complete or you are blocked on input only the user can provide.
```

## 12. Rare: context-budget anxiety

In very long sessions it may suggest a new session / offer to summarize / trim its work — usually triggered by a **remaining-token countdown shown to the model**. Avoid surfacing context-budget counts. If you must show them, reassure:

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

---

## Safety classifiers & refusals (READ before migrating)

Fable 5 runs classifiers targeting **offensive cybersecurity** (exploits, malware, attack tooling), **biology/life-sciences** (lab methods, molecular mechanisms), and **extraction of the model's summarized thinking**. Benign cyber/bio work may also trip them. Refused requests return `stop_reason: "refusal"`.

- Configure **server-side or client-side fallback to Claude Opus 4.8** to auto-reroute declined requests.
- ⚠️ **Do NOT instruct Fable 5 to reproduce / echo / transcribe / explain its internal reasoning as response text** — this can trigger the `reasoning_extraction` refusal category and cause elevated fallbacks. Audit existing system prompts/skills for "show your thinking" / "explain your reasoning step by step in the response" instructions when migrating. If you need reasoning visibility, read the structured `thinking` blocks from **adaptive thinking** instead, and surface progress via the send-to-user tool.

### API parameter notes (Fable 5 / Mythos 5)
- **Adaptive thinking only** — no extended-thinking budgets; thinking output is **summarized-only**.
- New `refusal` stop reason — handle it and fall back to Opus 4.8.

---

## Recommended scaffolding changes (migration checklist)

- [ ] **Start at the top of your difficulty range.** Assign a task *harder* than you'd give prior models; have it scope, ask clarifying questions, and execute.
- [ ] **Make self-verification explicit in long-run prompts.** Fresh-context *verifier subagents* beat self-critique:
      `Establish a method for checking your own work at an interval of [X] as you build. Run this every [X interval], verifying your work with subagents against the specification.`
- [ ] **Refactor existing prompts & skills — remove, don't add.** Older skills are often too prescriptive and degrade output. Strip instructions and re-check whether default performance is better. Fable 5 can also update skills on the fly from what it learns mid-task.
- [ ] **Audit for show-your-reasoning instructions** (see refusals above) — remove them.
- [ ] **Fix timeouts/streaming/async** for long turns (§2).
- [ ] **Add a send-to-user tool** for long async agents (§10).
- [ ] **Re-evaluate guardrails/tools** — higher capability means some old guardrails are now unnecessary.

---

## Do / Don't cheat-sheet

| ✅ Do | ❌ Don't |
|---|---|
| Steer with one short instruction | Enumerate every behavior by name |
| Point it at your hardest problems | Only test on simple workloads |
| Default to `high` effort, drop to `medium/low` for routine | Assume you always need `xhigh` |
| Async harness + long timeouts | Block until the run returns |
| Provide a memory file + the "one lesson per file" rule | Re-store what repo/chat already records |
| Give intent ("this is for X because Y") | Hand it a bare request with no context |
| Read structured `thinking` blocks for reasoning | Tell it to echo/explain its reasoning in the response (refusal risk) |
| Fall back to Opus 4.8 on `refusal` | Ignore the new refusal stop reason |
| Delete over-prescriptive legacy instructions when migrating | Pile on more instructions to "fix" behavior |
| Use send-to-user only for user-facing content | Route narration/reasoning through send-to-user |

---

## Installation / fleet rollout

To install this skill as a Socialure shared skill:

1. Place `SKILL.md` at `skills/shared/prompting-claude-fable-5/SKILL.md` (this file is the SKILL.md body — strip the `created` line from frontmatter if you prefer).
2. Add to `skills/deploy-manifest.tsv` with the appropriate fleet target column.
3. Run `bash skills/deploy.sh` to propagate to each agent workspace's `.claude/skills/` directory.
4. Verify with `ls /Users/agents/Desktop/Agents/<agent-slug>/.claude/skills/prompting-claude-fable-5/SKILL.md` on a sample agent.

Note: a version of this skill is already installed at `skills/shared/prompting-claude-fable-5/SKILL.md` (v1.0.0, authored by The Senior Founding Engineer). This deliverable is an attachable copy for review/release decisions.

---

*Mythos 5 shares these patterns. For capabilities/pricing/availability see "Introducing Claude Fable 5 and Claude Mythos 5". For cross-model techniques see "Prompting best practices". Source: platform.claude.com docs (build-with-claude/prompt-engineering/prompting-claude-fable-5).*