[BUG] OpenAI Compatible Qwen3.8:27B condense context token usage

[RemainIndoors1]

Describe the bug
When using Qwen3.8:27B running in llama.cpp as an openai compatible endpoint, Although I have the max context window set to 262144 in the server, when I attempt to condense context at 181.1k tokens used, I get an error for Failed to condense context - (304897 tokens) exceeds the available context size 262144 tokens

To Reproduce
Steps to reproduce the behavior:

1. Run Qwen3.8:27B server via llama.cpp using the following command:

llama-server.exe --ctx-size 262144 -m "C:\models\Qwen3.8-27B-Q4_K_M.gguf" --top-p 0.95 --top-k 20 --min-p 0.0 --presence-penalty 0.0 --repeat-penalty 1.0 --temp 1.0 --port 8080 --host 0.0.0.0 --chat-template-file "C:\models\chat_template.jinja" -ngl 99 -fa 1 --cache-type-k q4_0 --cache-type-v q4_0 --spec-type draft-mtp --spec-draft-n-max 2 --parallel 1

2. setup OpenAI Compatible provider to connect to that server with Model Reasoning Effort High.
3. Set Context Window Size in Zoo Code to 262144
4. Continue a conversation until token usage bar at the top shows 181.1k / 262.0k
5. Click the Intelligently Condense Context button
6. See error Failed to condense context 304897 tokens used.

Expected behavior
If Token usage for the current conversation was actually that long, I believe my llama.cpp server would have rejected it before this point. Or if the reason for the error is the actual request to intelligently condense context would take that many tokens, then I would expect to be able to see that number somewhere so that I can condense before it grows beyond the point where I have to let it fail and truncate the conversation.

What version of zoo are you running
3.78.0

Additional context
I just wanted to say I appreciate what you guys are doing with this project. It's extremely helpful and intuitive.

[Extremity]

The same thing is happening to me. I've spent the past two hours looking at prompt dumps (--log-prompts-dir) and history_item.json/ui_messages.json. I've realized that every task I've ran today while not monitoring them had condensing fail and truncated instead. When trying to manually condense now at 106,500 / 200,000, it fails with an attempt to send 281,671 tokens. I've had it attempt to send over 470,000 tokens when closer to my context limit.

My reasoning effort is at Medium, using the UD-Q4 quant of 3.8 27B. This happens instantly, it's not like it tries to condense for a while and then fails; llama is flat-out rejecting the initial prompt as too large:

46.00.600.546 E srv send_error: task id = 3, error: request (281671 tokens) exceeds the available context size (200192 tokens), try increasing it

You can see that the context really was just ~106,500 right before this:

561.49.931.139 I slot release: id 0 | task 2160 | stop processing: n_tokens = 106543, truncated = 0

Something interesting - when saving the prompts, the file is over 15,000 lines when trying to use the condense button. If I manually send the condense prompt myself (that is, I paste it as part of the conversation), the entire prompt is 6,600 lines which is much more reasonable/expected. The prompt when I manually sent it contained soft-truncated file reads, terminal outputs, etc. The condense button has full, raw outputs of all file reads, terminal outputs, tool outputs, etc. If a tool read a 3,000 line file 20 turns ago, all 3,000 lines are included when I use the condense button. When sending the prompt manually, it's truncated. I don't know if the typical condense button is meant to include full files, full outputs, etc or not but that seems to be the primary difference here. I can provide both files (the prompts the model received when using the button vs sending it manually) if it helps.

I had Gemini analyze both files because they're too massive for me to do more than skim; I haven't independently verified this, but it added:

Comparing the two files side-by-side reveals three major differences beyond un-truncated tool calls:

1. Mass Duplication of Message History
   The Manual File: Contains a single, linear chronological timeline of the conversation from turn 1 to your final message.

The Condense File: Duplicates entire chunks of the history. Because the extension hit a serialization error at lines 87–94, it restarted the message array assembly mid-stream without resetting its buffer. It appends the first half of the conversation history, hits the cutoff, and then appends the entire history array a second time underneath it.

