What I learned reading Claude's system prompts

I spent a few hours reading Anthropic’s published Claude system prompts and the Hacker News discussion about them.

I expected to find a clever prompt.

Instead, I found the history of a product.

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

The latest prompts are thousands of words long.

They contain product details, safety rules, writing advice, and recent news. They also explain when one model may answer instead of another.

No single rule is the most interesting part.

The whole document is.

It shows us how much work happens around the AI model.

The model is not the product

This is the first thing to understand.

Anthropic publishes the main prompts used by the Claude website and apps. The company says these prompts 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 this page is important. But 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

This explains why the same model can feel different in different places.

You can use the same model in Claude.ai, Claude Code, or your own app. Each product gives the model different instructions and tools.

The model may be the same. Everything around it is not.

The prompts became bigger, but not always

One Hacker News comment compared an early prompt with a new one.

The early prompt had a little over 300 words. The new prompt had more than 3,000.

This is true 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.

But the complete history tells a better story.

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

The prompt did not keep growing forever.

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 needs an explanation. It contains two similar sets of instructions. One is for text chats, and one is for chats with images.

Still, the numbers are useful.

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. This makes the changes much easier to follow.

A Git diff shows when a rule appeared or disappeared. It looks like the history of a normal software project.

One prompt has many jobs

I used to think a system prompt did one thing.

It told the AI what kind of assistant it should be.

That is now only a small part of the job.

The latest Claude prompt is at least five different documents joined 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.

This helps Claude answer questions about itself.

For example, someone may ask, “Which model am I using?” That information may be newer than the model’s training data. The prompt gives Claude the answer.

The prompt also tells Claude when not to guess.

Prices, account limits, and product instructions can change. Claude is told to send people to the documentation or support when needed.

This is good product design.

A model with old product information can give a confident but wrong answer. It is better when the model knows where its knowledge ends.

It adds recent facts

The Opus 5 prompt contains events that happened after its May 2026 knowledge cutoff.

It explains that Anthropic released two newer models. It also explains that access was suspended and later restored.

The prompt tells Claude something unusual: it knows these events only because they appear in the prompt.

This is a useful trick.

You do not need to train the model again to add one new fact. You can place that fact in the prompt today.

But this creates another problem.

Facts become old. A prompt can say something true today and wrong next month.

People in the Hacker News discussion noticed this in older prompts. Some prompts described a model list that was already out of date.

The system prompt now acts as two things:

• a list of instructions
• a small database of current facts

Those two things change at different speeds. Keeping them in one file makes the prompt harder to maintain.

It is a writing guide

The prompt tells Claude how to speak.

It says when to ask a question, when to use a list, and how long an answer should be. It explains how Claude should react when someone is rude.

Some rules are very specific.

Claude should check whether a file was really uploaded. It should not keep a conversation going when someone wants to leave. It should admit mistakes without becoming too apologetic.

These do not sound like rules written before the product launched.

They sound like fixes for conversations that went wrong.

It contains safety rules

Large parts of the prompt cover difficult topics.

These include child safety, weapons, harmful code, legal advice, financial advice, self-harm, and eating disorders.

The rules become more detailed when a mistake could cause serious harm.

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

One idea appears several times: the full conversation matters.

A single request may look harmless. But it can become dangerous after ten earlier messages.

Claude is told to look at where the conversation is going. It should not judge each message alone.

It connects different safety systems

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

Why?

Anthropic has another safety system that 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. Claude can then tell the person why a different model answered.

The prompt mentions other safety checks too.

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.

This tells us something important.

The prompt is not the full safety system. It is one part that talks to the other parts.

The prompt is a history of mistakes

Large instruction files often grow in 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 appears months later. The agent must now read many rules written at different times.

Some rules may repeat each other. Others may pull in opposite directions.

I call this prompt debt.

It is similar to code that becomes harder to maintain. But prompt debt has an extra cost: the model reads the instructions on every task.

The system prompt is not the whole safety system

Some Hacker News comments noticed that the first prompts had fewer safety rules.

That is true.

But it does not prove that the first models had no safety checks.

A system prompt is only one layer. Training can change 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. They talk about safety checks, added reminders, and requests moving between models.

There is a simple lesson here.

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.

A prompt can tell a model not to reveal secrets. The tool should avoid showing those secrets in the first place.

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 normal language makes sense here.

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.

This has some clear advantages.

Anyone on the team can read the prompt. Product, support, safety, and engineering teams can review the same file.

Anthropic can also change the prompt without training a new model.

But a prompt is not normal code.

A model can misunderstand a sentence. Two rules can disagree. A later message can pull the model’s attention away from an earlier rule.

The same prompt can also produce different answers.

I think of a prompt as a set of 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 discussion spent a lot of time on rules that seem to disagree.

There are real tensions in the prompt.

Claude should be brief. But it should give a full answer when asked.

It should be warm and curious. But it should not ask questions that are not needed.

It should help by default. But it must refuse some dangerous requests.

It should explain a political view fairly. But it should also include the strongest opposing view.

These goals 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 must 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. They are two different prompts.

Some Hacker News comments mixed them together.

The result is still useful. 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. This helps with speed and price.

But it does not remove the prompt from the context window. Anthropic explains this in its prompt caching documentation.

A long prompt has at least three costs:

• Space. It leaves less room for the task.
• Attention. The model must find the rules that matter now.
• Maintenance. Someone must keep every rule and fact correct.

The Hacker News discussion 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.

But the main point is clear.

Text added to every request should have a good reason to be there.

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.

This limits what we can learn.

A tool description tells Claude what a tool does. It also explains which information the tool 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 approach.

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

So reading only the main prompt is like reading one important file in a large app.

You can learn a lot from it. But you cannot see the whole product.

What I would change in my own agent setup

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

First, I would keep the main prompt as short as possible.

It should explain the product, the order of instructions, and the rules that apply to every task.

Next, I would move special workflows into skills. A writing skill should load for writing. A deploy skill should load for a deploy.

This is the idea behind fstack. Each skill has one job instead of trying to manage everything.

I would also keep current facts outside the main prompt.

Model names, prices, product status, and schedules change often. They should live in one place that tools can read when needed.

I would put tool instructions next to the tools.

If a tool can perform a dangerous action, 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:

1. Check every change.
2. Remove rules that are no longer needed.
3. Find rules that cover the same behavior.
4. Test important changes with real tasks.
5. 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 makes a mistake.

Only one of those problems needs another prompt rule.

The main lesson

Claude’s published prompts show us the product around the model.

Before a person types anything, Claude already receives a lot of information. It gets a role, a date, a knowledge limit, product details, safety rules, and writing instructions.

It may also receive signals from other safety systems.

The prompts show the limits of putting everything in one place.

The file grows because adding one more sentence is easy. Later, the rules become harder to understand and maintain.

The best system prompt is not the longest one.

It is a small, stable set of rules. Special instructions should stay close to the task. Hard safety limits should live in code too.

That is what I learned from reading 29 versions of Claude being told how to be Claude.