Expose prompt_cache_key for independent codex exec sessions
What variant of Codex are you using?
CLI, IDE, App, custom automation with exec
What feature would you like to see?
Problem
Fresh codex exec sessions use their thread ID as the Responses API prompt_cache_key. That makes it hard to get cache reuse across independent sessions that share the same long instructions.
Reproduction
I tested a local patch on commit f774455c3a831dfab2c6f37a1f624b8097f6f2c2 that allowed a fixed cache key across fresh threads.
Setup:
- Model:
gpt-5.5 - Static instructions: synthetic public prompt, 62,639 chars
- Each run used a fresh thread
- Each run had 18,362 input tokens
- All runs exited successfully and returned the expected output
| Run | Key / prefix condition | Cached tokens | Cached ratio |
|---|---|---:|---:|
| U1 | Default thread key, same prompt prefix | 2,432 | 13.2% |
| U2 | Default thread key, same prompt prefix | 4,992 | 27.2% |
| K1 | Same fixed key K, same prompt prefix | 2,432 | 13.2% |
| K2 | Same fixed key K, same prompt prefix | 18,304 | 99.7% |
| J1 | Different fixed key J, same prompt prefix | 5,504 | 30.0% |
| K3 | Same fixed key K, same prompt prefix | 5,504 | 30.0% |
| P1 | Same fixed key K, changed prompt prefix | 2,432 | 13.2% |
| K4 | Same fixed key K, same prompt prefix | 2,432 | 13.2% |
The fixed key produced one near-complete cross-thread cache hit, but later fixed-key runs were inconsistent.
Root-cause hypothesis
Using the thread ID as the default cache key prevents callers from intentionally grouping independent codex exec sessions that share the same long prompt prefix.
A caller-provided stable key appears to help routing, but the behavior is not predictable enough from the CLI today.
Suggested direction
Expose prompt_cache_key as a supported CLI or config option for codex exec, while keeping the thread ID as the default.
It would also help to document the expected behavior and expose enough diagnostics to confirm which effective cache key was used.
Happy to submit the focused patch and tests if invited.
Additional information
_No response_