What I learned reading Claude's system prompts

Anthropic publishes the system prompts used by Claude on the website and in the apps. I sat down and read them. All 29 versions, plus the Hacker News thread about them.

The first prompt is tiny. It tells Claude who it is, the current date, when its knowledge ends, and how detailed the answers should be.

The latest ones run to thousands of words. Product details, safety rules, writing advice, recent news, and when one model may answer instead of another.

The useful part is the whole file, and how much work sits around the model.

The model is not the product

Those published prompts are for Claude.ai and the apps. They do not apply to the Claude API.

Claude Code has a different prompt. Tool descriptions add more instructions. Search results, memory, user settings, and the conversation add even more.

So the text on that page matters. It is not the whole Claude product.

Claude works more like this:

model
  + system prompt
  + tool descriptions
  + safety checks
  + product features
  + memory and preferences
  + conversation
  = the Claude experience

That’s why the same model feels different in Claude.ai, Claude Code, or your own app. Each product gives the model different instructions and tools.

The prompts got bigger. Then they stopped.

Someone on Hacker News compared an early prompt with a new one. A little over 300 words vs more than 3,000.

That holds for the Opus models. Claude Opus 3 had about 350 words in July 2024. Claude Opus 5 had about 3,200 words in July 2026.

The full history is less linear.

Here are rough word counts from some of the published prompts:

The Opus 5 prompt is shorter than the Opus 4.7 and 4.8 prompts. A Sonnet 3.5 prompt from 2024 is longer than all of them.

That old Sonnet entry is a bit of a cheat. It contains two similar sets of instructions, one for text chats and one for chats with images.

Anthropic keeps moving instructions around as the models improve. It adds some rules, removes others, and moves some work into tools.

Simon Willison put the prompt history in a Git repository. A Git diff shows when a rule appeared or disappeared. It looks like the history of a normal software project.

One prompt does a lot of jobs

I used to think a system prompt just told the AI what kind of assistant it should be. That’s now a small part of the job.

The latest Claude prompt is several documents glued together.

It is a product manual. The prompt tells Claude which model it is. It lists other Claude models, product names, settings, and support links. Someone asks “Which model am I using?” and that information may be newer than the model’s training data. The prompt has the answer.

It also tells Claude when not to guess. Prices, account limits, and product instructions change. Claude is told to send people to the docs or support.

A model with old product information gives a confident wrong answer. Better if it knows where its knowledge ends.

It also carries recent facts. The Opus 5 prompt contains events that happened after its May 2026 knowledge cutoff. Anthropic released two newer models. Access was suspended and later restored. The prompt tells Claude something unusual: it knows these events only because they appear in the prompt.

You do not need to retrain the model to add one new fact. You put that fact in the prompt today.

Facts go stale though. A prompt can be true today and wrong next month. People on Hacker News noticed this in older prompts. Some described a model list that was already out of date.

So the system prompt is now two things at once. A list of instructions, and a small database of current facts. Those two things change at different speeds. Keeping them in one file makes the prompt harder to maintain.

Then there is the writing guide. When to ask a question. When to use a list. How long an answer should be. How to react when someone is rude.

Some rules are very specific. Check whether a file was really uploaded. Do not keep a conversation going when someone wants to leave. Admit mistakes without becoming too apologetic.

Those look like fixes for conversations that went wrong, not rules written before launch.

Large parts of the prompt cover difficult topics. Child safety, weapons, harmful code, legal advice, financial advice, self-harm, eating disorders. The rules get more detailed when a mistake could cause serious harm.

Claude is told when to refuse, and how to refuse. In many cases it can still give safe and useful information.

One idea shows up again and again: look at the full conversation. A single request may look harmless. After ten earlier messages, it may not be.

There is also a section that explains a person may choose Fable 5 but get an answer from Opus 5.

Why? Another safety system checks the request first. When it finds a risky topic, it may send the request to Opus instead. Anthropic says this happens in less than 5% of sessions on average. It can also happen by mistake on a harmless request.

The Opus prompt explains this change to the model, so Claude can tell the person why a different model answered.

Anthropic can add an extra reminder when one of those checks finds a risk. It can also add a reminder during a very long conversation.

The prompt is a history of mistakes

Large instruction files grow the same way.

Something goes wrong. Someone adds a rule. A new problem appears, so the rule gets a second paragraph. Then someone adds an exception.

After a year, the file contains the history of many old problems.

I know this pattern because it happens in my own AGENTS.md files.

An agent edits the wrong file, so I add a rule. It publishes a post before I review it, so I add another rule. It uses the wrong public product name, so I add one more.

Each rule makes sense when I add it.

The trouble shows up months later. The agent now reads many rules written at different times. Some repeat each other. Others pull in opposite directions.

I call this prompt debt.

It is like code that becomes harder to maintain. Prompt debt has an extra cost though. The model reads the instructions on every task.

