Control over auto-compaction parameters

This is an essential action. Hardcoding must be removed so that users can use it in the form they desire.

idk. needs to work more with it to be sure. might consider downgrading version if i notice an issue. i dont see them allowing for more token constantly or else it'll be more expensive for them to run.

I've already rolled back to 0.39.

I didn't roll back.
Looking at the related code change, It says the context window is 272k but iirc, in the docs, Pro users has 192k window? So I was thinking 220k made no sense. Here I think auto-compact at 220k (~81%) is reasonable.
I think context-rot happens at that time and more tokens in context makes the model behave worse.

So idk what will happen for a Plus user with 128k context? they don't get this feature? that's not fair.

But I'm with you on this issue, not only for the behavior but also for the freedom and equity.

gpt5-high doesn't auto compact. use that

Is this auto compaction intelligent?

For example, I could tell I was reaching the context window (showed I had 20% left), so I asked the agent to make a detailed MD file for the next agent about everything we've done and everything we need to do moving forward. Once that document was completed, I mentioned the context was low, I don't know if it was just coincidence, it automatically compacted the conversation and handed that document off as the first function.

Now after a test I think it's better to have it ON. my context were full on 0.39 and when it's full I get this error

⚠️ stream error: stream disconnected before completion: stream closed before response.completed; retrying 1/5 in 215ms… ⚠️ stream error: stream disconnected before completion: stream closed before response.completed; retrying 2/5 in 437ms… • Analyzing nested conditional directives ⚠️ stream error: stream disconnected before completion: stream closed before response.completed; retrying 3/5 in 857ms… • Simplifying nested conditional macros ⚠️ stream error: stream disconnected before completion: stream closed before response.completed; retrying 4/5 in 1.441s… • Tracing conditional compilation blocks ⚠️ stream error: stream disconnected before completion: stream closed before response.completed; retrying 5/5 in 3.031s… • Adjusting debugLiveActivityPreviewPhase assignment ⚠️ stream error: stream disconnected before completion: stream closed before response.completed; retrying 1/5 in 193ms… • Considering debug code removal ⚠️ stream error: stream disconnected before completion: stream closed before response.completed; retrying 4/5 in 1.505s… • Considering debugLiveActivityPreviewPhase assignment ⚠️ stream error: stream disconnected before completion: stream closed before response.completed; retrying 5/5 in 3.354s…

It looks like the auto-compact feature is triggering an infinite loop: the agent keeps running web-search, then auto-compacts, and then re-searches the same information it seems to have forgotten after the compact step. This loop continues until it’s manually cancelled, effectively draining the quota if left unattended.

There also appears to be a problem with retaining recent context after a compact. For example, it sometimes re-attempts tasks that were already completed earlier in the same session.

I will submit a PR for this. stayed tuned

If autocompact is not working properly and damaging the context, then compaction should be fixed. Prompt improved or only compact initial part and leave last part of context untouched. I have no idea on who is going to survive with a full context that the model won't accept, however. Only sane option I see is to trigger a request to compact with manually crafted prompt. But OFF doesn't look like a reasonable option. What are you going to do with OFF? Close the session? Possible improvements I see is to warn the user when getting close to autocompact limit, and another is to ask the user if they want to enter a custom compact prompt for autocompact.

When I encounter the issue, I have to enter /compact which is annoying

When I encounter the issue, I have to enter /compact which is annoying

The only 2 choices when running out of context are:

1 - Compact
2 - Restart a new session

The context is limited at least with current LLMs architecture. And likely in the near future models that could have 1/2 M tokens context will have it limited as well. You just will need to compact less in the future.

Options I see useful:

