A municipal finance bot reuses the same chart-of-accounts instructions across departments. Which caching practice fits?

Municipal finance bots that reuse the same chart-of-accounts instructions across departments should use cache checkpoints for that shared instruction block. Prompt caching and checkpoint patterns fit because the chart-of-accounts guidance is large, stable, and identical across bureau calls: caching it reduces repeated token cost and latency while preserving consistent account labeling for every department that shares the policy text. The variable portion of each request (department question, period, or attachment) stays uncached or separately scoped so answers remain specific.

Creating separate cache checkpoints per department for the identical instruction block fails by concept: the chart-of-accounts text is byte-for-byte the same across bureaus, so splitting it into department-specific checkpoints multiplies storage and cache-write cost for content that should hit one shared cache entry instead. Positioning the cache checkpoint after department variables to reuse tailored budget outputs across sessions fails by concept: prompt caching matches an identical prefix, so putting the checkpoint after the variable, department-specific part guarantees a cache miss on nearly every call—the cacheable boundary has to sit at the end of the stable, shared instruction text, not after the part that changes. Refreshing the cached chart-of-accounts block frequently to capture minor updates fails by concept: caching is meant to exploit a stable instruction block, and refreshing it on a short clock for minor edits defeats the cache by forcing repeated full-cost writes, while still risking departments running on a half-updated version mid-refresh.

Exam caveat: cached civic policy must still be versioned—when the chart of accounts changes, invalidate or bump the cache key so departments do not silently run on obsolete account rules—and caching does not authorize broader data access than the caller already has. Operational check: issue two Messages API calls from different department clients that share the same chart-of-accounts block with caching enabled, confirm cache hit metrics for the shared prefix, then change the instruction version and verify subsequent calls miss until the new checkpoint is established.