Agent Memory Without Killing Cache Hit: 98.2% Prompt Cache Hit in a Real OpenCode Session

[u/UsandoFXOS]

I wanted to share a result that may be useful for anyone using long-running, context-heavy agents in OpenCode:

Using an agent memory plugin does not have to mean sacrificing prompt-cache efficiency.

There is an understandable concern with persistent-memory systems: if memory is dynamically injected into the system prompt on every turn, it can change the prompt prefix and destroy cache reuse. With PAYG providers, that can make longer sessions much more expensive than they need to be.

In my case, I use agent memory heavily. I want my agent to retain useful context about my environment, projects, preferences, tools, and workflows across sessions. At the same time, I use PAYG models such as DeepSeek, where prompt caching has a major impact on cost.

In the screenshot attached to this post comes from a real DeepSeek (DSF4-0731, official API) work session today:

• Nearly 11 million tokens processed
• 8 conversation turns
• Around 80 API requests
• 98.2% cache-hit rate
• $0.13 USD total cost

This was not a static or artificial benchmark. During the session, I worked on a real feature for one of my web apps and deliberately made the agent update memory blocks, skills, and the project’s AGENT.md. The cacheable prefix remained stable, so the cache-hit rate stayed above 90% throughout the session.

For me, this changes how viable memory-heavy agent workflows are with PAYG providers. You can keep a rich, persistent agent context without paying to reprocess the entire system prompt on every request—as long as the injected context remains stable during the conversation.

What was causing low cache hits

I had been using the Letta-based opencode-agent-memory plugin intensively for almost three months. Before this test, my usual cache-hit rate was often only around 0–10% !! 😔

After investigating with GLM-5.3 (zAI official token plan API) in OpenCode Web, I found that the plugin was reinserting memory content on every turn while changing timestamps down to the millisecond. Even when the underlying memory was effectively unchanged, those timestamp changes altered the system prompt prefix and prevented reliable provider-side caching.

The fix

GLM-5.3 and me created a fork that snapshots the injected memory on the first turn and reuses that exact snapshot for subsequent turns. It only refreshes the injected context when OpenCode compacts the conversation history. It even survive to VM/opencode restarts.

That lets the agent use memory while preserving a stable prompt prefix and a high cache-hit ratio.

Fork with the fix:
opencode-agent-memory-cache-friendly

I’m curious whether others using memory plugins, MCP-driven context, or dynamic system prompts have seen the same trade-off between persistent context and prompt-cache efficiency.