Caching a Shared Case Study Brief Across Draft and Review Calls

You cannot decide whether caching is worth the engineering until you know two numbers: how big the shared block is, and how many calls will read it before it changes.

Consider a realistic brief. A style guide of 1,200 words, claim rules of 600 words, and twelve approved quotes averaging 80 words each comes to roughly 2,760 words. Using the common rule of thumb of about 100 tokens per 75 English words, that is roughly 3,700 tokens (Silicon Data). Add a task framing of 300 tokens and the shared block lands near 4,000 tokens.

Now the chain. A typical workflow is one draft call, two or three review calls (factual, editorial, legal), and one or two rewrites. Call it five calls per case study, and a team producing ten case studies a month. That is 50 calls reading a 4,000-token prefix.

At a base input price of $3 per million tokens (the figure in one worked Anthropic example), 50 uncached reads of that prefix cost about $0.60. Cached, with one write at a 25 percent premium and 49 reads at one tenth of base, the same stable prefix costs roughly $0.08 before storage (AgenticWire). The saving is real but small in absolute dollars.

That is the honest insight most caching guides skip: for a low-volume case study program, caching is not primarily a cost play. It is a latency and consistency play. Cached prefixes cut time to first token sharply because the expensive prefill is skipped, while generation speed stays the same (Michael Hannecke). A reviewer waiting on a 4,000-token preamble feels the difference more than finance does.

The decision rule: cache when the shared block is long, the call count per brief is three or more, and the block changes less often than it is read. Skip caching when the brief is short, when you are doing a single one-shot generation, or when the "shared" block is actually customized per client on every call.

The same prefix serves all three steps, but the suffix changes shape. Here is what each call looks like once the boundary is fixed.

Draft call. The prefix is unchanged. The suffix is the interview notes, usage data and outcome numbers, and the instruction "produce a first draft following the style guide, using only the approved quotes in section 4."

Review call. Prefix unchanged. Suffix is the draft plus "flag every sentence that states a metric or a quote not present in the approved block, and every construction banned by the style guide."

Rewrite call. Prefix unchanged. Suffix is the draft plus the review findings plus "apply the flagged corrections; do not introduce new claims."

The draft, review and rewrite differ only after the boundary, so every call after the first is a cache read on the shared block. That is the entire design.

The prep that makes reviews meaningful is worth doing before you ever call the model. Pull the customer's usage metrics, seat adoption and features actually used daily before the interview, so the draft can go deep instead of staying shallow (CaseLeap). Then document the onboarding timeline with concrete dates: contract signed, first login, first measurable result, full rollout (CaseLeap). Those facts belong in the per-call suffix, not the prefix, because they differ per customer.

A sketch of the call structure:

shared_prefix = task_framing + STYLE_GUIDE + CLAIM_RULES + APPROVED_QUOTES  # v3

def call(step_instruction, working_text):
    return client.complete(
        system=[
            {"type": "text", "text": shared_prefix, "cache_control": {"type": "ephemeral"}},
        ],
        messages=[
            {"role": "user", "content": step_instruction + "\n\n" + working_text},
        ],
    )

The exact marker syntax differs by provider; some match eligible prefixes automatically while others require explicit cache markers (AgenticWire). What matters is that the shared block is assembled once, from versioned parts, and never string-concatenated with anything dynamic.

One subtlety: put the task framing first and the quotes last within the prefix. If the task framing changes (say you add a "review only, do not rewrite" mode), you want that change to invalidate as little as possible. Ordering within the prefix should follow the same stability logic as the prefix itself.

This is where chains break. Suppose a reviewer notices a quote was misattributed, or legal withdraws a claim rule, in the middle of a five-call chain. Someone edits section 4. What survives?

Under exact prefix matching, the cache is keyed on the literal token sequence, so a single changed character before the boundary breaks the hit (Digital Applied). Edit the approved quotes and every token from that point onward is recomputed: the rest of the quotes, the task framing that follows if you ordered it badly, and the entire suffix.

The table below is the checklist to run when the shared block changes mid-run.

The second row is the interesting one because it shows the limit of granularity. If you have not versioned the quotes individually, a correction to quote nine doesn't let you keep quotes one through eight cached unless the edit genuinely leaves their bytes untouched. That is why the version stamp should describe the whole block, not individual sections, unless you are willing to run separate cache markers per section.

The sequencing that works: freeze the shared block, run the chain, collect every proposed edit, apply them all at once at the end, bump the version, and rerun the whole chain. That way the first call of the rerun pays the write premium once and the rest read. If instead you trickle edits in one at a time, you pay a fresh write on every edit and collect almost no reads. Below roughly a 30 percent hit rate on a stable-prompt workload, the write premium can cost more than the reads save (Digital Applied).

A worked version of the arithmetic, using the earlier 4,000-token block and 50 calls: one clean run with one write and 49 reads costs about $0.08. The same 50 calls with five mid-run edits means six writes and 44 reads, roughly $0.13, plus five chains restarted from scratch. Same tokens, 60 percent more for the prefix, and five times the wall-clock time. Batching edits is not just tidy, it is cheaper.

Turn the rule into a workflow with named stages.

Stage one, freeze. Assemble the block from versioned parts and compute a hash of the exact bytes. Store the hash with every call you make, so you can later tell whether a hit was even possible. Teams that skip this step cannot explain why their hit rate is low.

Stage two, run. Execute draft, review and rewrite against the frozen hash. Every call after the first should read the prefix.

Stage three, collect. Do not touch the shared block while the chain runs. Queue every proposed edit in a single list: quote corrections, rule changes, style tweaks.

Stage four, apply and bump. Review the queue as a batch, apply all accepted edits at once, increment the block version (for example from v3 to v4), and record what changed and why. This is the same discipline you would apply to any shared document in a regulated chain: the case study depends on measurable results and personal quotes that stand up to scrutiny (Weber Associates), and a change log is how you defend both.

Stage five, rerun. Rerun the chain from the draft step against v4. The first call writes the new prefix; the remaining calls read it.

Two governing rules fall out of this. First, edits are batched, never trickled. Second, the suffix is where iteration happens. Every round of "make the intro shorter" or "tighten the close" touches only the per-call instruction and the draft, so it never triggers a prefix rebuild at all. Most iteration in a real case study program is suffix work, which is why a well-placed boundary saves more than the cost math alone suggests.

If your briefs are structured this way and you would rather not maintain the cache-marker plumbing across providers yourself, Quanta Inference offers text, image and embedding models through one OpenAI-compatible API key, so the shared block can be assembled and reused the same way regardless of which model handles the draft versus the review: Quanta Inference.

Run this before you spend a token.

• The style guide, claim rules and approved quotes are assembled as one string, in that order, from versioned parts.
• A hash of the exact block bytes is stored with every call record.
• The per-call instruction and the working text are appended after the block, never concatenated into it.
• Quotes carry attribution and an approval date.
• Proposed edits are queued, not applied, while a chain is running.
• The block version appears in the output so a reviewer can tell which rules a draft was built against.
• You have measured your actual hit rate rather than assumed it.

That last point is the one teams most often skip. A hit rate below 60 percent on a stable prompt signals a structural problem, not bad luck (Digital Applied). The usual culprit is dynamic content that crept into the prefix, exactly the mistake of putting long per-user data at the end of the system prompt rather than the end of the message (Sankalp).