Choose between caching, components, Skills, and system prompts

Learning objective

Choose among caching, modular prompts, Skills, and always-loaded instructions by reuse pattern, change frequency, context cost, and governance.

Core idea

Universal guidance needs a persistent instruction surface; specialized procedures need selective loading. The professional decision adds two independent questions: who maintains shared text, and whether repeated processing is worth caching.

These options can compose. A versioned prompt component can supply always-loaded system instructions and form a cached prefix, while a Skill supplies a procedure only to relevant tasks. Choose each for the responsibility it performs rather than naming one option the organization’s universal reuse strategy.

How it works

Classify the reuse requirement

Start with the artifact that repeats. Identical API prefixes create a processing-reuse opportunity for cache_control; duplicated instruction source creates a maintenance problem for versioned components; a specialized workflow with references or scripts creates a packaging problem for Skills. A requirement that every request must receive creates an instruction-loading requirement for system or the appropriate Claude Code project instruction file.

Use this comparison to defend the decision:

Mechanics and pricing belong to 2.5.1, component release design to 2.5.2, and cross-surface Skill delivery to 2.5.3. Here, use their measured consequences to select a combination.

Separate change cadence from relevance

Frequently changing text is not automatically unsuitable for caching. A prefix updated every hour can still receive hundreds of matching reads between updates. Conversely, a quarterly policy that appears only once daily may not justify a cache write for that traffic pattern. Compare requests per unchanged prefix and the intervals between them, rather than saying “stable documents should be cached.”

A rarely invoked procedure can still require strict release governance. Its Skill may contain sensitive pricing logic or scripts, even though most sessions never load the body. API pinning through container.skills[].version protects the reviewed version from unrelated uploads; source-control releases perform the corresponding responsibility for project Skill files. The trigger frequency does not determine the review requirement.

Modularization follows ownership and reuse, not elapsed time alone. If marketing updates wording quarterly and operations changes process weekly, separate components can make their releases explicit. If one use case needs both on every call, those components remain included regardless of their different cadences. Conditional inclusion must follow task relevance, not an attempt to hide frequently edited instructions.

Budget for required and optional context

Distinguish required baseline instructions from a complete procedure library. The Claude API’s system field supplies baseline instructions for the request; the application must include the intended version on each call. In Claude Code, project CLAUDE.md provides the analogous persistent guidance for its scope. Neither prose surface constitutes enforced configuration.

Then measure the optional material actually used. Anthropic’s Skill architecture keeps discovery metadata available and loads instructions and resources when needed. That makes a Skill appropriate when many requests need none of a large reference library. It still carries discovery cost and loading behavior to evaluate, and it introduces a runtime requirement on the API. Avoid comparing it with caching as though both remove the same tokens: cached input remains in the prompt, while selective loading can avoid irrelevant input.

Do not shorten universal requirements merely to reach a token budget. First remove repetition through a shared component and exclude task-specific content from the universal core. Then test whether the resulting request still satisfies the success criteria. Cache eligible repeated processing after that composition is defensible, rather than using cheaper reads to justify loading every possible instruction.

Assign acceptance and operation

Record a decision for each content family: its owner, inclusion surface, release identifier, supported runtime, expected reuse, and acceptance measure. For cached policy components, measure writes and reads by deployed composition; for Skills, evaluate trigger accuracy, output quality, and coexistence. Anthropic’s enterprise guidance recommends an internal Skill registry with purpose, owner, version, dependencies, and evaluation status, which gives the package part of this decision a concrete home.

Keep promotion responsibilities explicit. The policy owner approves meaning; the application owner decides which prompt composition to ship; the Skill reviewer approves executable resources; the platform owner verifies the resulting deployment. When several options combine, no single cache-hit percentage demonstrates that all these responsibilities succeeded.

A retention constraint can rule out a combination before economics are considered. Anthropic documents prompt caching as ZDR-eligible and Agent Skills as outside ZDR arrangements. Do not transfer the caching designation to a workflow merely because it also contains a cache breakpoint. The organization’s data-governance owners must accept the selected surfaces and their documented handling.

Key distinctions and trade-offs

Caching versus modularity: Caching can make repeated stale instructions cheaper. Modularity controls which instructions are released. A cost target cannot establish correctness.

Skills versus universal inclusion: Skill relevance is useful for optional expertise. Requirements governing every request must arrive independently of whether the procedure triggers.

Review frequency versus use frequency: A seldom-used executable package still needs review; a heavily used unchanged prefix may offer excellent caching economics.

Choose the smallest composition that satisfies the task and gives each shared artifact an accountable owner. Add a reuse mechanism when its measured benefit pays for its own operational responsibility.

Architecture / decision scenario

An education company supports 12,000 tutor requests daily. Every request needs an 800-token teaching policy; only 4% need a 15,000-token examination-design procedure. Eight subjects share policy wording, while subject examples change independently. The content director proposes one always-loaded document containing everything, cached to make its size affordable.

The architect compares that proposal with a combined design. The full procedure would appear unnecessarily on 96% of requests, even if its processing were discounted. The architect keeps the teaching policy in system and releases it as one versioned component shared across the eight subject compositions. The deployment uses Sonnet 5.5 on the Claude API, so the 800-token policy clears its 512-token cache minimum. At steady load, 12,000 daily requests average about eight per minute; the team confirms that each unchanged composition repeats within five minutes, selects the default five-minute lifetime, and checks usage.cache_creation_input_tokens and usage.cache_read_input_tokens per composition using 2.5.1. Subject examples remain separately owned components; a policy change triggers evaluations for every consumer.

The examination-design procedure becomes a pinned API Skill with references loaded for qualifying requests and the required code execution tool. Its 4% trigger rate supports selective loading, but the team still evaluates missed triggers and conflicts with other attached Skills. Universal teaching requirements stay independent of the procedure’s activation.

The content director approves policy and educational output criteria, platform engineering owns assembly and cache accounting, and the procedure reviewer owns its scripts and references. The team’s data-governance owner checks Skills retention before accepting the design. This choice addresses shared wording, processing cost, optional context, and package governance through separate accountable decisions.

Common exam traps

• Selecting caching to fix inconsistent copies of policy text.
• Calling modules cheaper without reducing included content or using caching.
• Loading every procedure because cache reads are inexpensive.
• Moving universal requirements behind Skill relevance matching.
• Treating a ZDR-eligible cache as proof that attached Skills have the same status.

What to remember

Select by what repeats: processing, source text, specialized procedure, or universal guidance. Compare change cadence with real reuse, preserve required context, and assign release and runtime ownership. Combine mechanisms when the workload needs their different benefits.

Knowledge check

References

• Anthropic, Prompt caching
• Anthropic, Agent Skills
• Anthropic, Using Skills with the API
• Anthropic, Skills for enterprise
• Anthropic, How Claude remembers your project