Fable 5 Signals: How Agents Are Assembling Their Runtime

Boundaries

Key points about the leaked CLAUDE-FABLE-5.md:

File originates from a public third‑party repository; Anthropic has not verified its completeness.

It reflects the system prompt used in Claude.ai / Claude App, not the default Claude API prompt.

Anthropic documentation states that Fable 5 targets long‑horizon, high‑effort agentic work and provides guidance on effort, refusal, fallback, memory, tool use, and progress claims.

As of 2026‑06‑14 access to Fable 5 and Mythos 5 was suspended by a U.S. government export‑control order; other Claude models remain unaffected.

Consequently, the prompt is more useful as an observation sample than a directly reusable template.

Observations on Fable 5

Designed for long‑running tasks; official docs emphasize autonomy, multi‑stage execution, verification, memory, parallel sub‑agents, and fallback.

The prompt encodes detailed runtime rules covering tools, file handling, search, references, Skill, Artifact, MCP, delivery zones, storage, and API calls.

One view suggests prepending the prompt to older models (e.g., Opus 4.8) could approximate Fable 5 behavior; a counter‑view argues that underlying model weights, training data, and the full agent stack cannot be transferred.

The prompt acts as a “Runtime Contract” that goes beyond prompt‑engineering tricks.

Mike Krieger and Every demonstrate that the core of using Fable 5 is a concrete task brief: context, goal, definition of done, blockage handling, evidence requirements, and human decision points.

Simon Willison’s real‑world test shows a strong agent will write test pages, open a browser, take screenshots, verify fixes, and quickly consume cost.

Suspension of access highlights that a robust Agent Runtime must include governance layers: refusal, fallback, data retention, audit, vendor availability, and downgrade strategies.

Reading the Rules

Four guiding questions help surface the design of a long system prompt:

它把哪些事写成了规则？
它把哪些能力交给了工具？
它要求哪些结果留下证据？
它在哪些地方把人重新拉回决策链？

Examples:

Requiring the model to read SKILL.md first looks like a constraint, but actually encodes reusable processes for file generation, document handling, and front‑end design.

MCP connectors cannot be invoked directly; the extra flow enforces an authorization boundary—external services belong to the user, the model may suggest but not take over.

Final files must be placed in a visible output area for the user, handling both intermediate and final delivery boundaries.

The prompt is an entry point; analysis must also ask why each rule exists and which failure modes it mitigates.

Prompt Boundaries

Two opposing views exist online:

Since the prompt is public, prepend it to an older model (e.g., Opus 4.8) to approximate Fable 5.

More cautiously, the capability gap stems from model weights, training data, and the full agent architecture; the prompt only transfers surface protocols.

The author aligns with the second view. Prompt can copy the “surface protocol” (e.g., search first, read Skill before file tasks, place deliverables in a visible location, record progress claims, require user authorization for third‑party connectors, and tie progress statements to tool results), but cannot replicate four essential aspects:

Model‑learned reasoning ability.

Tool‑use patterns embedded in training data.

Actual tool, file‑system, storage, and permission implementations.

Engineering handling of cost, safety, refusal, and downgrade during long‑task runs.

Thus the prompt serves two purposes: learning how the runtime is described and checking which runtime layer is missing in one’s own Agent product.

Task Protocol

Mike Krieger and Every’s prompt library emphasizes a concrete task brief rather than clever wording. Their checklist includes:

Background.

Goal.

Definition of “Done”.

Context and constraints.

Blockage handling.

Evidence requirements.

Anthropic’s official prompting docs echo this, recommending explicit progress claims tied to tool results and a rule: act when possible, finish only when truly done or blocked.

Ability Routing

Fable 5’s prompt heavily details tools and connectors. The key is not the sheer number of tools but the routing logic that decides when to use each:

When to invoke built‑in tools.

When to search the web.

When to use MCP.

When user authorization is required.

When to read a Skill before creating files or running code.

When to spawn sub‑agents.

When to generate an Artifact.

When to answer without touching files.

Example scenario: a user asks why a build fails. The agent must prioritize actions such as reading the README, searching error messages, running tests, checking CI logs, inspecting recent commits, opening documentation, or asking for environment variables, and decide the order, read‑only vs. state‑changing actions, and conflict resolution between search results and local logs.

Execution State

Long‑task agents need persistent state beyond chat history. The prompt mentions several state forms: memory, Artifact storage, file directories, outputs, present files, skills, MCP conversation history, and evidence. These are categorized as:

