[Feature Request] Add User Controls for Context Management

Context for request
There are two main ways developers use Opencode:

AI-assisted programming — working side-by-side with the model as a “pair programmer.” In this mode, reliability and precision are critical, and performance drops when the context window grows beyond ~30–40k tokens.
Agentic workflows — where the model uses tools autonomously (searching files, pulling in directories, etc.). Here, having a very large context is fine because the model is orchestrating tasks rather than producing line-by-line code.

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 /new session)

Impact

Maintains Opencode’s smart defaults for agentic workflows.
Empowers power users doing AI-assisted programming to keep the model operating in its “sweet spot” (~30–40k tokens), reducing hallucinations and improving code reliability.
Creates a clear differentiator vs. Claude Code and other assistants that don’t offer this level of fine-grained control.
dual-mode advantage (“best of both worlds: autonomous agentic + precise pair programming”)

Priority
Moderate: Low engineering complexity, high impact for advanced users.

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

FEATURE REQUEST: Show tokens per file #1349: Specifically requests a /tokens command showing token usage per file (similar to what Aider provides)
feature: Context editing #1014: Requests context editing capabilities
Feature Request: Add reset or fork tool to let agent reset chat on the previous user message #1789: Requests a reset tool 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.

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 /tokens command 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.

Claude Code have a nice feature for it.

@taqtiqa-mark

@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 /add should 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 use expect?

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.log

Like /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

Here 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 \drop

Claude 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.

Navigation Menu

Repository navigation

[Feature Request] Add User Controls for Context Management #1990

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Feature Request] Add User Controls for Context Management #1990

Description

Activity

github-actions commented on Aug 16, 2025

rekram1-node commented on Aug 16, 2025

thdxr commented on Aug 17, 2025

ddbaron commented on Aug 17, 2025

nikhilmaddirala commented on Aug 18, 2025

westito commented on Oct 10, 2025

taqtiqa-mark commented on Oct 12, 2025

rekram1-node commented on Oct 13, 2025

taqtiqa-mark commented on Oct 14, 2025

rekram1-node commented on Oct 14, 2025

taqtiqa-mark commented on Oct 14, 2025

taqtiqa-mark commented on Oct 14, 2025

rekram1-node commented on Oct 14, 2025

taqtiqa-mark commented on Oct 14, 2025

rekram1-node commented on Oct 14, 2025

taqtiqa-mark commented on Oct 14, 2025

bf-frieder commented on Nov 17, 2025

taqtiqa-mark commented on Feb 6, 2026

github-actions commented on Jun 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions