Caching and memory solve different problems
A provider's prompt cache may reduce repeated processing of a stable prefix. It is not the workspace's durable record of a skill, a conversation, or an external action. Keep those records in the application and treat provider caching as an optimization with its own contract.
Preserve stable context where possible
Instructions and tool schemas that do not change between turns are natural candidates for a stable request prefix. Task-specific messages and tool results change more often. Ordering these deliberately makes a request easier to inspect as well as easier to compare across experiments.
Keep authorization fresh
A previously assembled context does not prove a person still has access to a workspace or connection. Recheck authorization at the tool boundary. Do not use a cached model prompt as the source of truth for permission, billing balance, or revocation.
Measure the actual provider behavior
Caching rules, accounting, and supported model routes depend on the provider. Inspect its current documentation and the usage actually returned. A lower token count in one example does not establish a reliable cost reduction for every workflow.
Avoid overstating implementation claims
Spinrun resolves models through a shared model layer and keeps durable task state in its runtime. This note explains an architectural consideration; it does not claim a particular cache-hit rate or saving. Such a result needs a measured workload, date, and reproducible configuration.
Review changes with the whole workflow
Compare useful outputs and external actions as well as request cost. A context optimization that drops a required instruction or source can be cheaper while making the work less reliable. Keep the review rubric and representative task set constant.