2. Conversation Depth and Bounds
   Both files start at the exact same initial task setup prompt (message 0).

Both files end at the same final turn state.

The Difference: The manual file moves cleanly from start to end once (~6,600 lines). The condense file starts at message 0, traverses forward, loops back to message 0 mid-prompt, and processes forward to the end a second time (~15,000 lines).

3. Duplicated System Reminders & Capability Headers
   In the failed condense dump:

Tool Schemas: The JSON definitions for system capabilities (read_file, apply_diff, execute_command) appear at the top of the file, and then appear again in full inside the second appended block.

Injection: System reminders and environment states (active workspace details, git status, editor paths) are injected twice—once near the middle cutoff and again at the very bottom right before the closing instructions.

The issue isn't just that past file reads are being restored to raw text; the extension's condensation serializer is literally appending two complete copies of your task context into a single wire request.

The only solution at the moment seems to be manually prompting the model to condense and starting a new task with the output.

Edit - A few things I've tried that did not make a difference:

• Disabling MTP, ngram, both
• Disabling reasoning
• Returning to my known, stable Qwen3.6 27B setup (for some reason this resulted in the failed prompt being over 450,000 tokens? Loading the 3.8 27B model back in and hitting the condense button yet again had it back to ~281,500, so somehow the model and/or it's configuration is relevant?)
• Reverting to Zoo version 3.76.0

As far as I can tell, once a task gets into this state it's stuck there.

[RemainIndoors1]

The same thing is happening to me. I've spent the past two hours looking at prompt dumps (--log-prompts-dir) and history_item.json/ui_messages.json. I've realized that every task I've ran today while not monitoring them had condensing fail and truncated instead. When trying to manually condense now at 106,500 / 200,000, it fails with an attempt to send 281,671 tokens. I've had it attempt to send over 470,000 tokens when closer to my context limit.

My reasoning effort is at Medium, using the UD-Q4 quant of 3.8 27B. This happens instantly, it's not like it tries to condense for a while and then fails; llama is flat-out rejecting the initial prompt as too large:

46.00.600.546 E srv send_error: task id = 3, error: request (281671 tokens) exceeds the available context size (200192 tokens), try increasing it

You can see that the context really was just ~106,500 right before this:

561.49.931.139 I slot release: id 0 | task 2160 | stop processing: n_tokens = 106543, truncated = 0

Something interesting - when saving the prompts, the file is over 15,000 lines when trying to use the condense button. If I manually send the condense prompt myself (that is, I paste it as part of the conversation), the entire prompt is 6,600 lines which is much more reasonable/expected. The prompt when I manually sent it contained soft-truncated file reads, terminal outputs, etc. The condense button has full, raw outputs of all file reads, terminal outputs, tool outputs, etc. If a tool read a 3,000 line file 20 turns ago, all 3,000 lines are included when I use the condense button. When sending the prompt manually, it's truncated. I don't know if the typical condense button is meant to include full files, full outputs, etc or not but that seems to be the primary difference here. I can provide both files (the prompts the model received when using the button vs sending it manually) if it helps.

I had Gemini analyze both files because they're too massive for me to do more than skim; I haven't independently verified this, but it added:

Comparing the two files side-by-side reveals three major differences beyond un-truncated tool calls:

1. Mass Duplication of Message History
   The Manual File: Contains a single, linear chronological timeline of the conversation from turn 1 to your final message.

The Condense File: Duplicates entire chunks of the history. Because the extension hit a serialization error at lines 87–94, it restarted the message array assembly mid-stream without resetting its buffer. It appends the first half of the conversation history, hits the cutoff, and then appends the entire history array a second time underneath it.

2. Conversation Depth and Bounds
   Both files start at the exact same initial task setup prompt (message 0).

Both files end at the same final turn state.
The Difference: The manual file moves cleanly from start to end once (~6,600 lines). The condense file starts at message 0, traverses forward, loops back to message 0 mid-prompt, and processes forward to the end a second time (~15,000 lines).

3. Duplicated System Reminders & Capability Headers
   In the failed condense dump:

Tool Schemas: The JSON definitions for system capabilities (read_file, apply_diff, execute_command) appear at the top of the file, and then appear again in full inside the second appended block.
Injection: System reminders and environment states (active workspace details, git status, editor paths) are injected twice—once near the middle cutoff and again at the very bottom right before the closing instructions.
The issue isn't just that past file reads are being restored to raw text; the extension's condensation serializer is literally appending two complete copies of your task context into a single wire request.

The only solution at the moment seems to be manually prompting the model to condense and starting a new task with the output.

Edit - A few things I've tried that did not make a difference:

* Disabling MTP, ngram, both

* Disabling reasoning

* Returning to my known, stable Qwen3.6 27B setup (for some reason this resulted in the failed prompt being over 450,000 tokens? Loading the 3.8 27B model back in and hitting the condense button yet again had it back to ~281,500, so somehow the model and/or it's configuration is relevant?)

* Reverting to Zoo version 3.76.0

As far as I can tell, once a task gets into this state it's stuck there.

Thanks for the much more in-depth reply than my initial post. After reverting to 3.76.0 have you continued to see the issue with 3.8 in new chats? I've mostly been requesting the model write continued plans in a markdown file before my context limit runs out and starting a new chat. it's a little annoying, but might just be a difference in the way 3.8 handles prompts and history?

[Extremity]

Thanks for the much more in-depth reply than my initial post. After reverting to 3.76.0 have you continued to see the issue with 3.8 in new chats? I've mostly been requesting the model write continued plans in a markdown file before my context limit runs out and starting a new chat. it's a little annoying, but might just be a difference in the way 3.8 handles prompts and history?

When reverting didn't seem to help, I updated back to the current release. Oddly enough, I've had another task running in an identical setup (Still 3.8 27B, nothing else is different) and I just came back to check on a long task that's been running and it's condensing right now. It accepted the prompt, ingested it, and is currently spitting out tokens for the output. I honestly don't know what's different here - it triggered condensing automatically at 163,600 / 200,000 tokens. It seems like this isn't an "always broken" problem, but rather a "something happens that breaks condensing permanently for the task" one - it's just a matter of figuring out what that "something" is. The only big difference I can see is this task didn't have any huge file reads; while it ran a ton of console commands, file reads were allocated to subtasks. My last one that failed had read several large files - do you remember if the task you ran where condensing failed had multiple and/or large file reads? All I can think to do now is try to narrow down the cause.

The condense just completed successfully as I finished typing this and looks normal outside of the analysis and summary tags being visible.

[plap1016]

For what it's worth, I too am experiencing this problem exactly as described using 3.80.

[RemainIndoors1]

do you remember if the task you ran where condensing failed had multiple and/or large file reads? All I can think to do now is try to narrow down the cause.

Hmm, I'd say this has been fairly consistent since I switched from 3.6 to 3.8 - One project I was working on had several very large file reads, and another was creating a project in an empty folder adding multiple files if you would count that as multiple file reads.
I'm going to test using a different gguf author other than unsloth, and maybe try something other than llama.cpp to see if those have any effect on it. Like you mentioned though, once a task is having that issue, it's already too late - switching to another model to attempt to condense doesn't fix it.

[RemainIndoors1]

Alright, so I spent the last few hours working with Qwen:3.8 looking at Zoo Code's code, and added logging in a test environment, and it seems to think the problem is calls to condense don't strip out reasoning blocks the same way a normal conversation does. So, although the status bar at the top shows a smaller percentage of the full context window, when you try to condense, it sends everything that's collected thus far and fails. It also claims there's an issue with how it handled reading a very large file where it added a massive chunk of context, and that was stuck from that point on, so every attempt at condensing would fail from there.

I'll probably have it implement the suggested fixes for my local branch and see if that helps, but I would be hesitant to create a pull request without testing multiple other features.

I also tested changing to ggml-org's version of Qwen:3.8-Q4_K_M still using llama.cpp and see the same behavior without MTP turned on.