Anthropic Published Claude's System Prompt. Steal the Structure.

Anthropic publishes the exact instruction text that runs claude.ai and the Claude mobile apps, updated with each model release. You can read the literal rules instead of inferring them from refusals and formatting quirks. The interesting part isn't the transparency story, it's that the file is a production-tested reference for how to organize a system prompt (the fixed instruction block a model reads before every conversation) once it outgrows a paragraph.

Most hand-written system prompts are one long undifferentiated blob: some identity, some tone, some "don't do bad things," all in the same run of text. Claude's isn't. It's segmented, and the segmentation is the lesson.

What's actually public, and what isn't

The published text covers the consumer surfaces only: claude.ai and the mobile apps. It lives on Anthropic's release notes page and changes with each model launch, which means anything you read about it secondhand is a snapshot of a moving target.

The API ships with no default system prompt at all. If you're building on the API, none of these rules apply to your agent unless you copy them in yourself. That scoping matters, because most coverage of this treats it as "Anthropic opened the black box" rather than "Anthropic shipped a reference architecture for one specific product surface."

The prompt isn't one block, it's five categories

Read the file and the seams are obvious. Identity and knowledge cutoff. Formatting rules. Refusal criteria. Topic-specific policy for legal, medical, and political questions. And separately, a set of reminders that are not in the base prompt at all: image_reminder, cyber_warning, system_warning, ethics_reminder, ip_reminder, long_conversation_reminder. Those get appended mid-conversation when a classifier fires or another condition is met.

That last split is the one most hand-written prompts skip: always-true instructions versus triggered-by-context instructions. Here's the skeleton, stripped of Anthropic's content and ready for yours.

## 1. Identity and context
You are <name>, <role> for <product>. Today is <current_date>.
Your training data has a cutoff of <date>.

## 2. Knowledge boundaries
For claims about events after your cutoff: neither confirm nor deny.
Say what you know, name the boundary, offer to search.
Known post-cutoff facts: <inject fast-moving facts here>

## 3. Formatting
Conversational replies: prose, no headers, no bullet lists unless asked.
Documents and reports: paragraphs. Lists only when the user requests one.
Code: fenced blocks with a language tag, always.

## 4. Refusal criteria
Decline only when the response would create a concrete, specific
risk of serious harm. Edgy, hypothetical, or uncomfortable is not
the same as harmful.

## 5. Topic policy
<domain A>: <what you may and may not assert>
<domain B>: <required disclaimer, if any>

<!-- NOT in this file: context-triggered reminders. See section below. -->

By one third-party count, the prompt grew from roughly 358 words in a July 2024 Claude 3 Opus release to about 3,235 words in a July 2026 Opus 5 release. A second independent count puts the same July 2024 Opus prompt closer to 350 words and the July 2026 Opus 5 prompt near 3,200, close enough to agree on direction, but the two sources diverge more in the middle of the timeline, for instance on where the May 2025 Opus 4 prompt lands. Neither count is Anthropic's own data. Both are manual word counts by outside readers of the same published page, so treat the absolute numbers as approximate and the shape of the trend as the more reliable part. On that shape both sources agree: growth is not monotonic. The Opus 5 prompt is shorter than the Opus 4.7 and 4.8 prompts, and a November 2024 Sonnet 3.5 entry runs longer than any of them, an artifact of that entry carrying two near-duplicate instruction sets, one for text chats and one for chats with images.

For anyone who wants to check a specific change rather than trust a summary, Simon Willison turned Anthropic's published prompt page into a git-scraped repository with one commit per revision, so an ordinary git diff between two tags shows exactly what was added, removed, or reworded between versions (simonwillison.net). That's the primary source to point to instead of a manual count.

Nine times the instruction text over two years is not bloat, it's the set of categories a long-lived production agent eventually accumulates. It only becomes bloat when the categories stop being separated.

The refusal rule is narrower than you'd write it

Most people write a refusal rule as a topic blocklist or a vague prohibition. Claude's is a single testable bar in plain language: Claude defaults to helping, and declines only when helping would create a concrete, specific risk of serious harm. Requests that are merely edgy, hypothetical, playful, or uncomfortable don't clear it.

The difference in false-positive refusals is large. The comparison below is an illustration of how each instruction shapes behavior, not a measured benchmark.

BEFORE
  Do not help with harmful, dangerous, illegal, or unethical requests.
  Refuse anything related to weapons, drugs, hacking, or self-harm.

  Likely refuses: "how does a firewall detect port scans"
  Likely refuses: "summarize this novel's overdose scene"
  Likely refuses: "what are the legal penalties for possession in Germany"

AFTER
  Decline only when your response would create a concrete, specific
  risk of serious harm. Three conditions, all required:
    concrete  a real-world action becomes materially easier
    specific  the request targets a named person, system, or method
    serious   the plausible harm is severe, not embarrassing
  Discussion, analysis, fiction, history, and defensive security do
  not meet this bar. When declining, say which condition applies.

  Answers all three above. Declines an operational exploit chain
  against a named production host.

The blocklist version fails because "hacking" is a topic, not a risk. The three-condition version fails only when all three fire together, which is roughly the shape of actual harm. Note that the three-condition breakdown is my expansion, not Anthropic's wording. Verify the exact current text on the release notes page before you paste anything close to it, since secondary summaries paraphrase and the live text changes.

Static rule or injected reminder

The reminder list is the reusable design decision. Anthropic doesn't carry every situational rule in the base prompt; it fires them conditionally. You can copy that with a classifier, a regex, a turn counter, or a tool-call hook. Use this to decide which pile a rule goes in.

1. Is the rule true in every conversation, on turn 1 and turn 200? Base prompt. Identity, formatting defaults, the refusal bar.
2. Does it only apply when a specific input type appears? Inject on detection. Images, uploaded files, pasted code, URLs.
3. Does it only apply after a threshold? Inject on the counter. Long-conversation drift reminders, token-budget warnings.
4. Does it only apply to one topic? Inject on classifier hit. Medical, legal, security. Keeping these out of the base prompt stops them from coloring unrelated answers.
5. Does it change faster than you deploy? Inject from config, not from the prompt file, so it can update without a release.

Knowledge cutoff is the cheapest example of category 5 done as text. Claude is told its cutoff date and told not to confirm or deny post-cutoff claims without searching, and specific post-cutoff facts (including dated notices about newer model releases) have been dropped straight into the prompt. You don't need a retrain to fix a stale fact. You need a line in a file.

Formatting works the same way. Anthropic doesn't leave output shape to the model's taste; it prescribes prose over headers in conversation and paragraphs over bullets in documents. If your agent's output looks over-formatted, that's a missing instruction, not a model limitation.

The published prompt is a free reference for structuring instructions at scale, and the structure transfers even though the content doesn't. Open your own system prompt on Monday, split it into the five labeled sections, and move every situational rule out of the base block into a conditional injection before the file turns into one undifferentiated wall of text.