What You Need to Know
Prompt reuse covers text Claude receives on many requests. Three mechanisms answer three different reuse questions. Prompt caching stops a repeated prefix, a prompt's opening part, costing full price each time. Modular prompts stop ten features each keeping a drifting copy of the same policy text. Skills give occasional access to a deep procedure without paying for it on every request.
An optician runs Claude behind ten features, including a booking assistant and a recall-letter writer. Each booking request resends one long policy prompt, and each feature has its own pasted copy. Occasionally a customer asks about contact-lens aftercare, which needs a long procedure.
Prefix Mechanics: Stability First
Cache prefixes are created in the order tools, system, messages. Each level builds on the ones before, so a change at any level invalidates it and everything after. Hence the rule, front-load stability: static system prompt, policy documents and few-shot examples first, dynamic per-request content last. A timestamp early in the prompt changes on every request, so it silently defeats the entire cache. The optician puts the current time last, beside the customer's message.
The operational shape matters more than the parameters. A breakpoint marks where the cacheable prefix ends, set explicitly or managed automatically. Entries are short-lived by default, with a longer option. Every use refreshes the entry at no additional cost, so steady traffic keeps a cache warm indefinitely. 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 economics have a fixed shape.
- Cache writes carry a premium over base input.
- The longer duration charges a higher write premium.
- Cache reads earn a steep discount on every reused token.
Anthropic's pricing page states the break-even: caching pays for itself within the first read or two, depending on the duration chosen. The multipliers are quick-reference material; the judgement they force is not.
At high volume the read discount dominates. Caching then cuts both per-request cost and time to first token, because cached prefix tokens are not reprocessed. For sporadic traffic outside the TTL, the entry's lifetime, the write premium can exceed the savings. The optician's occasional aftercare query is one such case. "Cache everything" is not universally correct. Run the arithmetic.
Caching is none of these.
- Persistence: entries are bounded by the TTL.
- Window relief: cached tokens still occupy the context window (objective 2.4).
- A quality lever.
Modular Prompts
A modular prompt is built from versioned sections (role, policy, task instructions, format contract, examples), assembled per feature from a shared library. One reviewed change to the shared policy section propagates everywhere. Ten hand-copied prompts drift apart and get fixed nine times. The optician edits its policy section once for all ten features.
Modularity is also cache design. Shared stable sections form common prefixes across features. Ordering them before feature-specific sections decides how much of the prefix caches. This is objective 2.2's template discipline scaled to an organisation: prompts as a managed asset with ownership, review and eval coverage.
Skills and Progressive Disclosure
A Skill is a folder with a SKILL.md file. Its YAML frontmatter carries a length-capped name and description. An instruction body follows. Reference files and executable scripts can be bundled too. The description doubles as 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 tiny fixed footprint per Skill loads into the system prompt at startup, so many Skills can be installed without meaningful context penalty.
- The SKILL.md body loads only when the task triggers the Skill.
- Bundled resources cost nothing until read, and scripts execute with only their output entering context.
A monolithic system prompt pays for every capability's instructions on every request, used or not. In the booking prompt, the aftercare procedure would cost every request. As a Skill, it costs only metadata until a customer needs it.
Custom Skills do not sync across surfaces.
- API Skills are workspace-wide and require the code execution tool.
- claude.ai Skills are per-user.
- 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 optician caches its booking policy, makes aftercare a Skill and sends each customer's question in messages.
In the exam
Stems describe one situation and plant the other two mechanisms, plus a model change, as distractors. The guide's own sample keys front-load stability and the cost-and-latency pairing, and when caching does not pay. Items 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 item: an 8,000-token static system prompt and policy document resent on every request, with latency and cost both flagged. The keyed 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 risks quality, and a few-shot block for the policy creates no 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 — timestamps, user data — as cached
The prefix never matches, so every request pays the write premium and reads nothing. The cache line becomes a surcharge, not a saving. Stems pair this with a near-zero hit rate; the keyed answer reorders content, not the cache configuration.
Offering 'enable caching' as the answer to window overflow or quality problems
Caching is a cost-and-latency instrument for repeated prefixes. The window is owned by curation and compaction (objective 2.4), and quality by prompt and model design (2.2, 2.3). Cache-as-cure-all is a planted distractor.
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.
Stuffing 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, and bundled resources cost nothing until read — the monolithic dump pays for procedures the request never touches.
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 collapsing 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 cascades from the first changed token. 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 is arithmetic, not faith — 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 compounds with caching — common prefixes across features multiply the read discount.
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, trigger-bearing description — and outline body, resources, and scripts
Why: The placement rule is the exam item: 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 collapsing hit rate
Why: A silently broken cache looks like a working system with a bigger bill. The usage field is the ground truth.
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