codex - 💡(How to fix) Fix Auto-Compaction is VERY BAD

What version of the Codex App are you using (From “About Codex” dialog)?

26.519.81530

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Main Issues I've Found:

1. The auto-compaction trigger has too much variability: I've had it trigger at 70% and other times at 98%. That is a HUGE window and there is no information I can find on how to know when it will actually happen. And the Codex Agent also doesn't know and seems to be highly disconnected from Token usage and context window data. Which brings me to the next point.

2. The Codex Agent has No Visibility of Token Usage and Compaction Data (Simple Fix): The agent should have visibility of token usage and context window information. There is no reason it cannot keep track of how much a task cost in tokens before it started and after it started the work. It should also be able to see the same Token Usage status that we can see on our UI. If we can see it, there is no reason it cannot have that very useful awareness of it. There are many benefits to allowing it some very simple access to view this data. If you are able to render this data to our UI, then it should be able to keep that counter data visible in it's core function. This would also allow it to know when we are nearing auto-compaction.

3. The Codex Agent has no connection with Auto-Compaction (Simple Fix): The agent and auto-compaction appear to have no connection and thus doesn't know when it could happen. It absolutely should based on the token usage data. Because it doesn't know of this, then it can proceed without warning, and it should automatically know whether it's task is a high risk of auto-compaction to do what it needs to in order to preserve the context window for it's work. That being said, the auto compaction needs some clear guardrails or improved algorithm because it seems very wonky and unreliable.

4. Auto-Compaction should not compact relied upon context during a work session: Auto-compaction will trigger during a work session, right in the middle of a task, which is understandable if the context window needs extra tokens to perform the task. What it should absolutely not do is compact relied upon context that the current work session is using. Before the work session begins, the context being used for that work session work to be performed should be blocked from being included in the compaction process. This causes a huge problem because none of the work that was performed can now be relied upon because all the context it was using to perform the work session just got compacted and the agent continues finishing the work like nothing happened. That work output is very likely to have to be scrapped because it cannot be relied upon. If the context that is needed can be locked from the compaction and that means all other context, especially oldest context should be more compressed, flattened, or even cleared from the context window to preserve what it needs to in order to finish the task. It should not ever do it to the context it needs. With bad outputs, then every other task depending on those now carries forward the compacted/incorrect outputs. FIX THIS PLEASE!

What steps can reproduce the bug?

Just use the agent into long context windows until it auto-compacts and see every time it auto-compacts at what percentage of Token Usage. Then have it auto-compact during a work session and compare how accurate the results are to if it didn't auto-compact the same task. I did this and the results are pretty significant. Give it some long documents where context matters and have it provide you a baseline test to confirm it's understanding pre-compaction. Then once auto-compaction completes, give it the same test and see how well it remembers the context and you'll see how bad it is.

What is the expected behavior?

It doesn't compact relied upon context to complete its current work session in order to preserve the intended output of that work. Use the non-related context of that work to free up the token context window if needed.

Additional information

I'm not sure if there's a bug causing this or if it's part of your intended process, but either way, it's bad and needs to be fixed.