Autocompact threshold configuration
Configure part of the context to compact (if not 100%), maybe even prompt for this could be useful
Compact prompt configuration/change
Prompt the user to enter compact prompt manually when threshold reached
Postpone compaction a little bit (maybe possible if there is more context beyond threshold, but there will be a point where it won't be possible to postpone)

Again:
OFF <----- What is the use case for this? (Pro doesn't means unlimited context)

I never see auth compact triggered, it always fall in to exceed max context window after a long run and can't recover even use the /compact command.

is there a config key to enable auto compact?

Is this a hallucination? I don't think there is an auto compact setting?

https://chatgpt.com/share/68f22c80-a444-8012-b6b1-239824b67d2b

there is auto-compact, but the limit for it is misconfigured

_ if slug.starts_with("gpt-5-codex") => Some(ModelInfo {
            context_window: 272_000,
            max_output_tokens: 128_000,
            auto_compact_token_limit: Some(350_000),
        }),

You see it's set to 350000 but would never trigger. and even if it triggers, there are no space for the prompts to do the auto compacting and always fail

Will you have plans to do this in near future? Recently I ran into a case where there was still over 20%+ context left, and the coding task was almost finished (all items in the Plan had been checked by Codex), but right at the end It got “Context compacted.” This feels like a waste of both time and tokens.

i want this too

Hello,

In our usage, context compaction does not merely “degrade” the session; it often makes it unusable.

After compaction, the agent loses essential parts of the conversation: instructions, business context, decisions already made, technical constraints, MCP, skills, and sometimes even the exact objective of the task. From that point on, it no longer follows the request properly, produces incorrect, unstable, or even broken code, and the generated changes often have to be discarded entirely.

In practice, whenever compaction occurs, we prefer to stop the session, revert the changes, and start over with the task broken down differently. This costs a great deal of time, but it is still preferable to continuing with a conversation that has become unreliable.

Two options seem essential to us:

the ability to completely disable automatic compaction;

compaction events/hooks that allow the necessary context to be explicitly re-injected.

As things stand, the issue is not a simple drop in quality: compaction makes the results unusable.

Have a good day

I also need the option to disable compaction. This is the most urgent feature missing in codex.

Adding support from the perspective of a long-time Claude Code user who has moved to Codex. The critical part for me is not only an OFF switch, but configurable proactive thresholds per model/project, e.g. compact at 70-85% or prompt before compacting, rather than waiting until the window is effectively exhausted.

When compaction fires too late or mid-flow, the session is more likely to drift or lose task state. A config surface like mode + threshold + prompt/manual would make long sessions safer and more predictable.

This is HUGE. I also recently came from Claude Code. (Now using both.) The inability to turn off autocompact is a really big deal. Please help!

(PS - The configurable proactive thresholds per model/project that @szybnev mentions would be really really nice too.)

[And thank you very much for all the work on Codex! 💯 ]

A hard OFF switch makes sense as an escape hatch, but I think it treats the whole window as if every token in it is worth the same, and that's the part that actually hurts. Most of a long session really is fine to compress. The exploration, the dead ends, the intermediate tool output. What you don't want summarized is the small set of things the rest of the work depends on, like the constraints you set early, the decisions you locked in, the files that matter. Those should come back exactly as written or not at all.

Your smart-auto mode already points at this with "preserves pinned blocks," and I'd argue that's the real lever, more than the threshold number. The questions worth nailing down are what gets pinned, whether the user or the agent decides, and whether pinned content is re-injected verbatim after a compaction instead of being folded into the summary like everything else. Threshold tuning mostly delays the problem. Separating what's safe to lose from what isn't is what actually fixes it.

The other thing I'd want is a signal when it happens. Right now compaction is silent, so the first sign something was dropped is the model doing something that no longer lines up with earlier context. Even a one-line note that it compacted, and whether the pinned set survived, would let you catch a bad compaction before it costs you a step.

+1. Compaction at 90% often fails with the oft discussed Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact), so if it must be automatic it needs to be automatic sooner, not at a point where the compaction model runs out of context window because it's already "too late". At that point the codex thread becomes effectively unsalvageable which is very annoying when you're deep into something: you have to manually extract whatever is in the worktree, archive it, start a new thread and ask the AI to try to figure out what was going on based on the markdown copy of the previous surface level convo. This happens multiple times a day. You can't "save" the old thread by say erasing a little bit at the end and then running compaction, the only way to recover once you get into the compaction failure death mode is if you happened to fork the conversation before you started the turn. But that has its own issues with worktree and branch juggling.

All this to say it'd probably be preferable for the context to just scroll out so disabling autocompact or providing an alternative compact that just discards the first 3rd of non-surface level context (e.g. not the user messages but all the items 'collapsed' in the UI) would be superior than this repeated pain-point. If that's not desirable for economics, e.g. you really want short context windows to save money, that's perfectly fair but then let us go the other way: auto-compact sooner, like at 85% since long compacting breaks the compactor so often.

Update: switching between fast and normal mode may also be a culprit.