Condensing depends on a context ceiling it can't see (#11801, #7992, #6396 look like one bug)

[behrnt-slatgng]

Disclosure up front: I build Grunz, a hosted chat + coding agent on open-weight models, so I'm working on the same problem as you. I'm not selling anything here. Condensing has been the hardest part of our agent to get right, and three of your closed issues describe the same failure from different angles, so here is how they seem to connect.

Condensing depends on a ceiling it can't see

• openai-codex reports GPT-5.5 as 1.0M context but rejects prompts around ~200k tokens #11801: the UI shows 1.0M for GPT-5.5 via openai-codex, but the provider rejects prompts at about 200K. Then condensing fails with "Context size increased from 207811 to 589777 during condensing."
• Context auto compaction in new extension is missing a threshold #7992: against llama.cpp, auto-compaction never fires, probably because Kilo doesn't know the context size and there's nowhere obvious to set it.
• [FEATURE]: Keep latest prompt and agent response when doing context condensing #6396: when condensing does run, it drops the latest prompt and response, and the agent re-does the task that opened the thread.

The first two are the same bug. The trigger compares usage against a declared window, and the declared window is a property of the weights. The window you are actually served belongs to whoever serves them. On the hosted endpoints I have checked, most serve about 32K no matter what the model card says (the card figures run 128K to 1M), and few serve more than 256K. With a ceiling that's too high, condensing never triggers. With one that's too low, it triggers too early. And when the provider rejects the request, the recovery path runs at the worst possible moment, when the prompt is already over the limit.

The 207K to 589K jump looks like the condense request itself was built from the full history plus the condensing prompt, so it could never fit under the ceiling it was trying to get back under.

Condensing is a lossy write, and the goal goes first

#6396 is the other half. A summarizer keeps whatever looks salient in the transcript, and the original goal is usually the oldest and least-repeated text in it. So it gets squashed into a topic, the agent sees a stated task, and it starts over. We hit the same thing, and our first fix made it worse: we pinned the goal by adding it to the system prompt, which counts toward the same budget. That moved the trigger earlier, and on a 32K endpoint the run started condensing in a loop. What did work was keeping the goal as a small, separately budgeted object that the summarizer can't rewrite, and never feeding it back in as something to summarize.

Questions

1. When the provider rejects a request, is the observed limit written back anywhere, so the next trigger uses it instead of the catalog value? The error text usually states the real maximum.
2. Is the condense request's own size checked against the ceiling before it's sent? The openai-codex reports GPT-5.5 as 1.0M context but rejects prompts around ~200k tokens #11801 numbers suggest it isn't.
3. Would you take a PR that keeps the original task and the latest exchange out of the summarizer's input entirely, rather than asking the summarizer prompt to preserve them?