Compress context window automatically

[Juice10]

Problem: once the context window goes over 50%, LLM output quality goes down.

Solution: compress it automatically

[Juice10]

Easy solution:
Add to system prompt something like "if the context goes over 50%, use newtask to start a new task with a fresh and compressed context window"

[Juice10]

Example custom rule that does this:
https://github.com/cline/prompts/blob/8058fe3d79c1ce52230588aa2383748f7732c838/.clinerules/new-task-automation#L1-L268

[HadesArchitect]

Do you think we should recommend users to use it as a custom instruction for now before it's implemented?

[HadesArchitect]

(I'd go for Instruction over Rule as it isn't project-specific)

[Juice10]

Yes I think so

[HadesArchitect]

I'll schedule something for the next week

[OleynikAleksandr]

You already have this excellent document:
https://blog.kilocode.ai/p/how-newtask-can-substantially-reduce
The idea is to simply inform the User - who, generally speaking, can already see the context window usage progress bar - that there's an emerging risk of deteriorating response quality. Then, recommend they use the /newtask function (Create a new task with context from the current task).
If the function's algorithm is effective, this would likely be sufficient, wouldn't it?

Additionally, I would like to note that from what I understand, Orchestrator mode directly helps reduce the context of a single session in large projects. This is because all the tasks it creates (after receiving the main task from the User) are essentially independent sessions, each with its own context. It seems that the dialogue with the Orchestrator within a single project could also, presumably, be broken down into separate sessions using the /newtask function.
Please let me know if I'm mistaken.

[HadesArchitect]

@olearycrew you did a big work on the orchestrator mode, WDYT about that?

[OleynikAleksandr]

Additionally, I would like to note that, by the way, I'm currently in the process of refactoring my project into a new structure, using the Orchestrator pattern. Nevertheless, right now, the 'Architect' agent/task, while studying the project and preparing refactoring documents, has already exceeded 300,000 tokens in its session (it's a good thing Gemini 2.5 Pro has a 1 million token limit!). For standard models, this would already be oversized. So, I think it's necessary to update the Orchestrator's instructions to include breaking down tasks to fit within, say, 50% of the model's context window. **Or even better—and this would be a huge help!—**provide the ability to configure the permissible token volume per session individually for each model. That would be extremely beneficial.

And another thing I noticed is that the 'Architect' handed off work to the 'Code' mode within the same session. That's almost certainly going to result in an oversized context.
Perhaps these delegations should always be routed through the Orchestrator, which would then consolidate the necessary information and initiate a new session (while also, of course, adhering to that 50% context window guideline for the model)?

[OleynikAleksandr]

Hi team,
Just to update you while we're on this topic: The Roo Code team has released version 3.17.2, which is now available to pull.
You can find the update notes here: https://docs.roocode.com/update-notes/v3.17.0
They've made significant enhancements to the Orchestrator mode.
I also hope the new 'Smarter Context Management with Intelligent Condensation' feature is compatible with Orchestrator mode when activated – I'll verify this.

[kevinvandijk]

This will be resolved in #440 then. Tagging @Juice10 for clarity.