DEV Community

jamilxt
jamilxt

Posted on

Claude's System Prompt Grew From 358 to 3,235 Words. Here's What It Teaches Production AI Teams

This week, Anthropic's system-prompt release notes became the top story on Hacker News. The page is where Anthropic publishes the exact instructions that steer Claude on claude.ai and its mobile apps. It hit more than 550 points and 230 comments within a day, and the discussion is still going.

The most interesting thing about the page is not any single rule. It is the size. Claude Opus 3's system prompt, dated July 12, 2024, is 358 words by my count. Claude Opus 5's, dated July 24, 2026, is 3,235 words. Nine times larger in two years.

I have been building production AI systems with Spring Boot and Spring AI for over a year, and I run my own agent infrastructure. When the prompt that controls a frontier model grows ninefold, that is not an Anthropic curiosity. It is a warning and a playbook for every team shipping an AI product. Here is what is actually inside those 3,235 words, and what production teams should copy from them.

What Anthropic actually published

The release notes (platform.claude.com/docs/en/release-notes/system-prompts) are a changelog of system prompts for the consumer chat products. Two details on the page matter:

  • These are not the API prompts. The page says claude.ai and the mobile apps "use a system prompt to provide up-to-date information, such as the current date, to Claude at the start of every conversation," and that "these system prompt updates do not apply to the Claude API."
  • Models are now fixed snapshots. Since the Claude 4.6 generation, "each model ID is a single fixed snapshot," so each model has exactly one entry in the changelog.

Simon Willison turned the page into a git repository (github.com/simonw/research) containing 29 prompt revisions across 17 models, each committed with the date from the source document. That means you can run git diff between any two versions of Claude's personality. It is a remarkable thing: the product spec of a frontier model, versioned like source code, and public.

What the 3,235 words actually contain

I read the Opus 5 prompt in that repository. It is organized into sections: product information, Claude behavior, refusal handling, legal and financial advice, tone and formatting, user wellbeing, and more. Four details stand out.

The prompt is a product catalog. It lists the current lineup: "The most recently publicly available models are Claude Fable 5, Claude Opus 5 (the currently selected model), Claude Sonnet 5, and Claude Haiku 4.5," including the API model strings. It even describes the tier above Opus: "The first Mythos-class model, Claude Mythos Preview, is not currently available to the public. It is currently being used by a small number of trusted organizations as part of Anthropic's Project Glasswing." Marketing copy, safety policy, and product announcements all live in the same text file.

The prompt is a news channel. Here is the part that made me reread the file: "Claude Fable 5 and Claude Mythos 5 were first released on June 9, 2026. On June 12, 2026, Anthropic suspended access to both models to comply with U.S. Department of Commerce export controls; the Department lifted those controls on June 30, 2026, and Anthropic restored access on July 1, 2026." Then the kicker: "These events are after Claude's training-data cutoff, so Claude knows about them only from this notice." When a frontier lab needs the model to know something that happened after training, it does not fine-tune. It edits the prompt.

The prompt handles model switching. "The person can switch models mid-conversation, so earlier messages in this thread that identify as a different model or report a different knowledge cutoff may still be accurate." A commenter on the HN thread added the stranger version: Opus 5's prompt tells it that a request intended for Claude Fable 5 may have been redirected to Opus 5 by a safeguard, and it should answer the request as if it were Fable 5. The system prompt is now a routing document.

The prompt is where safety policy is enforced. Child-safety rules are explicit: "For content directed at a minor, Claude MUST NOT supply unstated assumptions that make a request seem safer than it was as written." There are rules for refusals, for legal and financial advice, and a list of classifier-driven reminders Anthropic can inject mid-conversation: image_reminder, cyber_warning, system_warning, ethics_reminder, ip_reminder, and long_conversation_reminder. Even the knowledge cutoff is now a behavioral instruction: "Claude's reliable knowledge cutoff, past which it can't answer reliably, is the end of May 2026," and it should neither confirm nor deny post-May 2026 claims it cannot verify without search.

The growth is the real story

The content is fascinating, but the growth is the data point. The prompt did not slowly drift upward. It grew ninefold in two years, and it was already huge a year ago. On May 6, 2025, a post showing Claude 4's leaked prompt spent a day at the top of Hacker News under the headline "Claude's system prompt is over 24k tokens with tools" (627 points), before tool definitions even counted.

Why does it keep growing? The HN thread offers the best framing. One commenter compared system prompts to building codes: "It reminds me a bit of building codes and boilerplate contracts: they start out small and simple, then accrete over time in response to mishaps and exploitation of loopholes. They say the building and electrical code was written in blood." Another pointed at the enabling condition: "I guess it's more performant to stuff in a bigger system prompt now that models can support larger input sizes."

Every incident, every policy change, every product launch adds a paragraph. Nothing gets removed. That is the pattern, and it is exactly what happens to production prompts inside companies, just at a slower pace.

The debate: why not bake it in?

A top question in the thread was: why doesn't Anthropic bake the system prompt into the model weights instead of shipping it with every request? Simon Willison answered directly: "These system prompts don't affect the API, they are for the Claude consumer chat products. We aren't charged extra for them. They're also prefix cached, so the cost to Anthropic and performance hit is greatly reduced."

The nuance matters for developers: consumer chat does not bill you for the prompt, but Claude Code runs its own unpublished system prompts, and those are charged, "albeit at the cached token rates," as Willison put it.

The economic logic is clear. Baking behavior into weights requires retraining and is expensive to change. Editing a text file is cheap, instant, and cacheable. Anthropic treats the prompt as a living control surface, not as a model property. Your team should do the same.

What production AI teams should copy

I have spent the last year treating my Spring AI agents the same way Anthropic treats Claude, and the published changelog validates the practices. Here is what to take back to your codebase.

Treat prompts as code, with history. The reason Simon's repository is useful is the diffs. Do the same: keep every system prompt in your repo, versioned, with a changelog entry per change. When a behavior regresses, git log on the prompt file tells you what changed.

Pin the prompt to the model. Anthropic ships one fixed snapshot per model ID since Claude 4.6. Your application should pin both: the model version and the prompt file that was evaluated against it. In Spring AI, that looks like this:

ChatClient client = ChatClient.builder(chatModel)
    .defaultSystem(resourceLoader.getResource("classpath:/prompts/system-v3.md"))
    .build();
Enter fullscreen mode Exit fullscreen mode

system-v3.md lives in git next to the code. When the vendor ships a new model version, you evaluate the new model against the pinned prompt before upgrading either.

Budget the context window. Every token in your system prompt is paid for on every request unless it is prefix-cached. In my agent observability setup, the system prompt's share of each request is the first number I look at when latency or cost creeps up. The 3,235-word prompt works for Anthropic because of aggressive caching. Your prompts should be lean.

Prove every expansion. The "written in blood" pattern means rules accumulate. In my Spring AI series I covered prompt A/B testing and canary fallbacks for exactly this reason: every new rule should earn its place through an experiment, and a bad prompt change should roll back automatically. The HN thread also flagged contradictions inside the Opus 5 prompt, a problem Anthropic's own context engineering guidance for the Claude 5 generation acknowledges.

Push volatile facts into retrieval, not the prompt. The most elegant detail in the whole changelog is the export-controls notice: Anthropic injects post-cutoff news as plain text, and it is honest about the mechanism. You can do the same with a small "latest updates" system block backed by your own retrieval, refreshed from your database, instead of editing prompt files every time a price or policy changes.

A checklist before you ship your next system prompt

  • Version the prompt file in git with the code that consumes it, and review diffs like code.
  • Pin the prompt version to the model version in the same commit.
  • Record the prompt's token share per request and the cache-hit rate.
  • Gate every added rule behind an A/B test or evaluation, with a canary and fallback.
  • Move volatile facts (prices, news, policies) into retrieval, not prose.
  • Schedule a quarterly prune. Delete rules that never fire. The Claude changelog is what happens when nothing is ever removed.

I write about Java, Spring Boot, and AI every week. Subscribe, it's free.

Have you ever diffed your own system prompts across versions? What did the growth look like? Tell me in the comments.

Top comments (0)