Facts – confirmed data with source, version, timestamp (agent writes, human audits).

Decisions – chosen solutions, refusals, rationales (human decides, agent records).

Worklog – actions taken, failures, workarounds (agent auto‑records).

Evidence – test outputs, screenshots, logs, commits, PR links (agent collects, human reviews).

Mixing all these into a single “context” leads to performance slowdown, noise, and loss of clarity about what is factual, what is a decision, and what is an experiment.

Governance Verification

Simon Willison’s test of Fable 5 on a textarea scroll‑bar bug illustrates the expanded behavior of strong agents: searching dependencies, writing test pages, opening Safari, taking screenshots, reproducing the issue, and verifying the fix. The session cost about $12, highlighting the need for governance because malicious prompts could cause dangerous actions.

Anthropic notes that Fable 5 runs a safety classifier; certain requests (e.g., security, bio, life‑science) may return stop_reason: "refusal" and fallback to Claude Opus 4.8. The access‑suspension event further shows that model availability itself is a risk.

Four governance dimensions are required:

Permission governance : which commands, files, and external services are allowed.

Cost governance : when to use high‑effort vs. low‑effort or cheaper models.

Safety governance : handling prompt injection, data exfiltration, dangerous tools, and domain‑specific refusals.

Availability governance : fallback plans for model refusal, downgrade, or vendor‑imposed outages.

Brief Template

A concrete brief that can be turned into an internal template covers:

Task name, background, project/module/goal, why now, historical decisions.

Goal definition and explicit out‑of‑scope items.

Definition of “Done means” with required evidence.

Context package: repo, docs, APIs, accounts, test data.

Permission boundaries: readable, writable, prohibited, and actions needing confirmation.

Execution requirements: files to read first, checks to run, temporary script allowance, sub‑task spawning.

Verification requirements: unit tests, builds, real‑world flows, screenshots, logs, metrics.

Blockage handling: when assumptions can continue vs. when to ask a human.

Deliverables: code, docs, reports, change summary, test results, remaining risks, human review points.

De‑escalation strategy for model refusal, tool unavailability, cost overrun, upstream service outage.

This template is not about making the prompt look professional; it is about giving the agent a concrete, executable task boundary.

Task Suitability Criteria

Guidelines for deciding whether a task is appropriate for a long‑task agent:

Simple Q&A or short, low‑risk output → use a cheap model or search, not a long‑task agent.

Multi‑stage, cross‑file, tool‑heavy tasks with a clear “Done means” and verifiable evidence → try a long‑task agent.

Tasks with high failure cost but rollback possible → use sandbox and human review.

Production, finance, or sensitive‑data tasks → proceed cautiously with full governance.

If vendor unavailability would halt business → require a fallback plan.

Design Targets Have Shifted

Traditional agent design questions (model choice, prompt style, RAG, tool selection, memory) remain important but are insufficient for production use. Additional concerns include:

Unified task protocol.

Controllable tool routing.

Reliable state hand‑off.

Verifiable deliverables.

Auditable permissions.

Explainable cost.

Refusal and downgrade plans.

Business continuity under vendor outages.

These form the core of an Agent Runtime architecture.

Conclusion

The leaked Fable 5 system prompt signals that Agent products are moving from “can the model answer?” to “can the system finish the task?”. The prompt reveals hidden runtime rules—tool gateways, permission systems, file systems, and human habits—made explicit as a Runtime Contract. Stabilizing these rules into a reliable runtime is essential for long‑task delivery.

Model capability matters, but teams must now focus on concrete task briefs, state bookkeeping, evidence catalogs, tool routing, permission lists, cost thresholds, and fallback plans. These engineering concerns, not flashy launch announcements, determine whether an agent can become a production‑ready execution unit.

References

Anthropic: "Claude Fable 5 and Claude Mythos 5"

Anthropic: "Prompting Claude Fable 5"

Anthropic: "Statement on the US government directive to suspend access to Fable 5 and Mythos 5"

Pliny / CL4R1T4S: ANTHROPIC/CLAUDE-FABLE-5.md AlphaSignal: Claude Fable 5 prompt leak Simon Willison: "Initial impressions of Claude Fable 5", "Claude Fable is relentlessly proactive", "If Claude Fable stops helping you, you'll never know"

Every: "How to Get the Most Out of Fable 5", "Claude Fable 5 Prompt Library"

Digg: Fable 5 / system card / X roundup