Show token usage and estimated cost per thread

[stoivo]

I’d like to see how many tokens each thread has consumed and its estimated cost, so I can understand the expense of individual tasks and compare model choices.

Ideally, each thread would have a compact usage summary showing:

• Total token usage, with input, output, and cached tokens where available.
• Estimated API cost, clearly distinguished from actual billed spend for subscription accounts.
• A breakdown by model when multiple models are used in the same thread.

A thread breakdown on the Usage page would also be useful. Maybe link from the thread too.

It has been implemented in #9017 but I want to open a discussion in case PR gets closes or too stale.

It think the UI implemented looks fine.

Related work:

• feat: add usage / quota visibility for Codex sessions and accounts #228 previously requested per-thread usage alongside account quotas.
• feat(usage): add thread and subagent breakdown #9016 proposes thread and subagent breakdowns on the Usage page.
• feat(web): show thread API cost in composer #9136 proposed a thread cost indicator in the composer and was closed pending the V2 rewrite.

Could this issue track the feature request through V2, independently of those implementation PRs?

Also somewhat related to #6683

[pantharshit007]

posting for ref

[ZaBug]

+1. Folding in details from my closed duplicate #15043 (V2-specific):

• Cost source priority: prefer the provider-reported figure (Claude's result total_cost_usd, the same number the CLI status line shows), fall back to the LiteLLM estimate (with usagePriceOverrides), and label which one is shown.
• Placement: a "Thread cost" row in the existing Context Window popover under "Total processed", plus an optional compact composer badge ($1.4 · 32%).
• Settings in the UI (Settings → General, next to the context window indicator): show thread cost, show composer badge.
• Budget line: when a gateway budget source is configured (Generic HTTP `usageLimitSources` kind for gateway / proxy spending budgets #15042), show "Monthly budget $42 / $1000" in the same popover.
• Open question: total_cost_usd is cumulative per CLI session and resets on resume. Sum across sessions, or switch to the estimate?

[ajbarryiii]

I’d like to contribute a narrowly scoped version of this for V2. I run multiple long-running threads and want to see which threads account for my usage.

The proposed UI would mirror the existing Hour breakdown: one row per thread, showing its name and either estimated cost or tokens according to the existing metric toggle. A green dot would indicate threads that are currently running. It would reuse the existing period and environment filters.

I would leave out subagent drill-downs, project reporting, additional charts, and custom date controls. Usage that cannot be reliably attributed would remain explicitly accounted for.

Would a maintainer approve this direction and scope for a contribution before I start implementing it? Are there any constraints or existing work you would prefer me to build on?

[stoivo]

Now I think the most value is from cost per thread. Do get a feel for how much. Maybe tokenscount too

[ajbarryiii]

I mean cost per thread and tokens per thread are essentially interchangeable. Just a simple multiplier once you have the model price, number of input output and cache tokens.

[ZaBug]

Follow-up to my comment above with a working V2 prototype (dummy data, local mock):

Before / after: Context Window popover

• Thread cost prefers the provider-reported figure (Claude's total_cost_usd, stored per turn as a delta so resumes don't double-count) and falls back to an estimate at Usage prices with usagePriceOverrides. The label says which one is shown.
• Optional composer badge ($1.00 · 6.8%), off by default.
• The Monthly budget line only appears when a gateway source from Generic HTTP `usageLimitSources` kind for gateway / proxy spending budgets #15042 is configured.

Settings → General, next to the context window indicator:

This complements the per-thread breakdown on the Usage page proposed above; it answers "what has this conversation cost" from inside the thread. Happy to scope a PR to just the popover row if a maintainer approves.

[pantharshit007]

@juliusmarminge @t3dotgg @maria-rcks can anyone look into this, we can include this in the V2 stable release.

[maxvandongenTikkie]

Added by GPT-6.1 Sol via OpenCode in T3 Code, on behalf of @maxvandongenTikkie.

I’m using T3 Code nightly with OpenCode V2 and GitHub Copilot. OpenCode’s terminal displays estimated cost, and I’d like similar visibility directly in the T3 thread, without opening the aggregate Usage page.

My preference is a small cost indicator in the thread header or composer, updated after each completed turn, with more frequent updates where supported. This should be a shared feature across providers where sufficient data is available, with clear labelling for estimates, partial coverage, or unavailable data—not a misleading $0.00 when cost is unknown.

The displayed amount should explain its scope, particularly whether it includes native subagents or T3-delegated work and whether it remains cumulative when switching providers within a thread. If only the current native provider session can be measured, that should be explicit in the tooltip.

I’m looking for usage-cost awareness, not subscription billing or quota tracking. An after-turn indicator with honest scope and coverage would already meet my need; continuous live updates could be optional.

For context, this was investigated on T3 Code 0.0.46-nightly.20261007.2774 with OpenCode v2.0.20. No implementation changes were made.

[maxvandongenTikkie]

No implementation changes were made.

Happy to see I didn't make any changes with this comment 😂

[Blackskyliner]

I would also really like to see how many token a thread consumed, especially to get a feeling for how good or bad a certain workflow is, when changing or testing ai workflows in general.

But we also need to consider that it would need to be a sum of all sub-agents too.
Which sometimes do get duplicated context which would bloat the general token estimate.

Also as if using another model the cache would not be shared and as such the cost could not be calculated correctly, or am I wrong?
Can we read that info from the sub-agents context commands, how much of a certain agents context was cache read/write or not?
Because not only tokens in general are the interesting metric, but also how much of it was cached reads/writes in that thread, as all that also affects cost of a whole thread.

[pantharshit007]

Opencode shows you your current thread usage in there TUI, now in opencode V2 they also introduced sub agents so they must have find a way to efficiently calculate it, who ever work on this can look into it.

[YHKCyber]

I independently thought of this today, and my agent found this discussion while researching it. I’d love to see it upstream too—especially an on-demand “See chat usage” action in the chat’s right-click menu, or a slash command, showing tokens and estimated cost for that conversation.

[darox]

I need this cost visible in the thread itself, not only on the aggregate Usage page.

The context meter popover is the right place. It should show a live Session cost for the current thread and update after each completed turn. Keep the total when the thread resumes, changes provider sessions, or compacts its context.

Use only the cost that the provider reports. If a provider or model has no price, show Unpriced instead of $0.00. If the total contains unpriced turns, show that condition next to the total.

This remains separate from the Usage page. The Usage page answers "how much did I spend overall?" The thread indicator answers "what has this thread cost so far?"

[ronimuliawan]

FYI guys, this could easily be solved by using tokscale while waiting for the discussion to kick off.

[LightCC]

I'd like to contribute as an idea, a per-turn breadcrumb that shows time run, tokens and cost, similar to what Copilot does:

They put the time run at the top instead of the bottom (where it is much more convenient), and don't include tokens. Tokens is also complicated by input/cached/output/etc. but even just the total is helpful to me. That or maybe the context amount at the start of that turn would all be useful as a breadcrumb.

This helps tremendously with reporting both good and bad cost and total run times you achieved to the team and management, especially when calibrating to new models, etc.

[bradenbiz]

One stretch idea for this: after a long autonomous run, I'd like to ask the agent roughly how much of my weekly subscription allowance that thread used. This isn't particularly important—just food for thought alongside the thread usage work here.

The goal wouldn't be an exact percentage. I'd just like to know whether one thread has been taking up a large share of my usage, so I can decide whether to keep it running or change how I'm approaching the task. Something like “this thread used roughly a quarter of your estimated weekly allowance” would be useful even if it's approximate.

Could the thread's API-equivalent usage be divided by an estimated weekly API-equivalent allowance for the selected plan? I'm thinking of the same kind of figures Theo uses when comparing subscription value. The baseline could be configurable and dated, with the result clearly labeled as an estimate since model mix, caching, speed and plan changes could affect it.

PR #34338 already proposes the thread cost calculation. This would use that as an input to answer the subscription-percentage question. It would help if the agent could read the estimate too, and if the report made clear whether delegated work was included.

I'm not asking for precise billing or a guarantee that it matches the provider's usage meter. Just a rough indication that a particular thread is consuming a meaningful chunk of the allowance. No worries if that adds more complexity than it's worth!