A prompt is not a lock

Some Hacker News comments noticed that the first prompts had fewer safety rules. That does not mean the first models had no safety checks.

A system prompt is one layer. Training changes model behavior. Separate programs can check the input and output. Product permissions can block dangerous actions.

The newest prompts mention some of these other layers. Safety checks, added reminders, requests moving between models.

If something must always be safe, do not trust the prompt alone. A prompt can tell an agent to ask before deleting production data. The delete tool should still require a clear approval. Same for secrets. Don’t put them in front of the model and then ask it not to repeat them.

Language helps the model make a judgment. Code should enforce the hard limits.

Normal language is now part of software

One Hacker News commenter found these prompts surprising because they use normal language.

I think that makes sense. Language is how we tell a language model what we want.

In a normal program I change code or data. With an AI model I can often change its behavior by changing a sentence.

Anyone on the team can read the prompt. Product, support, safety, and engineering can review the same file. Anthropic can change the prompt without training a new model.

A prompt is not normal code though.

A model can misunderstand a sentence. Two rules can disagree. A later message can pull attention away from an earlier rule. The same prompt can produce different answers.

I think of a prompt as directions given to a very capable person. The directions matter, but they do not control every move.

Rules can pull in different directions

The Hacker News thread spent a lot of time on rules that seem to disagree.

Claude should be brief, but give a full answer when asked. Warm and curious, but not ask questions that are not needed. Help by default, but refuse some dangerous requests. Explain a political view fairly, and include the strongest opposing view.

These are not always mistakes. They are choices Claude must make during each conversation. The correct choice depends on what the person needs.

The problem is the amount of work this creates for the model.

The same idea may appear in the system prompt, a skill, a tool description, a project file, and the user’s request. Claude has to work out which instruction matters most.

Anthropic found this problem inside Claude Code.

In its article about context engineering for Claude 5, Anthropic says its instructions were fighting each other. The Claude Code team removed more than 80% of its system prompt. It found no clear drop in its coding tests.

Notice that this was the Claude Code prompt.

The 3,200-word prompt on the history page belongs to the Claude chat product. Two different prompts. Some Hacker News comments mixed them together.

A better model does not always need more instructions. Sometimes it works better with fewer.

A long prompt uses space and attention

Every model has a limit on how much text it can read at once. We call this the context window.

The system prompt takes part of that space. The rest must hold the conversation, uploaded files, search results, tool descriptions, and the answer.

I described the same problem in my RAG chunking guide. Every piece of text competes for space inside the same window.

Anthropic offers prompt caching to make repeated prompts cheaper and faster. The system can process the same beginning once and reuse that work later.

That helps with speed and price. It does not remove the prompt from the context window. Anthropic explains this in its prompt caching documentation.

A long prompt leaves less room for the task. The model has to find the rules that matter right now. And someone has to keep every rule and fact correct.

The Hacker News thread also talked about computing power and energy use. We cannot calculate the exact cost from the word count alone. Caching, the model design, and Anthropic’s servers all change the result.

The missing tool descriptions matter

Anthropic does not publish the tool descriptions on this page. It does not publish the Claude Code prompt there either.

That limits what we can learn.

A tool description tells Claude what a tool does, which information it needs, and what it returns. Good tool descriptions can replace many general rules. They keep the instructions close to the action.

Anthropic now recommends loading tool descriptions only when Claude needs them. Its tool context guide explains this.

This saves space and gives Claude fewer unrelated instructions to read.

Reading only the main prompt is like reading one important file in a large app. You learn a lot, but you miss the rest of the product.

What I would change in my own agent setup

Reading these prompts made me look at my own instructions differently.

I would keep the main prompt as short as possible. Product, the order of instructions, and the rules that apply to every task.

Special workflows go into skills. A writing skill loads for writing. A deploy skill loads for a deploy. This is the idea behind fstack. Each skill has one job.

Current facts stay outside the main prompt. Model names, prices, product status, schedules. They change often. They should live in one place that tools can read when needed.

Tool instructions sit next to the tools. If a tool can do something dangerous, the tool should make the safe path clear. Its permission system should block actions that need approval.

The main prompt should not explain every feature in the product.

I would review instruction files like code. Check every change. Remove rules that are no longer needed. Find rules that cover the same behavior. Test important changes with real tasks. Use code when a rule must always be enforced.

Most of all, I would stop adding a new rule after every bad answer.

Sometimes the model needs more information. Sometimes the tool is confusing. Sometimes the workflow needs an approval step. And sometimes the model just makes a mistake.

Only one of those problems needs another prompt rule.

I read 29 versions of Claude being told how to be Claude. The file grows because adding one more sentence is easy. Later the rules become harder to understand and maintain.

I want a small, stable set of rules, special instructions close to the task, and hard safety limits in code too.

Want me to talk about your product? You can sponsor this site.