Repository navigation
[Feature Request] Add User Controls for Context Management #1990
Description
Activity
This issue might be a duplicate of existing issues. Please check:
- FEATURE REQUEST: Show tokens per file #1349: Specifically requests a
/tokenscommand showing token usage per file (similar to what Aider provides) - feature: Context editing #1014: Requests context editing capabilities
- Feature Request: Add
resetorforktool to let agent reset chat on the previous user message #1789: Requests aresettool for reverting to previous messages - Feature Request: Show more details about the source of the context and the size #883: Requests showing details about context sources and token usage
Feel free to ignore if none of these address your specific case.
- FEATURE REQUEST: Show tokens per file #1349: Specifically requests a
interesting idea, haven't seen this mentioned before
this is something we can think about once we're moved to opentui - i think it's an interesting idea just needs thinking around ux
Hi, thanks for considering.
Is opentui eminent? If not, should I consider writing a PR for the current UI in the meantime? The UX is definitely the biggest challenge to get right (needs to feel and works like OC), as I think the backend would easily support these features with minimal modifications.
I think we can break this proposal down into two components:
-
Methods to get transparency into the current token usage (e.g. the
/tokenscommand proposed by OP) -
Methods to control the token usage (e.g. the other commands proposed by OP)
It would be great if we could prioritize #1 first, which should be much easier than #2.
Reacted by Joost and NataliaPC-
Claude Code have a nice feature for it.
Reacted by Aiden Cline, Oleksii Cherkashyn, Dan Brown, bf-frieder, Davide Ladisa, Connor Adams, Udo, Cyrille Giquello, Arne-Christian Rundereim, eightHundreds and 3 more@taqtiqa-mark we already have mechanisms to add files to context, you can directly @ a file and it will directly inject the context into session, you can also @ a dir to get a list of the files / dirs in it
this doesnt have to do with agents im talking about the prompt input box, when typing in your prompt furing a chat flow, you can introduce anything to context like a file or dir using @ it will bring up a modal and you hit enter to select the correct file, the contents of it will be inserted into context
so a /add command seems to do the same thing in the same place no?
this doesnt have to do with agents im talking about the prompt input box
This issue is clearly targeted at "User Controls for Context Management". Can we keep the discussion about
@and the prompt text to the issue #2965?so a /add command seems to do the same thing in the same place no?
No. As I stated above the effect of
@will be configurable, and concern "Prompt text", obtained from the config hierarchy.
The effect of/addshould always be adding text to the "Context text", obtained from the project hierarchy.These concern fundamentally different sources and destinations.
Or have I misunderstood, and OC makes no distinction between Prompt text and Context text?
@ it will bring up a modal and you hit enter to select the correct file
Yes you can implement this. How does scripting or
|piping work? I now have to useexpect?I really don't understand the emphasis on overloading
@with so many different behaviors.To my mind the need for the user friction (manual interaction with a dialogue) you described is a direct consequence of this overloading. That fine, everything is a tradeoff.... but what is the benefit we get for introducing this friction?
This issue is clearly targeted at #1990. Can we keep the discussion about @ and the prompt text to the issue #2965?
I'm just trying to respond to your comments :) I think this behavior already exists
Maybe you can outline an example of what /add would do?
Like /add and then what the llm would see as a result?
So i can follow better?
Or have I misunderstood, and OC makes no distinction between Prompt text and Context text?
When you add a file to context the content of it isn't literally injected, there is a hidden tool call we present to the llm with the file content as a result (similar to other tools like claude code) in this case I think you would refer to it as "context text"? Maybe you can outline the distinction you meant if I misunderstand
Here is the behavior I am referring to for reference you can add any file or directory to context:
Screen.Recording.2025-10-13.at.9.08.06.PM.mov
Maybe you can outline an example of what /add would do
What I stated above:
/add: A built in command. Importing text into a LLM's Context "buffer"
"Start with the doc's you wished you had":
/add Add a file from the project folder hierarchy to the Context Text submitted to the LLM. In code generation scenarios the Context Text is often program files, debug logs, etc. In other scenarios it could be a document the Prompt Text instructs the LLM to edit or evaluate, etc. Example /add src/user/create.ts /add test/e2e/create_user.feature /add log/debug/test/e2e/create_user.logLike /add and then what the llm would see as a result?
From, for example the OpenAI docs:
{text from @ files here (assuming @@ files are inserted} Text: """ {text from /add files here} """I'd also add some detail to the docs to set out the context/prompt distinctions, something like:
The **Prompt Text** is the immediate trigger for a response, while the **Context Text** provides the necessary background and framework for that response...gotcha that makes more sense
Reacted by Mark Van de VyverHere is the behavior I am referring to for reference you can add any file or directory to context:
That is largely what I expected.
I still believe the overloaded and implicit behavior for@is a terrible idea - sorry.The popup file selection should still be able to work with
\add, and also with\dropClaude Code have a nice feature for it.
Working on agentic workflows with subagents this view would help me a ton to understand the context usage and how I can optimize it. Further it helps a lot for understanding the basics of the context window and why it is so important. It could be really good for users that just started with using opencode and could be a feature why they stick with it.
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
Context for request
There are two main ways developers use Opencode:
Problem
The challenge is that Opencode’s current agentic defaults tend to balloon the context window to 150k+ tokens very quickly. This works fine for tool-driven workflows, but when switching into pair programming mode, it hurts performance. Opencode provides little manual control.
Proposal
Add lightweight context management commands so users can actively manage the session when needed (inspired by Aider):
/drop— remove specific files from context/list— show all files currently in context/tokens— display token usage breakdown (chat history, prompts, each file, repo metadata, etc.)/clear— clear chat history only (keep other context)/reset— reset the session (maybe equivalent to the existing/newsession)Impact
Priority
Moderate: Low engineering complexity, high impact for advanced users.