GPT-6 Astra reasoning-effort changes do not use configuration_update, defeating cache preservation

What issue are you seeing?

GPT-6 Astra now supports changing reasoning effort mid-conversation without invalidating the reusable prompt prefix by keeping the request-level reasoning.effort stable and adding a positional configuration_update input item instead.

Codex has also recently added first-class durable/trusted support for ResponseItem::ConfigurationUpdate in #42328 (0d502a423031396a8d11c096e5b9f1cb0d30b3d0), including persistence, replay, resume/fork handling, provenance, and filtering of untrusted client-injected updates.

However, on current main (531f3836a1e38ea61eaaba3dccda6711eb6c0dca at the time of this report), normal reasoning-effort changes still appear to follow the older request-level settings path rather than materializing a trusted configuration_update.

The current path is approximately:

TUI reasoning picker / shortcut
  -> UpdateReasoningEffort
  -> thread/settings/update
  -> ThreadSettingsOverrides / SessionSettingsUpdate
  -> StepSettings current effort changes
  -> ModelClientSession::stream(...)
  -> Responses request reasoning.effort changes

At the model-call boundary, session/turn.rs passes the current step effort into the client:

step_context.settings.reasoning_effort().cloned()

and core/src/client.rs uses that value to build the provider-facing request-level reasoning object:

Reasoning {
    effort: effort
        .or_else(|| model_info.default_reasoning_level.clone())
        .map(|effort| reasoning_effort_for_request(model_info, effort)),
    ...
}

So an in-thread change such as high -> xhigh changes the request-level reasoning.effort on the next request.

For Astra, current OpenAI guidance explicitly provides a cache-preserving alternative: add a configuration_update history/input item and keep request-level reasoning.effort unchanged so the existing prompt prefix remains cacheable.

Codex already contains the protocol/history machinery for exactly such an item:

ResponseItem::ConfigurationUpdate {
    reasoning: ConfigurationReasoning { effort },
}

with trusted harness provenance:

CodexHarnessMetadata {
    harness_authored_configuration: true,
    ..Default::default()
}

But I could not find a production path that creates this trusted history item when an ordinary reasoning-effort setting changes. The production occurrences appear to be serialization/replay/filtering support, while explicit construction with trusted provenance is currently exercised in tests.

This looks like the final wiring between the existing reasoning-settings machinery and the new Astra configuration-update machinery may not have landed yet.

Why this is distinct from #35416

#35416, opened July 26, already demonstrates empirically that changing to a previously unused reasoning effort causes a substantial prompt-cache regression in Codex. That issue predates GPT-6 Astra and predates the September 2 configuration_update infrastructure, so at the time there was no documented cache-preserving mechanism for Codex to use.

Astra materially changes the situation: the API now has an explicit mechanism intended to preserve cache across reasoning-effort transitions, and Codex now has durable trusted support for representing that mechanism in model history.

This issue is therefore specifically about wiring the new Astra capability into Codex, rather than documenting the older cache-miss behavior as unavoidable.

Additional impact: WebSocket / incremental reuse

This may also affect Codex's incremental Responses/WebSocket request reuse, not only provider-side prompt caching.

#32533 documents a long Responses Lite session where changing reasoning effort caused:

incremental request failed, websocket reuse properties didn't match

followed by a full-history resend. Keeping the request-scoped reasoning configuration stable and expressing the effective effort transition as incremental input via configuration_update should potentially avoid the reasoning-property mismatch for models that support the new mechanism.

What steps can reproduce the bug?

Source-level reproduction on current main:

1. Start a GPT-6 Astra thread at one supported effort, e.g. high.
2. Change the thread reasoning effort to xhigh through the normal TUI/model setting.
3. Trace the next turn through thread/settings/update -> SessionSettingsUpdate -> StepSettings -> ModelClientSession::stream.
4. Observe that the next provider request is built using reasoning.effort = xhigh.
5. Inspect model history / rollout construction and observe no corresponding harness-authored ResponseItem::ConfigurationUpdate being created by the settings transition.

A focused integration test should be able to demonstrate this without a live backend by inspecting the mocked Responses request body and model-visible input.

For a supported Astra-style fix, the expected test would be:

1. Start at effort A and complete a turn.
2. Change effort A -> B.
3. Start the next turn.
4. Assert the effective/thread setting is B.
5. Assert request-level reasoning.effort remains the stable base A for that same model/cache lineage.
6. Assert model-visible input contains a trusted configuration_update(B) in the correct position.
7. Repeat B -> C and verify a second positional update without changing the request-level base.
8. Cover no-op A -> A, resume, fork, compaction, model switches, and unsupported models/providers.

What is the expected behavior?

For GPT-6 Astra (and any other model/provider explicitly supporting positional reasoning configuration updates):

• changing the selected/effective reasoning effort within the same model lineage should not require changing the request-level reasoning configuration;
• Codex should append a harness-authored configuration_update at the correct history position;
• the user's effective reasoning setting should still update normally in UI/thread state;
• no-op effort changes should not append redundant controls;
• resume/fork/compaction should preserve the effective reasoning state without duplicating updates;
• unsupported models/providers should retain existing behavior;
• model switches should establish whatever new request-level configuration is appropriate for the new model rather than carrying an old model's baseline across lineages;
• external app-server clients should remain unable to forge trusted configuration_update controls.

This should preserve the prompt prefix/cache topology Astra's API feature was designed for, and may also preserve incremental WebSocket reuse across same-model effort changes.

Relevant current code / history

• Existing cache-miss report: #35416
• Related full-resend / reuse failure: #32533
• Durable configuration-update infrastructure: #42328 / 0d502a423031396a8d11c096e5b9f1cb0d30b3d0
• codex-rs/protocol/src/models/configuration_update.rs
• codex-rs/core/src/context_manager/history.rs
• codex-rs/core/src/session/thread_settings.rs
• codex-rs/core/src/session/turn.rs
• codex-rs/core/src/client.rs
• codex-rs/app-server/README.md
• bundled Astra migration guidance: codex-rs/skills/src/assets/samples/openai-docs/references/upgrading-to-gpt-6-astra.md

The repository's own AGENTS.md also calls out model-visible context invariants including incremental history construction and avoiding frequent context changes that cause cache misses, which seems aligned with using the new positional configuration control here.

Additional information

I am not assuming there is no proprietary server-side rewrite for ChatGPT-authenticated Codex traffic. The open-source client/harness itself, however, currently appears to send the changed effort as request-level configuration, and API-key / direct Responses usage cannot rely on an opaque Codex backend to compensate.

If there is an intentional reason not to wire ordinary Codex effort changes through configuration_update, clarification would be useful because the current Astra guidance and the newly landed trusted-history machinery otherwise appear designed for exactly this case.

Trace reasoning changes through codex-rs/core/src/session/thread_settings.rs, session/turn.rs, core/src/client.rs, and context_manager/history.rs, then read protocol/models/configuration_update.rs and the existing #42328 tests. Define the supported-model and model-lineage rules before adding focused mocked Responses coverage; done means trusted positional updates, stable request-level reasoning, correct resume/fork behavior, and unchanged fallback behavior for unsupported cases.