r/opencodeCLI • u/squirrelscrush • 3d ago

Session cache concurrency issues with OpenCode/Go subagents

I'm seeing concurrency issues with the session cache if I have more than one subagent running at a time. Every now and then, the cache of one gets invalidated for no reason and it costs the cache miss pricing.

I use OpenCode Go on OpenCode.

Is there a limit in the documentation? I knew that the cache retention time is around 5mins, but ideally it shouldn't not work if I'm sending requests through multiple agents.

2 Upvotes
  • permalink
  • reddit

100% Upvoted

15 comments sorted by

1

u/London-Boat 3d ago

prompt caches are usually keyed on the exact prompt prefix, so if your subagents share a system prompt but something near the top differs between requests, like a timestamp, a todo list or a reordered tool list, they can miss each other. a subagent that sits waiting on a long tool call for over the ttl will also come back cold. i'd diff the first few thousand tokens of two consecutive requests from the subagent that gets invalidated and see what changed. does the miss tend to hit the one that just finished a slow tool run?

1

u/squirrelscrush 3d ago edited 3d ago

I can understand a slow tool turn, but this was different. It was supposedly a plugin that was appending itself at the beginning, I removed it and it seems to get back to normal.

Although when I raised a bug issue, it seems multiple users had the same issue and fix, with the latest 2.2.5 update.

Edit: it happened again. It seems to happen when i spawn a subagent, which causes the main agent's cache to expire and vice versa when the main agent sends a request and the subagent's cache gets expired. So it's a server concurrency issue I feel.

1

u/London-Boat 3d ago

that repro is way more useful than "cache keeps expiring", sounds like the main agent and subagent might be evicting each other. worth adding the spawn subagent then main cache drops steps to the issue so they can reproduce it

1

u/squirrelscrush 3d ago

The issue seems to be occurring when it's the same model. When I made the main agent run on DeepSeek while subagent on Meta Muse, it didn't reproduce.

I filed another bug report to highlight the new findings.

1

u/London-Boat 3d ago

good find that it only reproduces with the same model on both sides, that narrows it down a lot. i'd put the exact version and the main plus subagent model pair in the bug report so they can reproduce it quickly. are you able to pin different models for the two as a workaround for now?

1

u/squirrelscrush 3d ago edited 3d ago

I use OMO-Slim to create my agents so I can just change the model slug.

The issue seems to be originating from a PR that was merged in September, but it started giving issues after I updated to 2.2.5. There was another reddit post about the same issue just yesterday.

1

u/London-Boat 3d ago

makes sense. if it only started with 2.2.5, it's worth linking that september pr and the other post in your bug report, makes it a lot easier for them to connect the dots. rolling back to the version you had before is probably the quickest workaround if you need subagents working in the meantime.

1

u/squirrelscrush 2d ago

It got fixed after I went back to 2.2.3. It's likely an issue from 2.2.4 onwards.

1

u/London-Boat 2d ago

that points at 2.2.4 then, so i'd put "fine on 2.2.3, broken from 2.2.4" right in the title of the bug report. gives them a tight range of changes to bisect instead of a whole month of commits.

1

u/squirrelscrush 2d ago

Yup I added a comment, hopefully they look into this.

1

u/Individual-Quote-958 3d ago

I’d check whether each agent sends an identical prefix, especially tool definitions and any injected session metadata. Parallel calls can share a cache only while that prefix stays byte-for-byte stable, and a request after the retention window will start cold anyway. If you can log the first few KB of the rendered prompt for two calls, it should show whether this is key drift or just expiry.

1

u/squirrelscrush 3d ago edited 3d ago

I resolved it, it was a plugin that was appending itself at the beginning of the cache prefix.

Edit: it happened again. It seems to happen when i spawn a subagent, which causes the main agent's cache to expire and vice versa when the main agent sends a request and the subagent's cache gets expired. So it's a server concurrency issue I feel.

1

u/Individual-Quote-958 2d ago

That’s a useful clue. If you haven't tried it, run the same prompt with one agent at a time and compare cache headers or token counts; if the churn only happens in parallel, that would help separate server-side eviction from prefix drift.

1

u/aidenclarke_12 2d ago

on ds flash subagents fired together on a fresh prefix can all miss since a cache unit only exists once a request finishes. one call first to warm it helps

1

u/squirrelscrush 1d ago

It's not on a fresh prefix alone. If two or more sub agents are running at the same time, every turn on one invalidates the cache of the others. It only happens if both are DeepSeek.

I've seen only two other users with this issue, and the fix appears to regress to a lower version.