What You Need to Know
Prompt reuse covers text that Claude receives on many requests. Three mechanisms answer three different reuse questions. A prefix is the opening part of a prompt. Prompt caching stops a repeated prefix from costing full price each time. Modular prompts stop ten features from each keeping its own copy of the same policy text. Such copies become different over time. Skills give occasional access to a long, detailed procedure without paying for it on every request.
This lesson uses one made-up example throughout: a bank that uses Claude in ten features, including a customer-support assistant and a letter writer. Each support request sends one long policy prompt again, and each feature has its own pasted copy of that prompt. Occasionally a customer asks how to dispute a card payment, which needs a long procedure.
Prefix Mechanics: Stability First
Cache prefixes are created in the order tools, system, messages. Each level depends on the levels before it, so a change at any level invalidates that level and everything after it. This is the reason for the rule "front-load stability". Put the static system prompt, policy documents and few-shot examples first, and dynamic per-request content last. A timestamp early in the prompt changes on every request, so it silently stops the entire cache from working. The bank puts the current time last, beside the customer's message.
How caching behaves in operation matters more than its parameters. A breakpoint marks where the cacheable prefix ends. You can set it explicitly, or it can be managed automatically. The bank sets its breakpoint at the end of the policy text. Cache entries are short-lived by default, and a longer duration is an option. Every use refreshes the entry at no additional cost, so steady traffic keeps a cache warm (not expired) indefinitely. The support assistant receives requests all day, so its entry stays warm. Each model has a minimum cacheable prefix length, and a shorter prompt runs uncached without an error. A near-zero hit rate means dynamic content is invalidating the prefix, or the prefix is too short to cache.
Cache Economics
The cache economics follow a fixed pattern.
- Cache writes cost a premium over base input.
- With the longer duration, the write premium is higher.
- Cache reads get a large discount on every reused token.
Anthropic's pricing page states the break-even point: caching recovers its cost within the first read or two, depending on the duration that you choose. The multipliers are quick-reference material. The judgement that the multipliers require is not quick-reference material.
At high volume, the read discount is the largest effect. Caching then cuts both per-request cost and time to first token (the delay before the response starts), because cached prefix tokens are not processed again. The TTL is the lifetime of a cache entry. For sporadic traffic outside the TTL, the write premium can be more than the savings. The bank's occasional card-dispute query is one such case. "Cache everything" is not universally correct. Do the arithmetic.
Caching is none of these.
- Persistence: the TTL limits how long entries last.
- Freeing window space: cached tokens still occupy the context window (objective 2.4).
- A way to improve quality.
Modular Prompts
A modular prompt is built from versioned sections (role, policy, task instructions, format contract, examples). For each feature, the sections are assembled from a shared library. One reviewed change to the shared policy section reaches every feature. Ten hand-copied prompts become different over time and get fixed nine times. The bank edits its policy section once for all ten features.
A modular prompt is also a cache design. Shared stable sections form common prefixes across features. Their position before the feature-specific sections decides how much of the prefix caches. This applies the template discipline of objective 2.2 to a whole organisation. Prompts are treated as a managed asset with ownership, review and eval coverage.
Skills and Progressive Disclosure
A Skill is a folder with a SKILL.md file. The file starts with YAML frontmatter, a block of settings at the top. The frontmatter contains a name and a description with maximum lengths. An instruction body follows. Reference files and executable scripts can be bundled too. The description is also the trigger, so it must say what the Skill does and when to use it.
Progressive disclosure saves tokens in three documented levels.
- Metadata only: a very small, fixed number of tokens per Skill loads into the system prompt at startup. Thus, many Skills can be installed without a meaningful context cost.
- The SKILL.md body loads only when the task triggers the Skill.
- Bundled resources cost nothing until Claude reads them. Scripts execute, and only their output enters context.
With a monolithic system prompt (one prompt that holds every capability's instructions), you pay for every capability's instructions on every request, used or not. In the support prompt, the card-dispute procedure would add cost to every request. As a Skill, the procedure costs only metadata until a customer needs it.
Custom Skills do not sync across surfaces (the API, claude.ai and Claude Code).
- API Skills are workspace-wide and require the code execution tool.
- Claude Code Skills are filesystem-based.
Choosing the Mechanism
- Standing per-request policy belongs in the cached system prompt, because every request reuses it.
- On-demand expertise and multi-file procedures belong in Skills, because most requests never need them.
- Per-request data belongs in messages, because it changes every time and must come after the cached prefix.
So the bank caches its support policy, makes the card-dispute procedure a Skill and sends each customer's question in messages.
In the exam
Questions describe one situation and include the other two mechanisms, plus a model change, as wrong options. The guide's own sample tests putting stable content first, the cost-and-latency pairing, and when caching does not save money. Questions also test the placement rule and the surface caveat for custom Skills.
The Guide's Own Sample
The exam guide's published Domain 2 sample is a reuse question. In it, an 8,000-token static system prompt and policy document are sent again on every request, and the question flags both latency and cost. The right answer places static content before dynamic content and enables prompt caching. Only that option addresses both concerns without discarding required context. Truncation loses needed policy. Blind downsizing of the model (regardless of task fit) risks quality. A few-shot block for the policy does not, on its own, create a cacheable, reusable prefix.
Where the Figures Live
The Domain 2 quick reference holds current cache figures and Skill field limits.
Exam Traps
Marking content that changes every request, such as timestamps or user data, as cached
The prefix never matches, so every request pays the write premium and reads nothing. The cache then adds cost instead of saving it. Put static content first and per-request values last.
Offering 'enable caching' as the answer to window overflow or quality problems
Cached tokens still occupy the window, so caching changes the cost, not whether the tokens fit. It only skips reprocessing the prefix, so the prompt and quality are unchanged. For overflow, curate or compact the context (objective 2.4); fix quality in the prompt or model.
Trimming few-shot examples or downsizing the model to cut input spend on a repeated static prefix
Both trade quality for a saving the cache delivers free. When the content is genuinely repeated, static-first ordering plus caching cuts the recurring read cost to a fraction with quality untouched.
Putting an organisation's entire procedure library into every system prompt
Every request pays for every capability whether used or not. Skills load expertise on demand for a tiny standing metadata cost per Skill. Bundled resources cost nothing until read. So the single large prompt pays for procedures the request never uses.
Practice Scenario
A claims-processing API serves 40,000 requests per day. Every request sends a 12,000-token system prompt that opens with a short claim record, including a request timestamp, followed by policy rules and few-shot examples that never change. Finance flags input spend, and p95 latency misses the SLA. Answer quality must stay as it is. What should the architect do?
Build Exercise
Design the Reuse Layer for a High-Volume Endpoint
What you'll learn
- How to order a prompt by stability and place the cache breakpoint
- How to compute cache economics for both TTLs at real volume
- How to refactor a prompt into shared modular sections
- How to identify what belongs in a Skill rather than the system prompt
- How to verify caching is active and alert on a sharp fall in hit rate
- Take one production Claude call and split its prompt into sections ordered by stability: tools, system policy, examples, per-request data; mark the cache breakpoint
Why: Invalidation starts at the first changed token and affects everything after it. The stability ordering is the design decision that determines how much of the prompt caches at all.
You should see: The prompt as an ordered list of sections, each marked static or dynamic, with the breakpoint after the last static section.
- Compute monthly input spend with and without caching at your volume — write premium x writes + read price x reads versus full price x requests, for both cache durations, taking the current multipliers from the live pricing page
Why: The break-even comes from arithmetic, not from assumption — the pricing page states it in reads-per-duration terms. Sporadic traffic can make the write premium exceed the savings.
You should see: Three monthly figures — uncached, short duration, long duration — with your traffic pattern stated.
- Refactor the prompt into modular sections in a shared library; identify which sections other features could share as a common cached prefix
Why: Shared stable sections are how modularity increases the benefit of caching — common prefixes across features apply the read discount to more requests.
You should see: A section inventory with owners, plus a list of features that could consume each shared section.
- Identify one procedure that belongs in a Skill instead of the system prompt; write its SKILL.md frontmatter — name, description that acts as the trigger — and outline body, resources, and scripts
Why: The placement rule is what the exam tests: standing policy in the cached system prompt, on-demand procedures in Skills, per-request data in messages.
You should see: Frontmatter with a name and a description that states what the Skill does and when to use it, plus a one-line outline per bundled file.
- Verify in the response usage fields that caching is active (cache_read_input_tokens > 0) and write the alert for a sharp fall in hit rate
Why: A silently broken cache looks like a working system with a bigger bill. The usage field is the reliable record.
You should see: One verified response showing cache reads, plus an alert rule on the read-to-write ratio.
Sources
- Prompt caching — Anthropic
- Pricing — Anthropic
- Agent Skills overview — Anthropic
- Claude Certified Architect Professional Exam Guide (v1.0) — Domain 2 — Anthropic