What a 275K-Character Claude Prompt Teaches Us About Building AI Agents

A GitHub repository recently published what it describes as a runtime system prompt for Claude Fable 5.1. The file contains more than 275,000 characters of instructions related to tool use, web search, memory, copyright, safety policies, and interface behaviour.

That naturally produced a dramatic headline: Claude had been hacked and its secret prompt had leaked.

The evidence does not support such a broad conclusion. There is no public indication that Anthropic’s servers were compromised, that model weights were stolen, or that customer information was exposed. The material is better described as a third-party extraction or reconstruction of instructions presented to the model at runtime.

But that does not make the file uninteresting.

For developers, its real value is not discovering a collection of secret phrases that supposedly make Claude intelligent. It is seeing how much infrastructure now surrounds a frontier model before it becomes a usable AI agent.

TL;DR

• A third-party repository published a purported Claude Fable 5.1 runtime prompt containing more than 275,000 characters.
• The file is not evidence that Anthropic’s model weights, servers, API keys, or customer data were compromised.
• Much of its length appears to come from tool definitions, search policies, memory rules, safety instructions, and product behaviour.
• Modern AI agents are increasingly built through runtime orchestration rather than one carefully written system message.
• Developers should enforce permissions, privacy, provenance, and safety in application code instead of relying entirely on prompts.

What was actually published?

The document appeared in Pliny the Liberator’s CL4R1T4S GitHub repository, which collects system prompts and jailbreak-related material from several AI products.

Anthropic separately publishes an official Fable 5.1 system prompt. The third-party version is substantially larger because it appears to contain more than the assistant’s basic conversational rules.

It reportedly includes instructions covering:

• web search and source selection;
• memory storage and privacy restrictions;
• copyright-sensitive responses;
• computer interaction;
• content and interface presentation;
• tool selection and routing;
• specialised safety behaviour.

Early analysis also identified schemas for roughly 46 tools. That number has not been confirmed by Anthropic as an official tool count, and the GitHub document cannot be independently verified as complete or universally active.

This is an important qualification. A runtime prompt can differ by product, account, enabled features, conversation state, or deployment environment. Extracting one assembled context does not necessarily reveal every instruction used across Claude.

The “system prompt” has become an application bundle

When developers first started building LLM applications, a system prompt often looked like this:

You are a helpful assistant.
Answer clearly and concisely.

A production agent may now receive something closer to this:

runtime_context = [
    base_behaviour_policy,
    product_instructions,
    user_preferences,
    memory_policy,
    available_tool_schemas,
    search_policy,
    retrieved_evidence,
    safety_constraints,
    conversation_history,
]

This is only a conceptual example, but it illustrates the architectural change.

The model is not responding only to the user’s message. It is operating inside a temporary environment assembled by the application. That environment tells it what it can do, which tools exist, what information it may retain, when it should search, and how its answer should be displayed.

Once all of those components are serialised into model-readable text, the context can become extremely large.

A 275,000-character runtime prompt therefore does not necessarily mean someone discovered a single 275,000-character piece of prompt engineering. It may mean the surrounding product stack was flattened into one context.

That is a less sensational story, but a much more useful one.

Tool definitions are part of the product architecture

Giving an agent access to a tool involves more than registering a function name.

The model needs to understand what the tool does, which arguments it accepts, when it should be called, which results it returns, and what restrictions apply. If an application exposes dozens of tools, their schemas and usage rules can consume a significant part of the runtime context.

The agent may also need routing instructions. A request for current information could trigger web search. A request involving an earlier conversation might use a history tool. Another request could produce a chart, preview a page, or interact with a computer.

The resulting flow looks roughly like this:

User request
     ↓
Intent and policy evaluation
     ↓
Tool selection
     ↓
Permission check
     ↓
Tool execution
     ↓
Evidence processing
     ↓
Response generation

Every arrow introduces possible failure modes.

The model can choose the wrong tool. A tool can return malformed data. Authentication can expire. Retrieved pages can contain prompt injection. Two tools can return conflicting answers. The agent can also call the correct tool repeatedly and create unnecessary cost.

A long prompt can explain preferred behaviour, but it cannot remove these risks by itself.

Permission checks, rate limits, schema validation, retries, timeouts, audit logs, and irreversible-action confirmations should be implemented outside the model. The prompt should guide the agent; the application should enforce the rules.

Search needs a policy, not just an API

The reported search instructions are especially relevant to developers building research agents and retrieval-augmented generation systems.

Connecting a search API is relatively easy. Deciding when and how an agent should use it is harder.

