Feature request: Option to choose the model and manual trigger of pruning

[DanielusG]

Hi, I find this plugin extremely interesting because ever since LLMs became famous, I've always wondered why no one implemented this system, which seems so logical and useful, in their tools (see Cline, Roo Code, and company).

I would like to be able to configure the model and start the pruning on demand, perhaps while seeing its status.

Reasons:
Currently, the Big Pickle model is used, and since it is free, the code sent via this API is used for training purposes. So if you use a private provider for your task and the plugin activates, you have successfully sold off your entire codebase.

Furthermore, during a task, I sometimes perceive that the model has gone a bit off track and I've redirected it in the right direction, but the context is still dirty from previous calls, perhaps command errors, incorrect readings, etc. Calling this plugin on demand when needed would be ideal in these cases.

I could potentially contribute to this feature by opening a pull request, but I don't know the OpenCode plugin system, so I wouldn't really know where to start. The documentation seems to only cover the SDK for using OpenCode programmatically, so if you could provide me with information on where to find documentation for plugins, I would be happy to contribute

[spoons-and-mirrors]

We were talking about this yesterday, this will be implemented 👍

I'm really excited for this plugin as well !

[Tarquinen]

Sorry forgot to reply to this, you can configure model in latest version with
"model": "provider/model",
same as your opencode in ~/.config/opencode/dcp.jsconc, or per project in .opencode/dp.jsonc
I'll keep issue open until manual pruning is implemented, waiting on a PR in opencode for that. Let me know if you have any other ideas!

[Tarquinen]

As for how you can contribute and learn about plugins, the docs don't cover much so I would recommend cloning the opencode repo and asking your robots to teach you how it works

[DanielusG]

A quick update on this issue. I've been using this plugin for a few days and, as I expected, it's very useful, but I've noticed a few things that I really don't like.

Disclaimer: this is clearly my personal opinion, and the criticisms reported below are entirely constructive for the purpose of improving the plugin.

Fallback system
Why implement a model fallback system in case of failure? I mean, if pruning fails, you could simply report the failure with a message like all other tools. Instead, forcing the use of other models when the main one has failed causes a loss of control and becomes needlessly expensive.

Pratical example: I use Claude Opus 4.5 within OpenCode using the GitHub Copilot subscription, but when pruning starts, it sometimes falls back, using one of my precious 300 requests per month.

Note: I've seen that the skip functionality for the github-copilot fallback models is set in the code, but this example is more useful for emphasizing what I mean by the loss of control than for its applicability in this specific case.

Simply, the very concept of configuring a model for pruning and then having it, without your control, use any other model configured in opencode is, in my opinion, wrong.

Manual trigger
While it's true that pruning doesn't break the current conversation flow and is therefore a fairly risk-free action, sometimes I've only interrupted a task to give the model a detail so it can proceed, or perhaps I need to execute a command first before it continues, and I find this tool activating on its own. Then, when I actually realize the model has gone off track and some pruning is truly necessary, there's no way to manually trigger this tool, and so I have to interrupt the task and hope the model is smart enough to understand what really needs to be removed from the context.

@Tarquinen Let me know if this feedback aligns with your project vision, and if so, I can try to help contribute in these aspects in my free time.

[Tarquinen]

Hey, these are some good thoughts, I had most of them myself as well. The fallback system was designed to follow opencodes philosophy of 'just works' out of the box. Users can install and use the plugin without having to set anything up. As you mentioned with the skip system, I think the cases where this can lead to expensive behavior have been taken care of. The fallback system won't use Github Copilot premium requests, and for other providers it uses the best 'value' model. Users also see toast notifications whenever this happens, encouraging them to find a solution that fits them in their dcp.jsonc config.

I understand some users want even more control, for example I know people with jobs requiring only specific providers/models be used. They can use the strictModelSelection key in the config, which will disable fallback and force DCP to use either their session model or their configured model if they have one set. There's also a notification here when DCP doesn't activate due to this setting.

Manual trigger is awaiting an opencode PR, but i'm working on more functionality that may help and there's some already implemented. For example, theres already a context pruning tool exposed to opencode with this plugin, most models don't do a good job triggering it yet (WIP), but you can tell opencode to prune and provide any details you want, that should already work fine. You're right that interrupting opencode with escape triggering DCP is weird behavior, this should be loooked at I think.

Let me know if this makes sense and of course feel free to contribute, couple ideas already in Issues

[Tarquinen]

Awaiting sst/opencode#4411 - once that lands we can register a /prune command.

[DanielusG]

@Tarquinen
Currently this extension is insane, truly incredible; it works very well and finally is properly configurable. Really congratulations. The only thing missing that doesn’t clearly depend on you is manual pruning, but it has basically been solved thanks to the model’s tool calls, even GPT OSS 20B uses it very well and the context always stays under 30k. If it's not a problem for you, I'll close this issue when the manual command is implemented, okay?

[Tarquinen]

Thanks for the kind words! I'll reference this issue when that PR above gets merged, should be an easy update when it happens.