System prompts occupy an interesting position in AI development. They sit between the trained weights, which encode everything a model learned, and the user’s own instructions, which steer a particular conversation. For API developers, they are also one of the most direct signals about how a model company’s priorities are shifting between versions, because they are the working instructions the model receives by default when nobody has overridden them.
Simon Willison’s analysis of the changes between Claude Opus 4.6 and Claude Opus 4.7 is worth reading carefully, not just for the specific diffs, but for what the practice of tracking them reveals about where Anthropic is spending its attention.
Why the Claude 4.x Family Is Interesting to Compare
The Claude 4.x generation introduced a family structure that Anthropic has been explicit about: Opus for the most capable and demanding tasks, Sonnet for balanced everyday use, and Haiku for fast lightweight inference. What makes the 4.6 to 4.7 Opus jump interesting is that these models share a family but differ in release timing and what Anthropic tuned between them.
The current model roster, as of April 2026, places Opus 4.7 (claude-opus-4-7) at the top of the capability stack, with Sonnet 4.6 (claude-sonnet-4-6) serving as the workhorse and Haiku 4.5 (claude-haiku-4-5-20251001) handling high-throughput cheaper tasks. Opus 4.6 itself appears in a specific context: Claude Code’s fast mode uses it, presumably because it offers a favorable latency-to-capability tradeoff for the interactive coding workflow even after 4.7 became available. This means both 4.6 and 4.7 are production models today, which makes the system prompt comparison practically relevant rather than purely historical.
When two versions of the same model tier exist in parallel production use, changes in how Anthropic instructs one versus the other have real-world consequences for applications.
What Claude System Prompts Contain
The Claude system prompt is not a short document. It covers a range of concerns that the Anthropic team has identified as requiring explicit instruction rather than relying purely on training.
The core sections, across versions, address a few recurring themes. One is self-identification: how the model should answer when asked what it is, whether it should acknowledge being an AI, how to handle questions about its training or its underlying model weights. Anthropic has been deliberate about not having Claude deny its nature or deceive users about what they are talking to.
Another major section covers agentic behavior. As Claude has been increasingly deployed in contexts where it is using tools, reading files, executing code, and taking actions with real-world consequences, the system prompt has acquired more specific guidance around these situations. The guidance generally emphasizes what Anthropic calls a “minimal footprint” approach: prefer reversible actions over irreversible ones, ask for clarification when a task’s scope is ambiguous, err toward doing less and confirming with users when uncertain. This is behavioral engineering through instruction, not just training, which means it can be updated between model versions without a full retraining cycle.
Formatting preferences appear in the system prompt as well. Claude has historically been verbose and markdown-heavy by default; the instructions around when to use headers, lists, and code blocks have been refined across versions, often in response to developer feedback that the default output needed tuning for different contexts.
The Signal in Version-to-Version Changes
When Anthropic changes something between Opus 4.6 and 4.7 in the system prompt, that change reflects a specific decision. Either user or developer feedback surfaced a consistent problem, internal evaluation found a gap in model behavior, or a new capability (like extended tool use or better reasoning) required updated framing instructions.
System prompt diffs reveal things that public announcements often omit. A model card will say a model is “better at agentic tasks” without specifying which failure modes Anthropic patched. A system prompt change that adds more precise language around when the model should pause and verify with a human, before taking an action that modifies persistent state, tells you something specific: there was a problem with the model acting too autonomously in those situations, and the text-based instruction was the chosen lever to address it.
This is the core reason Willison’s ongoing practice of extracting and comparing these prompts has accumulated genuine community interest over time. His simonwillison.net work on AI transparency, including similar analysis of system prompts from OpenAI and Google, has built a reasonable track record of surfacing changes that model providers did not highlight in release notes.
Developer Consequences of Silent Prompt Changes
For most users of the Claude API, the system prompt is either empty (they rely on Anthropic’s defaults) or replaced entirely with their own. If you are passing a fully custom system prompt, the changes to Anthropic’s default do not affect your application directly. But if you are relying on the default, or if you are appending to it rather than replacing it, the changes propagate into your application’s behavior.
The more subtle consequence involves the model’s calibration. Even when developers supply their own system prompt, the trained behaviors that the system prompt reinforces remain present in the weights. If Anthropic has spent model training capacity reinforcing a particular pattern, say, asking for confirmation before irreversible actions, that behavior shows up even when no system prompt instructs it. The system prompt and training interact, and changes in one often signal changes in the other.
For developers building autonomous agents, the agentic behavior sections of the system prompt are where this matters most. An agent built against Opus 4.6’s behavioral profile may produce subtly different outputs on 4.7, not because the underlying task changed, but because the model’s default disposition toward tool use, multi-step planning, or uncertainty handling shifted. These are not breaking changes in the API sense; there is no schema difference, no deprecated parameter. They show up as behavioral drift that you might not catch until a user reports unexpected behavior in production.
The practical response is not to panic about every version bump, but to treat system prompt analysis as part of the evaluation work you should be doing before migrating to a new model version. Running your test cases against both versions and diffing the outputs, particularly for edge cases around tool invocation and ambiguous instructions, is more informative than reading release notes.
The Broader Ecosystem Practice
Anthropics is not the only company whose system prompts get scrutinized this way. OpenAI’s system prompt for ChatGPT has been extracted and analyzed repeatedly, revealing things like character instructions, browsing tool constraints, and policy language around specific topics. Google’s Gemini prompts have received similar treatment.
This kind of third-party analysis fills a gap that official documentation rarely covers: the operational details of how a model is actually instructed to behave versus how the company describes it in marketing materials. There is usually no intentional deception in this gap; it reflects the difference between what matters at the level of product positioning (capabilities, benchmarks, use cases) and what matters at the level of prompt engineering (specific behavioral constraints, fallback handling, formatting rules).
For the developer community, this has become something close to a standard practice. When a new model version ships, someone extracts the system prompt, someone diffs it against the previous version, and the discussion surfaces which changes are meaningful. The Hacker News thread on Willison’s post ran to over a hundred comments, which suggests the community finds concrete value in this kind of transparency work rather than treating it as academic.
As models become more deeply integrated into production systems, and as those systems increasingly give models tools and autonomous execution capability, the stakes of system prompt changes rise. An instruction change that previously affected conversational tone now potentially affects whether an agent deletes a file, charges a customer, or sends an email. The gap between a model’s documented behavior and its actual default behavior matters more when the actions are real rather than textual.
Willison’s analysis is worth bookmarking not because any single diff is critical reading, but because the accumulated record of these changes builds a picture of how model companies are navigating the transition from assistants to agents. That picture is not available anywhere else in as concrete a form.