Changing Codex reasoning can make the next turn colder

A widely shared post claimed that changing Codex’s reasoning level in a long session throws away the prompt cache. The warning was plausible and expensive: one toggle deep in a large thread could force a cold pass, and switching back could make you pay again.

We could not find that behavior stated in OpenAI’s public Codex documentation. So we measured it.

In four new paired CLI trials, the changed-effort turn reused less cached input than its same-effort control three times and tied once. The median reduction was 9,216 cached tokens. A separate five-turn sequence showed that reuse could recover after the setting stabilized.

That supports a practical warning, but not the dramatic version. Changing reasoning effort can make the next turn much colder. It does not reliably erase every reusable token, and the telemetry does not show that a cache was permanently destroyed.

First, name the thing correctly

Prompt caching reuses an eligible prefix of the input sent to the model. It is not memory, and it is not a store of previous decisions.

OpenAI’s prompt caching guide says cache hits require an exact matching prefix. Stable instructions, tools, schemas, and shared context should stay at the front; changing content should come later. A request setting that changes before a cache breakpoint can stop an earlier prefix from matching.

Persisted reasoning is a separate API feature. Current GPT-5.6 guidance describes carrying available reasoning items across turns when a workflow calls for it. We did not test hidden reasoning state, memory, or a “decision cache.” We measured only cached_input_tokens reported by the Codex CLI.

The replicated test

We used the signed-in Codex CLI 0.148.0-alpha.15 with gpt-5.6-luna. Each trial began in a fresh session at medium effort. The second turn either stayed at medium—the control—or changed to high.

We kept the working directory, prompt shape, model, and no-tool instruction fixed, and alternated which arm ran first. The CLI reports cumulative usage within a thread, so we subtracted the first turn from the second.

Three pairs showed a large reduction. One did not. Across the four pairs, the median reduction was 9,216 cached tokens and the observed range was zero to 19,200.

Trial 3 matters. Its externally visible settings matched the other trials, but the CLI reported a smaller input context in the control arm. We kept it rather than editing away the inconvenient result. It shows why this is a characterization of one current path, not a deterministic rule or a probability estimate.

What happened after the change

The paired test measures the transition. We also ran an exploratory five-turn sequence to see whether reuse returned when the setting stopped moving.

The first high-effort turn added no cached input. Repeating high added 20,224. Returning to medium added 14,080, and the next medium turn added 20,224.

That sequence does not prove a universal recovery schedule. It does show why “destroyed” is the wrong mental model: the measured reuse returned after the setting stabilized, although the first turn back at medium was only partly warm.

What the result establishes—and what it does not

The replicated result supports this claim: changing Codex reasoning effort can sharply reduce cached-input reuse on the transition turn. In this test it did so in three of four pairs. The miss size varied, and one pair showed no reduction.

The tests do not establish that reasoning effort is literally part of a server-side cache key. OpenAI does not publish Codex’s complete cache identity. The change could affect a request prefix, routing, or another request field that moves with the setting.

The open-source Codex harness shows that the request model carries reasoning, service-tier, and cache-key fields. Its usage events expose cached-input and cache-write counts, and its Responses parser reads the API’s cached_tokens and cache_write_tokens. That makes the effect measurable. It does not reveal the server-side decision that caused it.

The practical rule for a long session

Choose a reasoning level before a session becomes large, and keep it stable when the work allows. If you change it, budget for a colder next turn. Do not assume that the whole context will miss, but do not count on partial reuse either.

After a change, another turn at the same setting may warm the reusable prefix. Our longer sequence did that at both high and medium. Treat that as an observation to measure, not a guarantee across models, clients, context lengths, or retention windows.

Use compaction when the context has become too large or noisy. OpenAI’s compaction guide says it reduces context size while carrying forward key state. Because that changes the context representation, exact-prefix reuse may change too. We did not test cache behavior across compaction. Use it for context quality, not as a cache-preservation technique.

Use a fresh session or a subagent when the work genuinely needs different instructions, tools, or reasoning settings. Isolation can improve the work, but it also means supplying context again.

Fast mode is a separate claim

We also held medium reasoning constant and changed only the Fast setting. The current CLI recorded service_tier="fast" as priority. The default first turn and the Fast continuation each reported 9,984 cached input tokens in that two-turn check.

The current Codex speed documentation describes Fast mode as a faster processing tier for a supported model, with higher credit consumption. We found no public OpenAI statement that Fast mode clears the prompt cache, and our bounded check did not show lower reuse than its default baseline.

That is useful negative evidence for this CLI path, not a universal result for every Fast route or model.

How to test your own path cheaply

Keep the model, prompt shape, working directory, cache key, and service tier stable. Pair a same-setting control with the setting change, alternate the order, and repeat enough times to preserve variation instead of publishing one convenient run.

For the Responses API, inspect cached_tokens under usage.input_tokens_details, plus cache_write_tokens. For the Codex CLI, inspect the JSON turn.completed usage object and subtract the previous cumulative totals.

The prompt-caching guide also documents prompt_cache_key, explicit breakpoints for supported GPT-5.6 workflows, and a default 30-minute cache lifetime. Those controls matter when you own the API request. They do not define the cache identity used by Codex desktop or the CLI.

Where this result stops

We ran four paired replications and one exploratory recovery sequence on one current CLI and model combination. We did not test a 350,000-token thread, every reasoning level, every Codex client, or the full cache-retention window. We also did not run a direct API breakpoint experiment; this test used signed-in CLI access only.

In a long session, reasoning effort affects both the work spent on the answer and the amount of earlier input the next turn may reuse.

The broader cost of rebuilding context

Product teams pay a similar cost when customer evidence becomes detached from a decision. The mechanism is different, but the failure is familiar: every handoff has to reconstruct what the previous person or agent already understood.

Zentrik for Codex carries source evidence, accepted constraints, and review checks into the implementation brief. AI can prepare and carry that evidence; the team still decides what to build. The aim is not to preserve every token. It is to stop paying repeatedly for context that should have survived the handoff.

Reproduction record

Dates: 19–20 August 2026<br /> Client: Codex CLI 0.148.0-alpha.15<br /> Model: gpt-5.6-luna<br /> Access: Signed-in Codex CLI; direct API access was not used<br /> Replicated comparison: 4 fresh-session pairs; medium → medium control versus medium → high treatment; order alternated<br /> Exploratory sequences: An earlier medium → high → medium run, a longer medium → high → high → medium → medium recovery run, and a default → Fast boundary check

Paired replications

Trial 3 retained the CLI’s smaller control input context as observed. No run was discarded.

Recovery sequence

Fast-mode boundary check

The experiment shows a repeatable but non-deterministic reduction in reported cached-input reuse after a reasoning-effort change. It does not establish causation at the internal cache-key level or behavior for every Fast route.