How Codex prompt caching behaves when you change settings
Changing the model or reasoning setting can make the next Codex turn reuse less of a long conversation. Six matched tests show what stays warm and what can return.

Codex prompt caching is a prefix-matching system. In a long session, keeping the model and reasoning level stable lets more of the conversation stay on one reusable path. Change either setting and the next request can fall back to a shorter shared prefix. Continue at the new setting and that path warms; return to the earlier setting and the older path may still match.
We observed that pattern in 6 matched setting changes and 5 return sequences using the signed-in Codex CLI. The result supports one operating rule: keep a setting stable when the work allows, and expect the first turn after a change to process more of the conversation again.
What the matched tests showed
We used Codex CLI 0.149.0-alpha.4.3. Each changed turn had a fresh no-change control at the same turn position. All test variables stayed fixed except the model or reasoning level under test.
| Change | Matched runs | No-change control | First changed turn |
|---|---|---|---|
| Medium → High | 2 | 20,224 | 9,984 |
| High → Medium | 1 | 20,224 | 9,984 |
| Luna → Terra | 2 | 20,224 | 9,984 |
| Terra → Luna | 1 | 21,248 | 6,912 |
Every changed turn reused less cached input than its matched control. Five changes reused 10,240 fewer cached tokens. Terra → Luna reused 14,336 fewer.

The controls matter. A before-and-after sequence can become colder for reasons we cannot see, even when the visible setting stays the same. Pairing each change with a fresh run at the same position isolates the setting transition more cleanly.
Why the cache looks like branches
OpenAI’s prompt-caching guide says reuse requires the rendered prefix to match through an eligible breakpoint. It also says that changing a request does not necessarily discard an existing cache entry. A later request can reuse the longest matching prefix it can still find.
The guide names both settings we changed:
- a different model can use different weights and caching behavior;
- changing
reasoning.effortcan change model-side reasoning instructions.
Our clean-room probes showed the layers behind the measurements. Fresh Medium and High sessions both started with 9,984 cached input tokens. One more turn at a stable setting grew the reusable prefix to 13,056. Changing the reasoning level dropped reuse back to 9,984. Repeating the new level raised it to 16,128.
The 9,984-token value was not the conversation. It was the stable Codex prefix available before the conversation grew. Keeping a setting extended one branch above that base. Changing the setting made the next request match a shorter part of the tree.
This is a model of the observed behavior, not a claim about an internal data structure. The CLI reports how much input was reused; it does not expose the server’s cache identity or breakpoint selection.
What happened when we switched back
We ran Luna → Terra → Luna and Terra → Luna → Terra. In both sequences, the first return to the earlier model reused exactly the earlier model-aligned prefix: 20,224 tokens in one direction and 21,248 in the other.

Reasoning-level returns varied. Two of 3 sequences found the earlier prefix on the first return. The third found it on the following turn.
An earlier path can return, but not on a fixed schedule. An unchanged control also became colder once without a visible model or reasoning change, so cache availability and routing remain hidden variables.
What this means for cost
On direct OpenAI API requests, cached input has a lower price than uncached input. Reusing a shorter prefix can therefore make the next request more expensive to process.
These tests used a signed-in Codex subscription, not direct API billing. We cannot convert the token difference into an exact Codex credit or currency charge. We also did not test Claude Code, whose request construction and subscription accounting need a separate experiment.
The practical cost is simpler: after a setting change, more of a long conversation may need to be processed again.
The operating rule
Choose the model and reasoning level before a Codex session becomes large. Keep them stable when the work allows.
When a change is worth making:
- expect the first turn to reuse less of the conversation;
- keep the new setting for the next turn when the work still fits it; and
- if you switch back, allow for the new messages added on the detour even when the earlier branch returns.
Use compaction when the context has become too large or noisy. OpenAI’s compaction guide says compaction replaces earlier context with a shorter representation. That can reduce prefix reuse on the first request after compaction, but fewer total input tokens can still lower cost. We did not test compaction in this experiment.
Change the setting when a better answer is worth the extra processing. The point is not to protect a perfect cache-hit rate. It is to stop treating a long session as if every model and reasoning level shared one warm copy of the conversation.
More field notes
Keep the useful details in the loop.
Subscribe for tested notes on AI systems, product decisions, and the context that makes both work better.
Reproduction record
- Date: 25 August 2026
- Client: Codex CLI
0.149.0-alpha.4.3 - Models: GPT-5.6 Luna and GPT-5.6 Terra
- Access: Signed-in Codex CLI; direct API access was not used
- Main test: 3 matched reasoning changes, 3 matched model changes, 3 reasoning-return sequences, 2 model-return sequences, and clean-room system-layer probes
- Raw record:
controlled-transitions-2026-08-25.jsonin the Zentrik marketing evidence package
The prompt, turn position, working directory, and tool instructions were fixed within each pair. The telemetry does not identify exact server-side cache boundaries. These tests establish a repeated reduction in cached-input reuse against matched controls; they do not establish permanent deletion, a universal recovery schedule, or an exact Codex subscription charge.