Hook
Cached context is not just a speed trick. It is part of the system that thinks with you.
That makes it useful. It also makes it dangerous when it gets stale, private, or too authoritative.
The Problem
Modern agent sessions are not made only from the latest user message. They can carry standing instructions, memory summaries, repository guides, tool schemas, prior session summaries, retrieved files, compacted transcripts, and old proof routes. Some of that material is cached by the application or provider. Some is reintroduced by local memory. Some comes from the repo itself.
When the context is right, the agent feels wonderfully oriented. It remembers the vocabulary, the proof command, the claim boundary, the style preference, and the place where previous work left off.
When the context is wrong, it can quietly steer the work from behind the curtain. A memory can point to yesterday's branch state. A session summary can preserve a count that has drifted. A tool instruction can describe an interface that has changed. A prior decision can be treated as current authority even though it was only a historical note.
The issue is not that cached context exists. The issue is that it can become hidden infrastructure without infrastructure discipline.
The Idea
Treat cached context as a governed development surface.
That means every important cache class should have provenance, freshness, authority, invalidation, privacy, and claim-ceiling rules. The agent can use memory and reused context to know where to look. It should not use them as a substitute for live proof when the current claim can drift.
Cache may orient. Cache may suggest a proof route. Cache may preserve user preferences. Cache may point to source artifacts. Cache should not approve current claims, replace live file or ref inspection, or override current instructions.
What We Saw
The source manuscript inherits the aggregate-only boundary from A Longitudinal Corpus of Human-Codex Software Work. The local snapshot reported 7,514 session files, 7,183 sessions with token information, 331 without token information, 174,068 token-count events, and 2,060 null token-count events.
It also reported a large cached-input surface: 20,704,900,411 input tokens and 19,684,191,488 cached input tokens. Those figures are local and private. They are not billing evidence, productivity evidence, or model-quality evidence. They are a scale signal. In this workflow, cached context was large enough that stale or over-authoritative cache would matter operationally.
That is the useful lesson. If reused context dominates the working surface, then we should be able to ask what kind of reused context it is and what authority it carries.
Why It Matters
Caching changes the feel of agent work. A good memory can make a model seem experienced rather than forgetful. It can prevent repeated orientation and keep the work moving.
But there is a difference between memory as route and memory as truth.
Memory as route says: this may be the right place to inspect.
Memory as truth says: this is still current.
Only live checks can answer the second question when the fact is drift-prone. Repo state, branch alignment, proof status, package counts, review decisions, publication posture, API behavior, and external documentation can all change. For those, cached context should trigger verification rather than replace it.
A cache record does not need to be ornate. It needs the right fields:
- where the context came from;
- when it was last verified;
- what authority it carries;
- which workflows it applies to;
- what invalidates it;
- what privacy class it belongs to;
- what claim it can support by itself.
That last field is the pressure release. Most cached context should support orientation, not current authority.
What This Does Not Prove
This post does not claim that cached input caused any particular result. It does not claim that more cache is good, bad, cheaper, or more productive. It does not claim that the local aggregate represents other users, products, models, or teams.
It also does not publish raw logs, raw memory contents, transcript bodies, private paths, or row-level examples. Those remain held by default unless a separate release decision approves an exact sample.
The claim is narrower: in long-running agent work, cached context is important enough to govern as infrastructure, and weak enough that it should not replace live verification.
Where To Go Deeper
Read the source manuscript: Cached Context Infrastructure: Treating Reused Agent Context as a Governed Development Surface by A.G. Mauro and C.A. Harris.
Related archive work: A Longitudinal Corpus of Human-Codex Software Work, Proof-Carrying Development, Metrics Are Not Authority, and Tool Calls Are the Medium.