anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

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

New Issue
Open
opened 2026-02-16 17:30:27 -05:00 by yindo · 18 comments
yindo commented 2026-02-16 17:30:27 -05:00
Owner
Copy Link
Copy Source

Originally created by @ddbaron on GitHub (Aug 16, 2025).

Originally assigned to: @thdxr on GitHub.

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

  1. 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.
  2. 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.

Originally created by @ddbaron on GitHub (Aug 16, 2025). Originally assigned to: @thdxr on GitHub. **Context for request** There are two main ways developers use Opencode: 1. **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. 2. **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.
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Aug 16, 2025):

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

  • #1349: Specifically requests a /tokens command showing token usage per file (similar to what Aider provides)
  • #1014: Requests context editing capabilities
  • #1789: Requests a reset tool for reverting to previous messages
  • #883: Requests showing details about context sources and token usage

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Aug 16, 2025): This issue might be a duplicate of existing issues. Please check: - #1349: Specifically requests a `/tokens` command showing token usage per file (similar to what Aider provides) - #1014: Requests context editing capabilities - #1789: Requests a `reset` tool for reverting to previous messages - #883: Requests showing details about context sources and token usage Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Aug 16, 2025):

interesting idea, haven't seen this mentioned before

@rekram1-node commented on GitHub (Aug 16, 2025): interesting idea, haven't seen this mentioned before
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@thdxr commented on GitHub (Aug 16, 2025):

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

@thdxr commented on GitHub (Aug 16, 2025): 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
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@ddbaron commented on GitHub (Aug 17, 2025):

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.

@ddbaron commented on GitHub (Aug 17, 2025): 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.
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@nikhilmaddirala commented on GitHub (Aug 18, 2025):

I think we can break this proposal down into two components:

  1. Methods to get transparency into the current token usage (e.g. the /tokens command proposed by OP)

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

@nikhilmaddirala commented on GitHub (Aug 18, 2025): I think we can break this proposal down into two components: 1. Methods to get transparency into the current token usage (e.g. the `/tokens` command proposed by OP) 2. 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.
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@westito commented on GitHub (Oct 10, 2025):

Claude Code have a nice feature for it.
Image

Image
@westito commented on GitHub (Oct 10, 2025): Claude Code have a nice feature for it. <img width="670" height="229" alt="Image" src="https://github.com/user-attachments/assets/dfd71d6e-90fc-4e47-bb69-f9bf70861b0c" /> <img width="562" height="456" alt="Image" src="https://github.com/user-attachments/assets/7c4d32cd-09b0-4be7-b018-55fbf3d3124a" />
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@taqtiqa-mark commented on GitHub (Oct 12, 2025):

Proposal Add lightweight context management commands so users can actively manage the session when needed (inspired by Aider):

* `...`
  • /add — insert specific files into context

A related configuration variable (agent file) is suggestive:

add_context: raw, tree-sitter

@taqtiqa-mark commented on GitHub (Oct 12, 2025): > **Proposal** Add lightweight context management commands so users can actively manage the session when needed (inspired by Aider): > > * `...` * `/add` — insert specific files into context A related configuration variable (agent file) is suggestive: `add_context: raw, tree-sitter`
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 13, 2025):

@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

@rekram1-node commented on GitHub (Oct 13, 2025): @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
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@taqtiqa-mark commented on GitHub (Oct 13, 2025):

I'll focus further comments in #2965.

Relevant here is that /add should be a built in command, independent of how an agent is configured (import_at: true,false, where current default behavior is consistent with import_at: false, and that may/will change).

I believe they are categorically distinct:

  • /add: A built in command. Importing text into a LLM's Context "buffer"
  • @: A DSL-style of convention, with configurable behavior that can vary by agent/sub-agent. Importing text into a LLM's Prompt "buffer"

Can you clarify where that understanding is off?

@taqtiqa-mark commented on GitHub (Oct 13, 2025): I'll focus further comments in #2965. Relevant here is that `/add` should be a built in command, independent of how an agent is configured (`import_at: true,false`, where current default behavior is consistent with `import_at: false`, and that may/will change). I believe they are categorically distinct: - `/add`: A built in command. Importing text into a LLM's **Context** "buffer" - `@`: A DSL-style of convention, with configurable behavior that can vary by agent/sub-agent. Importing text into a LLM's **Prompt** "buffer" Can you clarify where that understanding is off?
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 13, 2025):

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?

@rekram1-node commented on GitHub (Oct 13, 2025): 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?
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@taqtiqa-mark commented on GitHub (Oct 13, 2025):

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?

