Models become obsessed with pruning (read->check-build->prune)

[TheGoddessInari]

The system prompt can be ignored/overridden, and DCP's tone creates a sense of urgency even when the model has a lot of context headroom to spare.

In a less noisy opencode environment with more conscientious models, they will get into loops like read->check-build->prune->become convinced their edits aren't being persisted (when no edits were performed).

Consider moving information to the tool descriptions and using more technical language with less urgency: a model should never be convinced that DCP is its main task/job.

[spoons-and-mirrors]

What model are you using?

[Tarquinen]

Moving information to tools wouldn't change anything as thats also part of the system prompt, but you may be right that the tone creates too much urgency and changes default model behavior. I haven't seen that loop you're talking about, I've seen one where it reads > distills > reads > distills when trying to learn a lot of information, but I don't think this is necessarily bad behavior? We're also focused mostly on optimizing towards SOTA models, as coding with non SOTA is just a bad experience overall anyway. Is it possible you're just experiencing poor model behavior? Any specific ideas on what from the prompt should be changed and how?

[TheGoddessInari]

What model are you using?

GLM-4.7 mostly the last few days, but was also happening with Kimi K2.5 Thinking, Minimax M2.1, and Step 3.5 Flash.

Moving information to tools wouldn't change anything as thats also part of the system prompt

That shouldn't be the case. Tool information is their own thing? Been testing a version that goes to the extreme & remove the system prompt hook altogether & the model sees the specific tool descriptions fine.

Is it possible you're just experiencing poor model behavior?

I don't think so. Leading/SOTA OSS models (on default settings) have started treating context-management as their primary task/goal rather than accomplishing whatever programming goals are important.

Any specific ideas on what from the prompt should be changed and how?

IMO, it's more that the model doesn't always pay attention to the system prompt & other plugins are free to override/replace the system prompt altogether.

The behavior that's being shown, the model is constantly trying to count tokens and imagining percentages. It'll purge as often as it's allowed, and changing those parameters didn't seem to help much. Because it keeps getting stuck in the purge loop for me, it becomes convinced that the removed tool calls involved it writing/editing successfully, So at best it recognizes that there's a problem, stops, and alerts the user. At worst, it'll just keep going around in circles indefinitely.

I'm testing a version that removed the system prompt, gave a more concise focus in the tool descriptions, and the model isn't provided with numbers for the prunable list. It definitely fixes the looping/obsession. So far in testing the more minimalistic 'nudge' seems to work, but encountering some provider reliability issues that make testing extensively a bit harder (unrelated to models/model quality). I'm guessing that'd not be the direction you'd want to go!

[spoons-and-mirrors]

yeah some of the changes introduced (namely token counts and context limits) are not tuned in properly yet i guess. system prompt could also cause some of the urgency, but my guess is this is mostly coming from the injections that are forcing model's attention to some data points a bit... to hard

[Tarquinen]

Tool specs, DCP system prompt, default opencode system prompt, things like AGENTS.md all get concatenated into one big system prompt. Thats what I mean by it not mattering if you have information in your tool specs or somewhere else if its one of the elements that gets grouped together to form the one big system prompt.

"SOTA OSS" models are not SOTA models. The best of your examples are still pretty far behind Opus / Codex / Gemini. We optimize for the best models because they are the most used for coding, they present the least issues exactly like what you're describing, and new model performance is trending in their direction, not in the direction of OSS model performance, so this approach is more future proof.

I'm interested in some of your ideas, for example I agree that showing tool token counts probably isn't great, models most likely don't have much training on information like this. It's hard to write prompts everyone will like, they're entirely subjective and I have no way to test performance it's purely vibes, but the goal can not be to optimize when running OSS models.