Confused: 272k context window or 400k?

I guess the reason is: 400k - 128k (output tokens) = 272k input tokens. So what codex is showing us is the max input token limit and not the context window size. Makes sense, but then elsewhere in the CLI it says "xx% context left", I'm assuming that's input tokens left?

This might also explain why many times you're 30% "context left" and suddenly it says 0% left on the next prompt. I'm not certain but perhaps in some places it's using 400k as the "input context limit" incorrectly?

This might also explain why many times you're 30% "context left" and suddenly it says 0% left on the next prompt. I'm not certain but perhaps in some places it's using 400k as the "input context limit" incorrectly?

Imagine you begin with about 190k tokens already in context — that leaves around 80k free.
The tricky part is that the input counter doesn’t track usage live; it only updates after the turn ends.
So when you run a sequence like “Analyze xyz…” → “apply corrections” within one turn,
you risk a context overflow that the auto-compaction system can’t catch in time.

What’s happening under the hood is that every iteration quietly expands the context,
but the system doesn’t notice until the whole cycle completes.
That means you might unknowingly blow past 300k tokens during generation —
and the overflow gets detected only after everything’s done, when it’s too late to fix.

Ideally, auto-compaction would prevent this.
But for that to work, token tracking must happen continuously, in real time,
and compaction should be offloaded to a background thread
as soon as the context size crosses a defined threshold.
That way, each new iteration could append to the compacted state
instead of reusing the full (and increasingly bloated) conversation log.

Another possible fix would be a progressive compaction model with N recent items preserved,
where N scales dynamically depending on tool usage and function calls —
this keeps essential information intact without cluttering the context.

Such a mechanism would ensure a stable flow and a smoother user experience
(✅ no sudden pauses, no delayed cleanups, no overflows mid-session).

That’s how it should work:
✅ 190 → 210 → … → 250 → (compact) → 120 → 150 → … → end of turn

But right now it goes more like this:
❌ 190 → 210 → … → 250 → overflow (no compaction happening mid-turn)

Claude has access to real-time information about the current context state,
and in such situations, it automatically interrupts generation
before a context overflow can occur.

Besides, the 128k output limit applies only to a single-shot generation.
If the model produces, say, 50k tokens and then triggers a tool or search function within the same turn,
it effectively resets — the new call starts with the full 128k limit again.
That’s because the limit concerns the current generation,
and any function call interrupts that process.
So after a function call, the model effectively starts fresh with a new 128k limit.

So in practice, this mechanism doesn’t help much —
each tool invocation just opens a fresh 128k window anyway.

Great analysis @guidedways and @AdsQnn - you were exactly right!

I confirmed your theory by checking the source code (codex-rs/core/src/openai_model_info.rs):

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

Confirmed: 272k input + 128k output = 400k total token budget.

I've submitted #4858 to clarify this in the documentation (both technical docs and FAQ), so future users won't be confused.

when this will get renewed?