@taqtiqa-mark commented on GitHub (Oct 13, 2025): > 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"](https://github.com/sst/opencode/issues/1990). 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**?
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@taqtiqa-mark commented on GitHub (Oct 13, 2025):

@ 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?

@taqtiqa-mark commented on GitHub (Oct 13, 2025): > @ 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?
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 13, 2025):

This issue is clearly targeted at https://github.com/sst/opencode/issues/1990. Can we keep the discussion about @ and the prompt text to the issue https://github.com/sst/opencode/issues/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:

https://github.com/user-attachments/assets/73c72250-52b5-4364-92e7-2b2cb63ac056

@rekram1-node commented on GitHub (Oct 13, 2025): > This issue is clearly targeted at https://github.com/sst/opencode/issues/1990. Can we keep the discussion about @ and the prompt text to the issue https://github.com/sst/opencode/issues/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 <hello> 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: https://github.com/user-attachments/assets/73c72250-52b5-4364-92e7-2b2cb63ac056
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@taqtiqa-mark commented on GitHub (Oct 13, 2025):

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...
@taqtiqa-mark commented on GitHub (Oct 13, 2025): > 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](https://opencode.ai/docs/tui#commands) 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](https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api#h_21d4f4dc3d): ``` {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... ```
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 13, 2025):

gotcha that makes more sense

@rekram1-node commented on GitHub (Oct 13, 2025): gotcha that makes more sense
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@taqtiqa-mark commented on GitHub (Oct 13, 2025):

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

@taqtiqa-mark commented on GitHub (Oct 13, 2025): > 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`
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@bf-frieder commented on GitHub (Nov 17, 2025):

Claude Code have a nice feature for it. Image

Image

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.

@bf-frieder commented on GitHub (Nov 17, 2025): > Claude Code have a nice feature for it. <img alt="Image" width="670" height="229" src="https://private-user-images.githubusercontent.com/536799/500005461-dfd71d6e-90fc-4e47-bb69-f9bf70861b0c.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjMzNjcwMjgsIm5iZiI6MTc2MzM2NjcyOCwicGF0aCI6Ii81MzY3OTkvNTAwMDA1NDYxLWRmZDcxZDZlLTkwZmMtNGU0Ny1iYjY5LWY5YmY3MDg2MWIwYy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMTE3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTExN1QwODA1MjhaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT02YzAyODc3MDY0MTc1Y2ZhOWU4NDUzOGQ5MGI5NTIzNjQ4YWI0NGIwM2I4ZDJlOGEwYzU2YTYwMTI1MDMxMGNhJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.fyYZC-_Tn31Ys_MvY9nti8C0F41RdHesimw60SO14_8"> > > <img alt="Image" width="562" height="456" src="https://private-user-images.githubusercontent.com/536799/500008500-7c4d32cd-09b0-4be7-b018-55fbf3d3124a.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjMzNjcwMjgsIm5iZiI6MTc2MzM2NjcyOCwicGF0aCI6Ii81MzY3OTkvNTAwMDA4NTAwLTdjNGQzMmNkLTA5YjAtNGJlNy1iMDE4LTU1ZmJmM2QzMTI0YS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMTE3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTExN1QwODA1MjhaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1lZWEzZTc4NmQ4MDMwMjZhMDMxZDNjMWIyMTVjMDc2YjZjNDA3MDUwMmY4ZTcwYWE5NzEwOGU3NTNjYTg0YTk3JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.zoM6Ky_CnNwT9eexG3U-gZfmA8SsKqxhJuKJlSOj3TE"> 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.
yindo commented 2026-02-16 17:30:28 -05:00
Author
Owner
Copy Link
Copy Source

@taqtiqa-mark commented on GitHub (Feb 5, 2026):

In the spirit of calling out excellent engineering and design....

I've found that the Pi Coding Agent is more robust and, for me has none of the issues that I've encountered in OC, or has an elegant way to resolve them.... I'm dropping out of OC issues:

@taqtiqa-mark commented on GitHub (Feb 5, 2026): In the spirit of calling out excellent engineering and design.... I've found that the Pi Coding Agent is more robust and, for me has none of the issues that I've encountered in OC, or has an elegant way to resolve them.... I'm dropping out of OC issues: - [Pi Coding Agent](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent) - [Overview](https://mariozechner.at/posts/2025-11-30-pi-coding-agent/) - [Example development session](https://www.youtube.com/watch?v=ANQ1IYsFM2s)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#1331
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?