You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE]: Enable OpenAI prompt caching by setting prompt_cache_key for GPT-5.6+ #43689
OpenAI GPT-5.6+ supports prompt caching, but it requires setting prompt_cache_key in API requests for reliable cache matching. Without this, users pay full input token costs on every message, even in long sessions where the context is largely unchanged.
Real-world impact: In a 1 hour window of a 32-hour session using GPT-5.6, I spent ~$700. The session data shows cache_read: null and cache_write: null for all OpenAI messages, meaning zero caching occurred. Switching to Claude mid-session immediately showed cache hits (173M tokens read from cache) because Anthropic's caching works automatically.
For GPT-5.6, you must set prompt_cache_key to use the more reliable matching for both implicit and explicit caching. At each breakpoint, the service matches the key with the exact prompt prefix. Without a key, requests may still receive automatic cache hits, but they do not use the improved matching.
Please review those issues and consider whether your request is already covered. If so, adding a comment there with your additional context (especially the real-world cost data) would be very helpful.
@jlongster Hi, I'm also experiencing the issue where caching doesn't work for GPT series models. I'd like to add some additional information.
I set the option setCacheKey to true, then captured the requests sent by opencode. I sent two consecutive requests and checked the cache hit status of the second request.
I found that when opencode sends a request, the value of the prompt_cache_key field is a string like ses_xxxx. However, when codex sends a request, prompt_cache_key uses a UUID.
So I replayed the request, changed prompt_cache_key to UUID4 format, and this time the cache hit successfully.
Therefore, I believe the root cause of the issue lies in the format of prompt_cache_key when opencode sends model requests. Changing it to a UUID might solve the problem.
This is addressed in v2: OpenAI Responses requests include a session-affinity prompt_cache_key by default, unless caching is disabled or the model explicitly rejects that field. This enables cache matching but does not guarantee a cache hit for every request. Upgrade with npm i -g @opencode/cli@latest. If you still see this on v2, please open a new issue with the details.
Activity
github-actions commentedon Aug 20, 2026
This issue might be a duplicate of existing issues. Please check:
prompt_cache_keymechanismPlease review those issues and consider whether your request is already covered. If so, adding a comment there with your additional context (especially the real-world cost data) would be very helpful.
mrchi commentedon Aug 25, 2026
@jlongster Hi, I'm also experiencing the issue where caching doesn't work for GPT series models. I'd like to add some additional information.
I set the option
setCacheKeyto true, then captured the requests sent by opencode. I sent two consecutive requests and checked the cache hit status of the second request.I found that when opencode sends a request, the value of the
prompt_cache_keyfield is a string likeses_xxxx. However, when codex sends a request,prompt_cache_keyuses a UUID.So I replayed the request, changed
prompt_cache_keyto UUID4 format, and this time the cache hit successfully.Therefore, I believe the root cause of the issue lies in the format of
prompt_cache_keywhen opencode sends model requests. Changing it to a UUID might solve the problem.before

after
neriousy commentedon Oct 19, 2026
This is addressed in v2: OpenAI Responses requests include a session-affinity
prompt_cache_keyby default, unless caching is disabled or the model explicitly rejects that field. This enables cache matching but does not guarantee a cache hit for every request. Upgrade withnpm i -g @opencode/cli@latest. If you still see this on v2, please open a new issue with the details.