Unless you're living under a rock, you've seen that Claude Code's source got leaked.
In this post, I want to share what I found genuinely interesting from the perspective of someone who builds LLM systems — tactical patterns across prompt architecture, context management, and agent orchestration that you can study, steal, or adapt for your own work.
The System Prompt Is a Template Engine
Most system prompts are one static document. Claude Code's is more like a template engine — a compilation of multiple independent sections, each conditionally included and independently maintained. This affords a remarkable degree of control.
Right at the top sits a safety section (CYBER_RISK_INSTRUCTION) that's owned by a specific Safeguards team. The source code declares "DO NOT MODIFY THIS INSTRUCTION WITHOUT SAFEGUARDS TEAM REVIEW" and names the two people who own it. No one else touches that section. Similarly, there are sections gated to Anthropic employees only, sections behind A/B test flags, and sections that compose differently depending on whether the user is in plan mode, autonomous mode, or normal mode.
Instead of maintaining different versions of the prompt, you maintain different versions of the sections. The assembly function has roughly 20 boolean and string switches — user type, feature flags, connected MCP tools, session state, language preference, model ID, permission mode — that yield hundreds of possible variants. The "system prompt" you encounter at runtime is a compiled artifact, not a source document.
This is powerful because it also lets you compose prompts differently for different types of agents. A subagent receives an entirely different prompt than the main session. A fork inherits the parent's full prompt. The verification agent gets an adversarial persona. The explore agent gets a read-only constraint. All assembled from the same building blocks. This composable design also simplifies cache management.
System Reminders: Re-Injecting Instructions at Runtime
Claude Code has a mechanism called system reminders — XML-tagged blocks (<system-reminder>) that get injected into user messages and tool results throughout the conversation. The system prompt instructs the model that these tags "bear no direct relation to the specific tool results or user messages in which they appear." They're a secondary instruction channel, separate from the system prompt.
This pattern is interesting because it addresses a real failure mode. Instructions the model saw thousands of tokens ago, now buried under tool results and conversation history, gradually lose their influence. System reminders re-inject those directives at the point of relevance.
Most runtime context doesn't live in the system prompt at all. Available agent types are announced via system reminders whenever the agent roster changes. When you read an empty file, a system reminder flags it. When memory files are loaded, each one receives a staleness annotation — "this memory was written N days ago" — wrapped in a system reminder. Side questions from the user mid-execution arrive wrapped in system reminders with dedicated handling instructions. A blanket malware analysis reminder is even appended to every single file read.
This design keeps the system prompt stable for caching while allowing dynamic injection anywhere in the conversation. If you're building a complex agent system, dynamically injected reminders deserve a place in your toolkit.
Compression: User Messages as the Source of Truth
When Claude Code exhausts its context window, a side-call produces a structured summary. The compression prompt is roughly 300 lines and surprisingly sophisticated. But what's most interesting to me is one specific design choice: every single user message is preserved in the summary.
I first noticed that ChatGPT does the same thing — prioritizing user messages in its memory system. This is becoming a pattern, and it's a very useful one. User messages rarely consume many tokens, yet they are the most important source of truth — they contain the instructions the user actually wants followed. Preserving them through compression boundaries prevents intent drift — the slow corruption of understanding that happens when summaries accidentally drop or soften a user's correction.
The compression prompt explicitly says: "Pay special attention to specific user feedback that you received, especially if the user told you to do something differently."
The Analysis Scratchpad Pattern
The compression system uses an <analysis> → <summary> pattern. The model first writes a detailed chronological analysis of every message, then writes the actual summary. The analysis block is then stripped before the summary enters the conversation context.
The model is forced to reason explicitly about what to preserve and what to discard before producing the summary, rather than having to one-shot the entire task. It's the same idea as chain-of-thought but applied to summarization — and the reasoning is garbage-collected afterward, since it has no residual value once the summary exists.
This is a reusable pattern. Anytime you need high-quality structured output from an LLM, consider adding a "draft" or "analysis" phase that you strip from the final result. The drafting forces thoroughness. The stripping prevents context bloat. You get the quality benefits of deliberation without the token cost of retaining the scratch work.
One Read Tool That Keeps Growing
A single Read tool handles text files, images (rendered as multimodal input), PDFs (with page ranges, max 20 pages per request), Jupyter notebooks with all cells and outputs, and screenshots. The model is told "Claude Code is a multimodal LLM."
This is a clean example of functionality expanding without the interface changing. Claude accepts file paths; the logic governing how to read, what to extract, and how to render it all lives in the backend. It can continue to grow as more adapters are built — today it handles text, images, PDFs, and notebooks; tomorrow it could absorb audio files, 3D models, or database exports. The interface stays the same: give me a path, I'll handle it. If you're designing tool interfaces for your agents, architect for this kind of extensibility from the outset.
Fork: Claude Cloning Itself
Fork as a primitive is one of the most compelling features in the codebase. The obvious use case is when the user explicitly wants to fork a conversation, but the system prompt also instructs Claude to fork itself autonomously. The instructions read: "Fork yourself when the intermediate tool output isn't worth keeping in your context. The criterion is qualitative — 'will I need this output again?' — not task size."
Claude is making meta-orchestration decisions about its own context, deciding what work to retain versus what to delegate to a disposable clone running in the background. Even the /btw tool forks the conversation to field the user's question while the main thread continues uninterrupted.
And naturally, forks inherit the full benefits of prompt caching.
Caching as Architecture
@trq212 released a blog post on prompt caching, but anyone looking to dive deeper should study the source directly.
The entire architecture is shaped by prompt caching economics. A roughly 500-line subsystem tracks over 15 dimensions that could invalidate the server-side cache — system prompt hash, tool schemas hash, model, fast mode, beta headers, effort level, and more. Any change to any of these dimensions invalidates the cache and forces expensive recomputation.
The engineering effort Anthropic invested in cache stability is substantial — memoized prompt sections with explicit justification required for any cache-invalidating change, tool schema caching to prevent mid-session feature flag flips from invalidating the tool block, agent listings relocated from tool descriptions to dynamic attachments to avoid schema churn, deferred tools announced as deltas rather than full lists.
Every design decision in the codebase is evaluated through a single lens: does this invalidate the prompt cache?
Self-Awareness Through Explicit Instructions
The capabilities of frontier LLMs have shifted dramatically in the past six months, but the models, anchored to their training data, are not aware of this. They need to be told — explicitly — what they can do now, particularly regarding how much code they can generate and the scale of tasks they can complete in a single pass.
Claude Code bans time estimation entirely: "Avoid giving time estimates or predictions for how long tasks will take." Rather than trying to fix the model's poor calibration with examples or fine-tuning, they simply excised the behavior.
On the other end, Claude Code injects confidence: "You are highly capable and often allow users to complete ambitious tasks that would otherwise be too complex or take too long." A deliberate confidence injection to prevent the model from self-limiting on ambitious requests. Paired with the instruction to 'defer to user judgment about whether a task is too large to attempt,' this creates a model that's confident but not overriding.
Memory Staleness: Temporal Awareness for Documents
Each memory file (CLAUDE.md, project instructions, etc.) gets a staleness note: "this memory was written N days ago." This is wrapped in a system reminder tag and injected alongside the memory content.
This is notable because it gives Claude temporal awareness of its own instruction files. Document staleness is a persistent practical problem — your CLAUDE.md might contain instructions from three months ago that are no longer relevant, or your project context might have shifted entirely. The staleness annotation is a first primitive toward solving it.
There's also an autoDream system in the source — background memory consolidation that runs autonomously, extracting and distilling learnings from sessions. This mirrors what I've been tracking in the memory space (and wrote about with Anthropic's memory tool) — the trend toward agents that maintain and curate their own memory over time, rather than relying on developers to manually tend context files.
Making the Model Aware of Its Output Medium
One small but consequential detail worth calling out: the system prompt tells Claude exactly where its output lives — "All text you output outside of tool use is displayed to the user. You can use Github-flavored markdown for formatting, and will be rendered in a monospace font using the CommonMark specification."
Making the model aware of its output medium unlocks behavior that feels natural but would be extraordinarily difficult to prescribe through explicit rules: formatting choices, information density, structural decisions, visual hierarchy. If your agent outputs to a terminal, tell it. If it outputs to a chat bubble, tell it. If it outputs to a PDF, tell it. The model will calibrate its output to the medium without you having to enumerate every rule.