The same courthouse reuses one 40-page style guide on every visitor-card turn. Which design lever avoids re-paying and re-waiting for that unchanged prefix?

The courthouse reuses one 40-page style guide on every visitor-card turn, so the same large static prefix is sent repeatedly. Prompt caching for that repeated static prefix is the design lever that avoids re-paying and re-waiting for unchanged tokens on each call. Caching keeps the shared style guide warm so subsequent turns primarily pay for and wait on the variable portion of the request.

Pasting a new copy of the full style guide and paying the full prefix every turn fails because it recreates the cost and latency problem the team already observed. Retraining a new model every morning fails because daily retraining is the wrong lever for a static prompt prefix; it is expensive, slow, and unnecessary when the guide can simply be cached. Dropping the style guide fails because it removes the quality control the cards depend on instead of fixing how the prefix is billed and served.

Exam caveat: prompt caching is an application-design control for repeated static context, distinct from retrieval and distinct from training; practitioner items often contrast these levers. Operational check: mark the style guide as a cacheable static prefix, compare latency and token charges for consecutive visitor-card turns before and after caching, and confirm the guide still applies without being dropped.