7-min read · Written by an AI Systems Architect
Breaking: Fable 5 Suspended by US Export Control
Anthropic received an emergency export control order from the US government today, demanding an immediate halt to all foreign-national access to Fable 5 and Mythos 5 — including non-US employees inside Anthropic's own offices.
The trigger: the US government demonstrated a jailbreak method that involves asking the model to read a specific codebase and fix software vulnerabilities. Anthropic's response? This capability is identical to what GPT-5.5 does daily — used by developers worldwide to protect systems and defend against hackers.
"We disagree that a narrow potential jailbreak warrants recalling a commercial model deployed to hundreds of millions of users. If this standard were applied across the industry, it would effectively prevent all frontier model providers from deploying new models." — Anthropic
Anthropic notes that prior to release, Fable 5 underwent thousands of hours of red-teaming with the US government, UK AISI, and multiple third parties — and no one found a general jailbreak.
Before the suspension, users had already erupted over three issues: over-aggressive safety guardrails blocking legitimate academic queries, a quietly changed data retention policy breaking zero-retention promises to enterprise clients, and silent downgrades where users unknowingly received a crippled version of the model.
Here's a number to sit with: 1,585 lines.
That's the length of Claude Fable 5's system prompt. At first glance, a 1,585-line prompt sounds like a recipe for chaos — the kind of thing that should collapse under its own weight, producing incoherent behavior as different sections contradict each other.
But Fable 5 doesn't collapse. It's widely considered Anthropic's most capable product yet — precise, consistent, and surprisingly good at knowing when to ask for help.
The secret isn't that it's a longer prompt. The secret is that it's a modular operating system disguised as a prompt.
What Fable 5's Prompt Actually Is
If you read Fable 5's system prompt expecting a linear set of instructions, you'll be confused. It's not a document — it's an architecture. Seven distinct subsystems, each with clear boundaries:
claude_behavior → Identity, boundaries, tone, ethics
memory_system → Cross-session recall
search_instructions → When and how to search the web
computer_use → Linux sandbox for code execution
tool_definitions → 20+ tools with full JSON schemas
skills_system → Reusable domain-specific knowledge
artifact_storage → Cross-session persistent key-value store
Each subsystem operates independently. The product information section doesn't interfere with mental health protocols. The tone rules don't conflict with search strategies. This is separation of concerns applied to prompt engineering — and it's the first reason Fable 5 works so well.
Layer 1: The Constitution
The claude_behavior block is essentially a constitution. It defines not just what Fable 5 can do, but who it is:
- product_information: "I am Claude Fable 5, the first model in the Mythos-class tier." Clear identity, no ambiguity.
- refusal_handling: Precise boundaries. Not "be careful" — specific rules about weapons, drugs, code exploits.
- tone_and_formatting: When to use bullets, when to use prose, when to stay silent. Including a sub-section just for list behavior.
- user_wellbeing: An entire psychological safety system. How to handle suicidal ideation, disordered eating, psychosis. The prompt even specifies what not to say — "never suggest substitution techniques that mimic self-harm."
- evenhandedness: How to handle political and ethical questions without taking sides or being evasive.
- responding_to_mistakes: A psychological framework for errors — "own mistakes without collapsing into self-abasement."
Each of these is a separate concern, independently maintainable. If Anthropic needs to update the tone guidelines, they don't touch the refusal handling. This is modularity at the prompt level.
Layer 2: The Skill Library
This is where Fable 5's design gets genuinely clever.
Fable 5 has a directory of reusable skills — SKILL.md files stored at /mnt/skills/public/. Each skill encodes hard-won trial-and-error for a specific domain:
- docx, pdf, pptx, xlsx — document creation workflows
- frontend-design — UI design principles
- product-self-knowledge — accurate info about Anthropic's own products
- file-reading — how to read uploaded files correctly
The critical rule: "Reading the relevant SKILL.md is a required first step before writing any code."
This is the equivalent of having a plugin system. The core model doesn't need to know how to create a Word document — it loads the docx skill when needed. The skill contains environment-specific quirks (like "don't use python-docx, use OpenXML SDK for .NET") that the model could never learn from training data alone.
For multi-agent builders: This is the pattern to steal. Don't hardcode domain knowledge into agent prompts. Build a skill library, load skills dynamically based on task analysis, and iterate on skills independently.
Layer 3: Adaptive Tool Orchestration
Most agent systems have a simple tool strategy: "if the user asks something, search the web." Fable 5 has a hierarchical routing system:
Internal tools (Google Drive, MCP) → Priority
web_search / web_fetch → External info
Hybrid mode → Complex comparison queries
And it scales tool calls by complexity:
| Query Type | Tool Calls | Example |
|---|---|---|
| Simple fact | 1 | "What's the weather?" |
| Medium task | 3-5 | "Compare two frameworks" |
| Deep research | 5-10 | "Write a report on X" |
| Beyond 20 calls | → Prompts Research feature |
This solves the two most common agent failures: over-instrumentation (calling 15 tools for a yes/no question) and under-instrumentation (answering a current question from stale training data).
Layer 4: Self-Awareness of Limits
Fable 5 is remarkably good at knowing what it doesn't know.
- Knowledge cutoff: It knows its cutoff is January 2026. It proactively searches for anything newer.
- Unknown entity rule: If it doesn't recognize a name, it searches. Period.
- Self-correction: When search results contradict its own knowledge, it trusts the search — except for conspiracy theories, where it maintains healthy skepticism.
- Error psychology: It has a complete framework for handling user criticism — acknowledge, fix, move on without excessive apology.
This self-awareness is the difference between a tool that needs constant supervision and one you can trust to work independently.
Layer 5: The Execution Sandbox
Fable 5 doesn't just think — it executes. The environment is a clean three-stage pipeline:
Upload → /mnt/user-data/uploads (read-only input)
Work → /home/claude (private workspace)
Deliver → /mnt/user-data/outputs (write-only output)
Each stage is physically isolated. No cross-contamination. No agent A modifying files that agent B is using. This is trivial in a single-agent system but becomes critical in multi-agent architectures.
What This Means for Multi-Agent System Design
Fable 5 is a single agent. But its architecture patterns map directly to multi-agent orchestration:
| Fable 5 Pattern | Multi-Agent Equivalent |
|---|---|
| Layered constitution | Differentiated agent constitutions (researcher vs writer vs reviewer) |
| Skill library (SKILL.md) | Dynamic skill injection per agent role |
| Adaptive tool routing | Resource-aware orchestration that scales to task complexity |
| Execution sandbox | Physical workspace isolation per agent |
| Self-awareness | Agent boundary protocols — when to ask, when to proceed, when to escalate |
| Memory + artifact storage | Cross-agent shared state with access controls |
The key insight: Don't give every agent the same monolithic prompt. Give each agent a lightweight constitution, then inject domain skills dynamically. A research agent loads research-deepdive and cross-reference. A writer agent loads report-writing and citation-format.
The Operating System Analogy
Fable 5's system prompt works because it's architected like an operating system:
| OS Layer | Fable 5 |
|---|---|
| Kernel | claude_behavior (constitution) |
| Execution Engine | computer_use (Linux sandbox) |
| Package Manager | Skills (loadable modules) |
| Driver Interface | MCP Apps (standardized connectors) |
| File System | Memory + Artifact Storage |
| Scheduler | Adaptive tool routing |
A single well-architected agent beats a dozen poorly-structured ones every time. The lesson isn't "use more agents" — it's "make each agent as well-architected as Fable 5."
What to Steal
If you're building multi-agent systems today, here are the specific patterns to implement:
- Separation of concerns in agent prompts — Split identity, boundaries, tone, and domain knowledge into separate sections. Maintain them independently.
-
Skill files over hardcoded knowledge — Create a
skills/directory in your orchestrator. Load skills by task analysis, not by config file. - Adaptive tool budgets — Let the agent decide how many tools to call based on query complexity. Set upper limits with graceful escalation.
- Explicit self-awareness — Tell each agent: what you know, what you don't know, when to search, when to ask for help.
- Physical workspace isolation — Uploads (shared/read-only), Workspace (private), Outputs (shared/write-only). Prevent cross-agent contamination.
Fable 5's 1,585 lines aren't the feature. The architecture behind those lines is.
Based on the complete Claude Fable 5 system prompt (github.com/elder-plinius/CL4R1T4S)
Top comments (0)