[FEATURE]: Session context usage (similar to /context in Claude)

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

I would like to implement a simple tool - TUI dialog - that displays a breakdown of the current session's context window usage, answering the question "what is eating my context window". A feature similar to /context command in Claude Code, but leveraging TUI dialog to avoid obstructing the chat log.
Its purpose is to optimize the context usage by understanding what exactly is consuming it.

I build a quick PoC, and while the real token usage is difficult to get, the estimations seem good enough to be useful.

Would you be interested in having such feature in the core?

Here's the PoC implement as a dialog:

How does it work?

It exposes new server endpoint - /session/:sessionID/context that it then loaded in TUI when <leader>i key combo is pressed.
Token usage is estimated (4 characters per token) and then "calibrated" against the the actual total token usage reported by LLM provider. This is probably over-complicated, so I will play around with the methodology if this gets accepted.

It could be placed in the sidebar:

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

[Feature Request] Add User Controls for Context Management #1990: Add User Controls for Context Management - Proposes context management commands including a /tokens command to display token usage breakdown
Feature: status command #2995: Feature: status command - Requests a /status command similar to Claude that would show used context breakdown
[FEATURE] Sliding window context management for long-running sessions #4659: Sliding window context management for long-running sessions - Proposes an extensive context management system with a TUI context viewer that shows token usage breakdown
[FEATURE]: More Detailed Subagent's Context #3759: More Detailed Subagent's Context - Requests ability to see context size, tool calls, token usage, and context size for optimization

Feel free to ignore if your specific case differs from these existing requests.

I was just about to raise a feature request for this and found yours, amazing :D

@thdxr

@thdxr seems there is some interest for this. Would you accept the PR?

We need this feature because some times the agent generates chunks of code that just breaks the context, for example taking a screenshot on a model that don't support vision, or reading a whole react site and using it as context. Being able to edit/update/modify context after this happens is a must.

Love this!!!

I'm working on this, you can see here how it looks like to analyze the context of your last sent message. You can also see what opencode sends and to what models when it wants a title or summary generated.

I would be really interested to have this feature. It's not always easy to understand how much enabling or disabling an MCP server can impact the context.

+1 to this feature request.

I really need this feature to judge my skill and mcp costs

Already waiting for this feature to be included 🙏🏼

I would also like to see what the context was, not just the costs and usages. E.g. I want to drill down exact conversation, so I can see context bloat.

Is anyone working on this issue? I plan to develop this feature 'cause I really really need it

Would like to see this feature in OpenCode (especially side bar stat).

This would be a truly useful feature that would make me switch to Opencode from claude directly. I would love to see the usage per file.

Hello, I am bumping this issue and voicing my support for this feature request

This feature is important not only for context management, but also for cost control with OpenRouter / token-billed providers.

Right now OpenCode users cannot clearly see whether context is consumed by chat history, file attachments, tool results, MCP schemas, or system/provider metadata. For models like Kimi via OpenRouter, this can directly turn one task into a $1+ request.

Even an estimated context breakdown would be very useful:

model context limit
estimated context used
remaining context
chat/history tokens
attached file tokens
tool result tokens
MCP/tool schema tokens
compaction status
last provider-reported token usage

A TUI panel/sidebar would be ideal, but even a /context command would already solve a big part of the problem.

What make us delay this feature? So much needed for my context anxiety. Please.

There've been a few takes on this already (#24210 most recently) that got auto-closed without ever being reviewed. Before I redo that work, is this something you'd actually accept, and is there a shape you want?

I went digging through the code first and a decent chunk already exists: GET /api/session/:sessionID/context gives you the messages after the last compaction, and every assistant message already stores the provider's real token counts (input/output/cache). So the accurate total and the % used are basically free.

The part that has to be estimated is the per-category split: system, tools, chat history, tool results, file reads. I'd estimate those roughly (chars/4) and then get the system+tools overhead by subtracting the estimated history from the real input total the provider already reported. That way the overhead number stays grounded and I don't have to rebuild the whole system prompt to measure it.

Shape I had in mind: compute it in core (new context-usage.ts), put it on a sibling endpoint, TUI dialog on /context plus a leader keybind, and the desktop sidebar can reuse the same endpoint later.

