Kimi k2.5 loses context after compress.

[nmzpy]

How could we make it so that models don't lose context entirely after compress and they start to "fix" what has already been fixed IN the compressed summary? I think we should put some tighter guards to the tool call so it knows before making it HOW to actually summarize well. -- Thoughts?

[Tarquinen]

Yea compress is still fairly experimental, working on some big changes to it. The way it triggers and how it summarizes the compressed section is mostly set by the prompt here: https://github.com/Opencode-DCP/opencode-dynamic-context-pruning/blob/dev/lib/prompts/compress.md, any ideas on what you think should be improved?

[manorit2001]

what's the difference between this compress and /compact in opencode?

[Tarquinen]

Compress doesn't compress the entire context history, it can be more surgical by picking a start and end range. This means each compression summary will only have information about a specific task. It also doesn't trigger when your context window runs out but at "smarter" times like when tasks are done or direction changes.

[wassname]

My suggestions as a suer would be

• show the compression (like the opencode compression does) this lets user verify it, and they don't wrongfully blame it for the model forgetting things
• make it clearer it's a targeted compression by calling it compress_window
• perhaps emphasize keeping 1) user messages especially corrections, requests, choice, preferences (even more than currently) 2) plans 3) tasks

You could also directly optimise it using GEPA, and performance test it using an approach like huggingface does in upskill (since this is essentially a compression skill).

[Tarquinen]

Great ideas, thank you! The compression can already be shown, it's just disabled by default because it adds a big block of text:

"tools": {
    "compress": {"showCompression": true}
}

I'm not really a big fan of changing the tool name, but you're right it should be more clear that it's a window vs the whole session context.

How do you think keeping user messages should work? I'm currently working on a system to keep prior compressions if a new compression encompasses it by requiring the new compression to include a tag/placeholder in the summary where the previous compression should be inserted. This means you're never diluting down compressions over multiple compress tool calls. Unfortunately so far this is quite hard for anything other than the best SOTA models, so I'm not sure I can extend this further to force the summary to include placeholders where user messages can be inserted, but I haven't tried yet. Do you have any ideas? I don't really want to just stack up 5 user messages that were in the compression range and place them in front of the compression, I think this will impact the flow / meaning of the conversation that took place...

[wassname]

Do you have any ideas? I don't really want to just stack up 5 user messages that were in the compression range and place them in front of the compression

To be honest it sounds like you have good plan, but maybe you're just hitting the limits wrt to model intelligence / context.

The recursive language model paper has some interesting ideas regarding recursive compression, which is what you're talking about. So if you haven't read that it may spur some fun ideas.

[Tarquinen]

Awesome thanks, i'll research your references thats very helpful.

[manorit2001]

https://arxiv.org/abs/2305.15805 came across this as well, although RLMs would be more scalable but you can see if this makes sense too ( incase you haven't already )

[cloudpresser]

I think this is related to #391 #391 (comment)

User messages are interpreted correctly as the user requesting immediate action from the model, instead of letting it continue with summarized findings.