Make context window and auto-compaction settings model-aware

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #16139

Powered by Codex Action

Related bug report: #16139

@GraviyDev Hey — I know this kind of issue too well. It is very close to the agent reliability problem I’m working on.

I’m building AgaveCore, and I’d like to let a few early people use it for free while I shape it into something stronger.

It helps when a coding agent starts to drift, loses important context, or gives you an output you do not fully trust.

In practice, it works through two habits:

• tell the agent to remember-progress or remember-this when something important should not be lost
• use consult-brain when the current task needs more grounded feedback on what to do next

Over time, as useful journals, decisions, and failures pile up, the product should help the agent make sharper decisions and take better actions with less drift.

If this sounds relevant, reply here and I’ll send the exact steps. You can also use the email or Telegram on my profile.

Cheers,
Mads.

I'm using local model, and I can only afford 64k context window.
I set model_context_window inside profile like this:

[profiles.test]
model_provider = "llamacpp"
model = "Qwen3.6-27B"
model_context_window = 64000

Then if I run /status, I get this:

│ Context window: 86% left (45.9K used / 258K) │

How can I set the context window for the profile properly?
Thanks!

Nevermind, I asked Codex to look codex repo, and it said model_context_window is top level config.
It worked if I set it on the top!

Additional deterministic evidence from macOS / Codex CLI 0.145.0 with gpt-5.6-sol.

Environment

• Codex CLI: 0.145.0
• Surface: local CLI / TUI
• Model: gpt-5.6-sol
• Reasoning effort: high
• Platform: macOS
• A custom model_catalog_json entry declared:
• context_window = 1048576
• max_context_window = 1048576
• effective_context_window_percent = 95
• Codex therefore reported an effective window of 996147.
• The built-in model cache for the same model declared 272000.

Observed behavior

Four separate tool-heavy threads failed with context_window_exceeded after the last successful request reached approximately:

• 364559 input tokens
• 369007 input tokens
• 369869 input tokens
• 371440 input tokens

The next request failed with:

Codex ran out of room in the model's context window.
Start a new thread or clear earlier history before retrying.

The affected rollouts contained no compacted or context_compacted event before failure. The client was waiting for the locally advertised ~996K threshold while the request path rejected the conversation much earlier.

This made the thread unrecoverable: even a short follow-up asking for a summary failed with the same error.

Workaround and compact smoke test

A safe local workaround was:

model_auto_compact_token_limit = 220000
model_auto_compact_token_limit_scope = "total"

I also ran a deterministic compact smoke test using the same model and CLI, temporarily overriding the threshold to 32000:

1. First turn reached 37128 input tokens.
2. The same thread was resumed with a short second prompt.
3. The persisted rollout recorded both:

• compacted
• context_compacted

1. The resumed turn completed successfully.

This confirms the compact machinery itself works when the threshold is below the real request boundary. The failure is the unsafe split between configured/catalog context metadata and the actual accepted context.

Suggested fix

1. Treat the server/provider maximum as authoritative and clamp any custom catalog context_window to it.
2. Compute the effective auto-compact limit as the minimum of:

• configured compact limit,
• server-advertised effective context,
• a safe preflight limit that reserves output/reasoning headroom.

1. Before sending a request, estimate the normalized prompt and trigger compaction when it cannot fit the active provider limit, even if local metadata says otherwise.
2. On context_window_exceeded, perform one emergency compact-and-retry before making the thread unrecoverable.
3. Show configured window, server-effective window, and active compact threshold separately in /status and diagnostics.
4. Emit a warning when model_catalog_json advertises a window larger than the selected provider accepts.

This appears to be a concrete GPT-5.6 instance of the model-aware context handling requested in this issue.