Web: break Usage down by project, thread, account and environment #16722

Following this existing request rather than opening a duplicate. We checked nightly 0.0.46-nightly.20261012.3010 against d83929a: the native environment filter is useful, but usage buckets do not carry project/thread attribution and configured provider history can include multiple projects and activity outside T3. One environment per project with the same provider history would therefore not provide reliable project accounting.

Our useful minimum is native project attribution with an explicit unknown/outside-project group and retained source coverage/as-of information. Recorded tokens and API-equivalent estimates should remain distinct from subscription quota/reset and actual billing; shared history/accounts must retain native deduplication. Discussion16722 and open PR15902 already address the attribution need, so we will track them and document the installed limitation without building another accounting layer or assuming the unmerged feature is available.

I'd like this too. In Theo's videos, I've often seen him open a thread to ask for project metrics. Having those numbers available directly would avoid spending more tokens asking an agent to collect and summarize them.

For a selected project, the useful minimum would be:

• Total tokens across its threads and worktrees, including attributable subagent usage without double-counting.
• This month's usage, previous calendar months, and a selectable date range, so monthly comparisons are easy.
• Input, output, and cache breakdowns, plus provider/model and thread breakdowns where available.
• Estimated API-equivalent cost, clearly distinguished from actual subscription charges.

A project metrics page or a project filter on the existing Usage page, linked from the project, would both work. Opening or refreshing it should use recorded usage data and ordinary aggregation, without invoking an agent. Incomplete or unavailable data should be marked clearly.

I initially filed this as #27055. This existing Ideas discussion covers the request, so I'm adding the use case here and closing that issue.

Adding my support for this proposal. I use T3 Code for long-running threads with multiple subagents, and I'd like to see how many tokens a specific thread consumed, including its subagents.

The overall Usage dashboard and context-window meter don't answer that question. A per-thread total, ideally with an input/output/cache breakdown and without double-counting subagent usage, would be very useful.

This is a feature I'd appreciate having directly in T3 Code, without needing to ask an agent to reconstruct usage from local history.

+1, mostly for the account and environment part.

I use T3 on more than one machine and with more than one subscription, and the Usage page sums everything. The question I open it for is simple: how much did each subscription use, in tokens, cost and limits, and on which machine. Today I can filter by environment, but I can't see them side by side.

If the full proposal is too big to approve at once, maybe the per-account slice from #27154 is a good first step: an optional instance on each usage source and sub-rows under each provider. Small, additive, and older clients keep working.

I'll open a separate Ideas post for a daily heatmap view, since that one doesn't need any server change.

Adding another concrete use case to this existing proposal rather than opening a duplicate.

I use T3 across a remote environment and a local WSL environment. In Usage → Tokens, I'd like to see:

• Tokens per project, with drill-down into its threads and attributable subagents, plus explicit groups for threads without a project and usage that cannot be attributed.
• Input, output, and cache breakdowns over the same selected time range, with each project's share of the recorded token usage clearly labelled.
• One combined view across environments and an environment breakdown/filter, without counting shared or copied provider histories twice. Offline or incomplete sources should retain visible coverage/as-of information.

A related need is configurable personal budgets on a shared subscription: for example, someone wanting to keep their own activity within roughly 20% of the subscription's weekly allowance. This needs attribution from that person's recorded usage, not simply a check of the shared account's overall percentage while their threads happen to be active. It would help to distinguish advisory warnings from an enforced stop on new work, and to define what can actually be measured and enforced across connected environments.

This should not assume that 20% of recorded tokens equals 20% of a subscription's quota. Provider limits can have several windows/model pools and include activity outside T3. Where precise attribution or enforcement isn't available, the UI should say so rather than imply a guaranteed cap.

Project/environment attribution would already be valuable independently of budgeting. Is #15902 still the intended path for that part? Are there plans for an external read-only usage interface or an extension point so users can build reporting without maintaining a core patch?

@juliusmarminge, asking you because you closed #9015 with "discuss the project-reporting scope with a maintainer", and CONTRIBUTING now says a feature from outside the team needs a maintainer to ask for it.

One question: do you want per-project usage in T3 Code from an outside PR? A yes or a no is all I need.

If yes, the smallest piece is ready as #29931: a Project option under Breakdown on the Usage page, next to Model and Day. It is 914 added lines across the server, the shared merge, web and mobile, tests included. One read-only query per scan through the project store; the new summary fields are optional, so older clients and servers are unaffected; no scan-cache or contract-version change. Before and after captures from real builds of main and the branch are in the PR.

Everything else in this proposal (threads, accounts, environments, offline usage, zoom) is out of that PR. I have closed #15902, the 8,000-line version, so it is no longer in your queue, and I will only bring another piece back if you ask for it.

If no, I will close #29931 and leave it there.

Prior effort on the thread-local side of this question: #31821 (timing flame chart), #32261 (tokens/cost by turn), #32303 (context occupancy).

What we learned trying it

• Global Usage answers “which provider spent money.” Thread Insights answers “why was this thread slow/expensive.” Both are needed; stacking cost onto a timing flame chart is how operators actually debug a runaway turn.
• Performance traps: a 1s now tick that rebuilds the whole trace on idle threads, and priceUsage keyed on the full items array (refetch + blank costs on every token). Subscribe to the tick only while something is live, and stabilize/chunk pricing queries.
• Prefer active time (working/waiting/tooling) over wall-clock idle in headers and rulers, or long parked gaps dominate the chart.