One thing I'd want your call on: is an estimate (chars/4) fine for v1, or do you want a real tokenizer? I'd rather not pull tiktoken in just for this.

Happy to put up a small PR if the shape sounds right.

+1 to this feature.

Any activity on this issue? It would be a very welcomed feature.

I really liked context menus in other harnesses, so I built this extension in the meantime for opencode.

@tebayoso

Real-world case for why context visibility + management matters

@tebayoso's comment above already nails this:

We need this feature because some times the agent generates chunks of code
that just breaks the context, for example taking a screenshot on a model
that don't support vision, or reading a whole react site and using it as
context. Being able to edit/update/modify context after this happens is a
must.

Hit basically that exact scenario on opencode v2.0.18 (Desktop app, Windows),
confirmed by pulling raw message history via
opencode api get /api/session/{id}/message:

Agent's own tool-result screenshot persists and gets reused silently.
The agent called browser.screenshot (via Code Mode execute) to inspect
a running Electron desktop app. That screenshot is a tool-result file part,
rendered in the Desktop app transcript only inside a collapsible tool-call
row -- not as a visible chat image like a user-pasted attachment. Many
turns later, discussing an unrelated topic, the agent reused that stale
screenshot (combined with a Get-Process timestamp) to make a UI claim,
worded as if it were current. A later attempt to take a fresh screenshot
failed ([browser.operation_failed] browser.screenshot failed. Screenshot needs a visible tab...), and the agent fell back to the stale cached
image without flagging that explicitly.
User-pasted images from earlier turns get referenced in later unrelated
turns without being resent. Several images were pasted across different
user turns (files: 1 each, confirmed via the message API). On a later
turn with files: 0, the agent's reply said "latest image" / "the image
you sent", reusing an earlier turn's image. Technically correct (full
history is resent every call), but there's no way to tell which earlier
image is being referenced, and no way to drop a specific stale image once
it's no longer relevant -- short of a new session or a full /compact
(lossy for everything else too).

Without a /context view, there was no way to even confirm that this was
happening -- I had to query the message API by hand to prove the stale image
was still being resent. A context viewer (this issue) is the prerequisite for
any kind of selective cleanup (the related ask in #7712, now closed as
not-planned/duplicate -- but the underlying need is very much still live, see
this thread and #3759).

Environment:

opencode version: 2.0.18
OS: Windows_NT 10.0.26200 (win32 x64)
Client: Desktop app
Active plugins: opencode-browser

I totally agree that this /context command is necessary. Why OpenCode core developers don't consider this?

Navigation Menu

Repository navigation

[FEATURE]: Session context usage (similar to /context in Claude) #6152

Feature hasn't been suggested before.

Describe the enhancement you want to request

How does it work?

1 remaining item

Real-world case for why context visibility + management matters

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE]: Session context usage (similar to /context in Claude) #6152

Description

Feature hasn't been suggested before.

Describe the enhancement you want to request

How does it work?

Activity

github-actions commented on Dec 25, 2025

ramarivera commented on Dec 25, 2025

mtymek commented on Jan 4, 2026

tebayoso commented on Jan 10, 2026

eparreno commented on Jan 12, 2026

DeveloperJose commented on Jan 18, 2026

nesk commented on Feb 17, 2026

0xGurg commented on Mar 11, 2026

AvatarGanymede commented on Mar 11, 2026

jonathan5p commented on Mar 13, 2026

Ciantic commented on Mar 16, 2026

AvatarGanymede commented on Mar 16, 2026

1 remaining item

alxark commented on Mar 27, 2026

Djordje-Stojanovic commented on Apr 13, 2026

Alezander9 commented on Apr 13, 2026

mikhailfur commented on May 31, 2026

rhmndnt commented on Jun 12, 2026

theabecaster commented on Jun 20, 2026

enesgur commented on Aug 2, 2026

JakobHavtorn commented on Aug 6, 2026

ZackarySantana commented on Aug 7, 2026

tuan2linh commented on Oct 4, 2026

Real-world case for why context visibility + management matters

dppalomar commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions