[FEATURE]: Optimization of skill context control and user manual control entry

[wuyezhong]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Can opencode currently automatically unload the content loaded by skills without requiring a skill at this time? If not, can a similar function be added and a user-managed control tool developed, such as unload-skill({name: xxx})?

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [FEATURE]: Support MCP-CLI for on-demand loading of MCP tools for reduced token consumption #7406: [FEATURE]: Support MCP-CLI for on-demand loading of MCP tools for reduced token consumption - Requests on-demand loading of tools to reduce context/token consumption
• [FEATURE]: Let LLM enable MCP on demand, default all MCPs off #7466: [FEATURE]: Let LLM enable MCP on demand, default all MCPs off - Proposes letting the LLM enable/disable tools on-demand to optimize context usage
• [FEATURE]: Add /skills command to list and quick-invoke skills #7846: [FEATURE]: Add /skills command to list and quick-invoke skills - Requests a command interface to list and manage available skills
• [FEATURE]: Session context usage (similar to /context in Claude) #6152: [FEATURE]: Session context usage (similar to /context in Claude) - Requests better visibility and control over what's consuming context

Feel free to ignore if your feature request addresses additional specific use cases not covered by these existing discussions.

[arsham]

I have an implementation using the experimental.chat.messages.transform event. I am still working on it and will opensource it at some point. However, I think if the community would come up with a set of requirements, we can set up a project to release it as a plugin.

Note that you don't need this to be an internal tool. The plugin system is quite capable of doing this.

[IgorWarzocha]

The more session/context manipulation you do the more you break the provider prompt cache.

Fine with the very few providers that don't tie their usage limits to tokens consumed, absolutely devastating with the rest of them.

The former are offering these subs like that mostly because they assume their caching system will make it cost-efficient for them (watch them change their minds). The latter have already identified this and are only approximating how many requests you can send, while in reality counting your token consumption.

Hope I'm making sense. Unloading stuff from context isn't always the best idea.