Skip to content

[FEATURE]: Enable OpenAI prompt caching by setting prompt_cache_key for GPT-5.6+ #43689

Closed

Description

@yue-arch

Problem

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.

OpenAI's Caching Requirements

From OpenAI's docs:

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.

Key parameters:

  • prompt_cache_key: String identifier (e.g., session ID) - required for reliable caching
  • prompt_cache_options.mode: "implicit" (default) or "explicit"
  • prompt_cache_options.ttl: Cache lifetime (default "30m")

Current State

OpenCode already:

  • ✅ Tracks cache tokens from OpenAI responses (cached_tokens, cache_write_tokens)
  • ✅ Has a cacheKey option in the provider interface
  • ❌ Does NOT pass prompt_cache_key to OpenAI API requests

Proposed Solution

Set prompt_cache_key to the session ID for OpenAI GPT-5.6+ requests:

{
  "model": "gpt-5.6",
  "prompt_cache_key": "ses_abc123...",
  "messages": [...]
}

This would:

  1. Enable reliable prompt caching for long sessions
  2. Dramatically reduce costs (cached tokens are billed at 0.1× the uncached rate)
  3. Reduce latency for repeated context

Configuration Options

Could be exposed as a provider-level or global config option:

{
  "provider": {
    "openai": {
      "promptCache": true  // or "auto" | "off"
    }
  }
}

Or enabled by default for supported models (GPT-5.6+).

Workaround

Currently none. The opencode-cache-injector plugin exists but only works for Claude API proxies, not native OpenAI.

Environment

  • OpenCode version: latest
  • Models affected: GPT-5.6, GPT-5.5, GPT-5.4, GPT-5.2, GPT-5.1, GPT-5, GPT-4.1 (all models supporting prompt_cache_key)

Activity

  1. github-actions commented on Aug 20, 2026

    @github-actions
    Contributor

    This issue might be a duplicate of existing issues. Please check:

    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.

  2. mrchi commented on Aug 25, 2026

    @mrchi

    @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.

    before
    Image

    after

    Image
  3. neriousy commented on Oct 19, 2026

    @neriousy
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions