You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to increase the context window of an existing Codex thread without changing its model, duplicating the Codex provider entry, or losing the provider-native conversation.
Today, different model_context_window and model_auto_compact_token_limit values can be supplied through provider-level Codex launch arguments. That creates two Codex entries for the same account and model. Custom model rows do not carry separate launch configurations and duplicate model slugs are deduplicated.
Please add a context selector within one Codex entry, alongside the model and reasoning controls:
Choose the model independently from its context preset, such as Default, a supported token limit, or Maximum supported.
Expose the auto-compaction threshold separately, including a maximum-supported option. Show the actual effective limit after Codex reserves headroom or clamps the requested value.
Discover or validate limits against the active model and Codex runtime, rather than hard-coding the public API's advertised context size. Disable unsupported combinations.
Apply a change to an existing thread after its active turn finishes. Resume the same native Codex conversation and preserve the T3 timeline, rather than creating a fresh native thread behind an existing chat.
There is also a presentation problem with the two-provider workaround: labels such as Codex and Codex · 872K produce tiny CO and C· overlays on the OpenAI icon. These are difficult to interpret. A single provider entry would remove the need for that distinction. Where multiple entries are still useful, please allow hiding the initials overlay or setting a meaningful short badge independently from the full label. Keep the complete entry name in the tooltip and accessible label, and show the context size separately from the model name.
Observed in T3 nightly 0.0.40-nightly.20260907.1346 and Codex 0.153.4. A local handoff patch has been tested with disposable real Codex conversations: active switches, a stopped-session switch, unchanged native conversation ID, recall of a saved marker, and continuation across a T3 upgrade and rollback. This request is for native application support so users do not need separate entries or a local patch.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
I want to increase the context window of an existing Codex thread without changing its model, duplicating the Codex provider entry, or losing the provider-native conversation.
Today, different
model_context_windowandmodel_auto_compact_token_limitvalues can be supplied through provider-level Codex launch arguments. That creates two Codex entries for the same account and model. Custom model rows do not carry separate launch configurations and duplicate model slugs are deduplicated.Please add a context selector within one Codex entry, alongside the model and reasoning controls:
There is also a presentation problem with the two-provider workaround: labels such as
CodexandCodex · 872Kproduce tinyCOandC·overlays on the OpenAI icon. These are difficult to interpret. A single provider entry would remove the need for that distinction. Where multiple entries are still useful, please allow hiding the initials overlay or setting a meaningful short badge independently from the full label. Keep the complete entry name in the tooltip and accessible label, and show the context size separately from the model name.Observed in T3 nightly
0.0.40-nightly.20260907.1346and Codex0.153.4. A local handoff patch has been tested with disposable real Codex conversations: active switches, a stopped-session switch, unchanged native conversation ID, recall of a saved marker, and continuation across a T3 upgrade and rollback. This request is for native application support so users do not need separate entries or a local patch.All reactions