Some questions involve stable information and may not need retrieval. Others concern recent model releases, product prices, regulations, company leadership, security incidents, or live events. Answering those from model memory alone creates an obvious freshness problem.

Anthropic’s own Fable 5.1 prompting guide says that lower-effort settings can be less likely to initiate search or retrieval. For changing or unfamiliar subjects, developers may need to instruct the model explicitly to verify the information.

That means a production search agent needs rules for questions such as:

• Which requests require current web data?
• Which sources are acceptable for a particular claim?
• How should recency affect ranking?
• How should duplicate pages be handled?
• What happens when credible sources disagree?
• How does each citation remain attached to the claim it supports?

Without those rules, an agent may perform a search and still produce an unreliable answer.

Retrieval should therefore be treated as part of the reasoning architecture. A search API should return more than a list of URLs. The surrounding system needs structured content, publication information, source metadata, and a way to preserve provenance as evidence moves through the workflow.

Memory creates a data-governance problem

Persistent memory can make an agent feel far more useful. It can remember formatting preferences, recurring projects, or which programming language a user normally chooses.

It can also create serious privacy risks.

A model may encounter information that is sensitive, inferred, outdated, or irrelevant to future tasks. If everything enters a general memory store automatically, the system can preserve data that the user never expected it to retain.

The reported Fable 5.1 instructions appear to define categories of information that should not be stored. Whether every detail in the extracted document is authentic cannot be confirmed, but the architectural principle is sound.

An agent memory system should be able to answer:

• Why is this information being saved?
• Did the user provide it directly, or did the model infer it?
• Which tools and agents can access it?
• When will it expire?
• Can the user inspect, correct, or delete it?
• Which categories must never enter persistent storage?

These controls should exist in the memory service itself. Asking the model not to remember sensitive information is useful, but it should not be the only barrier between a conversation and permanent storage.

Capability and access are different things

Anthropic introduced Fable 5.1 as a model for demanding coding, long-horizon agentic work, and multistep research. Its official model documentation lists a one-million-token context window and support for features such as per-message effort and progress updates.

Anthropic also introduced Mythos 5.1, which is available to approved cybersecurity and life-sciences researchers through Project Glasswing.

The interesting developer lesson is that model capability does not automatically determine product access.

A system can place additional boundaries around particular tools, domains, and actions. Access can depend on the user, organisation, workflow, or risk level.

This is how developers should approach agent permissions as well.

A coding agent may be able to write deployment scripts without receiving production credentials. A research agent may be allowed to read public scientific papers without gaining access to internal laboratory systems. An assistant may draft an email without being authorised to send it.

Capability answers the question “Can the agent do this?” Permission answers “Should this agent be allowed to do it here?”

Those checks belong in separate layers.

Benchmarks are only one part of agent reliability

Fable 5.1 received attention for its performance on ARC-AGI. ARC Prize reports results of 97.5% on ARC-AGI-1 Semi-Private and 90% on ARC-AGI-2 Semi-Private under the tested configurations.

These scores are relevant when evaluating model reasoning. They do not tell us whether an agent built around the model will behave reliably in production.

Production reliability also depends on whether the system can:

• recover from failed tool calls;
• detect untrusted instructions in retrieved content;
• avoid repeating expensive searches;
• distinguish evidence from generated interpretation;
• stop before performing an irreversible action;
• expose enough logs for developers to understand a failure.

The strongest available model cannot compensate for an application that grants every tool unlimited authority or discards the provenance of retrieved evidence.

What developers should take from the reported prompt

The GitHub document will attract attention because of its size and the suggestion that a hidden Claude prompt was exposed. The more durable lesson is that an AI product contains far more than a model.

A robust agent needs several independently enforceable layers:

Model reasoning
Search and retrieval
Tool orchestration
Permissions
Memory governance
Evidence provenance
Safety enforcement
Observability

Prompts connect these layers by giving the model instructions. They should not become substitutes for those layers.

If a rule matters only because it appears in a prompt, assume it can eventually fail. Enforce important restrictions in code, validate every tool argument, keep permissions narrow, and retain enough evidence to reconstruct why an agent produced a particular result.

The purported Fable 5.1 prompt does not prove that Anthropic’s infrastructure was breached, and it should not be treated as an authoritative map of every Claude deployment.

What it does reveal is how dramatically the meaning of “prompt engineering” has changed.

The most capable AI applications are no longer built around one clever instruction. They are built as systems in which models, tools, search, memory, policies, and evidence have to work together.

For developers working on agents today, that architecture is where most of the difficult—and valuable—engineering now lives.

---

How are you handling this in your own agent stack? Are tool permissions and retrieval policies enforced outside the prompt, or is too much of that behaviour still entrusted to model instructions?