Summary

conversation-field-updates.ts (crm-updater), updateNextStepsAndTasksTool.ts (next-steps), and strategist-updates.ts (strategist) each build a manual "3-layer cached message" with two cache_control breakpoints: the triggering event's raw content first, then the (mostly stable, per-user) preamble/hydrated-context block, then an uncached task prompt.

Anthropic's prompt cache is prefix-based: a cache_control breakpoint only hits if the entire request content before it matches a previously cached prefix, byte for byte. Because the event-content block is a fresh email/meeting/Slack message on every call, it's never identical across runs , which meant the preamble/context breakpoint that came after it could never accumulate a cross-run cache hit either, since its cached prefix always included that call's unique event text.

Confirmed against real production billing/trace data via the understudy CLI: these three workloads showed cache-write dollars exceeding cache-read dollars by 1.9x,5.3x over a 6-day window (write should be small relative to read for healthy reuse), while a sibling workload with a stable-content-first order did much better.

The fix: reorder each generateInput so the stable block (preamble / hydratedContextBlock) comes first and keeps its cache_control marker. The event-content block's cache_control is removed , it's write-once-read-never regardless of position, so marking it cacheable only paid Anthropic's 1.25x cache-write markup for zero benefit , and it's merged into the uncached tail together with the existing task prompt. Same text, same order, no behavior change to what the model sees; only cache eligibility changes.

Where cache_control was removed from

In each case it's now merged uncached into the trailing block with the task prompt, and the block that keeps cache_control (preamble / hydratedContextBlock) moved to the front.

Estimated savings

Derived from real Understudy billing data, not assumed:

• Confirmed actual cache pricing from Cedar's own billed $ and token counts: cache-write ≈ $3.7,3.76/Mtok, cache-read ≈ $0.295,0.301/Mtok , a consistent ~12.5x ratio (matches the standard 1.25x-write / 0.10x-read multipliers off a ~$3/Mtok base input rate).
• Post-migration 6-day cache-write totals: conversation-field-updater $569.08, next-steps-tasks $788.06, strategist-updater $670.54 → combined $2,027.68 / 6 days = $337.95/day.
• Measured volatile/stable byte split per workload (from a real trace): crm-updater & next-steps ≈ 74% volatile (event content) / 26% stable (preamble); strategist ≈ 56% volatile / 44% stable (it bundles more into its hydrated-context block).
• Effect A , dropping cache_control on the volatile block, ~20% off its write cost (1.25x → 1.0x base rate), close to guaranteed with no dependency on traffic patterns: ~$14/day (crm-updater) + $19/day (next-steps) + $13/day (strategist) ≈ $46/day combined (~$1,380/month, ~$16,800/year).
• Effect B , reordering lets the stable block accumulate cross-run cache hits instead of rewriting every time; modeled at 25/50/75% cross-run hit-rate scenarios: ~$25,75/day, ~$50/day midpoint.
• Combined estimate: $70,120/day across these three workloads ($2,100,3,600/month, ~$26k,44k/year) , roughly 13,22% of what these three workloads currently spend, ~6,10% of org-wide daily spend. Not enough alone to hit a 50% overall reduction target; one contributing lever among several.

Effect A is low-risk and close to guaranteed. Effect B is a genuine estimate , confirm actual $ savings via a staged rollout comparing cache-read % before and after, rather than ass