Repository navigation
V2: ChatGPT Token Sharing reports 3.44% prompt-cache reuse in native CLI #53765
Description
Description
OpenCode 2.0.24 reports very low prompt-cache reuse with openai/gpt-6.1-sol (xhigh) through ChatGPT Token Sharing. This was reproduced directly in the native CLI, without SuperOne-injected instructions or tools.
One coding session on 2026-10-07 (14:46–15:01 UTC) recorded:
| Metric | Value |
|---|---|
| Metered ordinary assistant calls | 23 |
| Total input tokens | 2,798,660 |
| Cache-read tokens | 96,256 |
| Uncached input tokens | 2,702,404 |
| Token-weighted cache-read share | 3.44% |
| Calls with zero cache reads | 14 / 23 |
| Maximum input in one call | 193,179 |
| Compaction messages | 0 |
All 14 zero-cache calls started less than five minutes after the preceding call. Several started immediately after its completion. Consecutive examples:
| Call | Total input | Cache read | Gap between request starts |
|---|---|---|---|
| 10 | 123,835 | 79,872 | 21.25 s |
| 11 | 141,418 | 0 | 15.09 s |
| 12 | 143,579 | 0 | 22.54 s |
| 13 | 145,308 | 2,048 | 13.30 s |
These figures were verified from session_message assistant records in the local database. OpenCode's tokens.input is uncached input; total input here is tokens.input + tokens.cache.read + tokens.cache.write. Cache-write tokens were zero throughout. The percentage is computed from summed tokens, not averaged per-call percentages.
Steps to reproduce
- Use OpenCode 2.0.24 with the built-in ChatGPT Token Sharing login.
- Start a fresh native CLI session with
openai/gpt-6.1-sol, variantxhigh. - Run a coding task with multiple tool-use/model turns and follow-up messages.
- Compare total input and
tokens.cache.readacross consecutive ordinary assistant records.
This describes the observed reproduction; it has not yet been reduced to a deterministic minimal prompt. Existing project/user configuration was retained.
Expected behavior / investigation
Repeated turns should reuse eligible unchanged prompt prefixes. The frequent full misses cause substantial repeated uncached input, but the underlying cause is not established: final outbound request bodies were not captured. Could you check request-prefix stability, cache-key/routing behavior on the Token Sharing path, and whether cache-read usage is being reported correctly?
Related: #52761 concerns summary-compaction cache misses. This report concerns ordinary assistant calls in a session with no compaction. These token counts do not establish a formula for subscription quota consumption.
Environment
- OpenCode: 2.0.24
- Provider/auth: built-in
openai, ChatGPT Token Sharing - Model/variant:
gpt-6.1-sol/xhigh - OS: macOS 27.0.1
- Client: native OpenCode CLI
Activity
github-actions commentedon Oct 7, 2026
This issue might be related to existing issues. Please check:
opencode-agent commentedon Oct 7, 2026
Thanks for the detailed numbers. Prompt-cache reuse is decided by OpenAI's servers and depends on a real ChatGPT Token Sharing login, so we can't reproduce this in our sandbox, which has no provider account. A maintainer with a Token Sharing account will need to capture the outgoing requests.
One lead from reading the 2.0.24 code, not yet verified: the built-in
openaiplugin adds thesession-idheader (used for ChatGPT prompt-cache routing) only for the Codex browser/headless login methods. The Token Sharing method doesn't seem to add it. Its requests still includeprompt_cache_keyand the generic session headers. Whether this explains the misses still needs to be confirmed with real requests.If you can capture one or two consecutive outgoing request bodies and headers (for example through a local proxy) for a cache-miss pair like calls 10 → 11, that would help a lot.
neriousy commentedon Oct 7, 2026
edit: nevermind, something is seriously wrong - investigating
rekram1-node commentedon Oct 7, 2026
hmm this wasnt documented, it seems like these additional headers increase cache hits tho so adding them.
rekram1-node commentedon Oct 8, 2026
the header additions are in the latest release, also notified openai team about this, nothing else we can do on our end
closing since in my testing it seems to be fixed? if not just lmk and we can reopen
ill keep u posted with what they tell me
A ChatGPT plan's requests name their session by Codex's session headers