Sume team usage: totals for all members, event rows for Admins

On a Sume team workspace, all roles can see team spend totals and the per-member breakdown, because the wallet is pooled. Only an Admin, through the usage.read_all capability, can open other members' individual usage event rows: model, job id, tokens and metadata. Creators and Members see their own events.

Why it is split

The capability comment in capabilities.ts gives the reason. Per-member spend totals are team information when everyone draws from one balance. The event log is the sensitive part, since it carries models, job ids and token counts. So usage.read_all is a separate capability, not folded into billing.manage. The billing role is collapsed to Member today, and a finance-only role has not shipped.

What each role sees

Where attribution comes from

Usage rows keep the acting member as the owner and the organization as the workspace. The wallet itself sits at a sentinel owner equal to the organization id. A job run by a teammate therefore shows that teammate in the ledger while the pooled balance pays. The team Usage page groups by member, and totals use every member's rows.

Two known limits

The channel hints on the team page come only from the viewer's own jobs, because the job list is still owner-scoped. For other members, older rows written before reservation channel metadata existed fall back to other. Also, spend caps and an audit-log UI are listed as later phases, so there is no per-member cap to configure today.

What to do

For a monthly review, an Admin reads the member table, then opens event rows for anyone whose spend stands out. If a producer needs to audit their own spend, their own rows are always visible. For API-level attribution across keys, use the key-level usage grouping rather than the team page.

Funding and concurrency context

Because the wallet is one pool, a single producer's heavy week draws down everyone's balance. Admin top-ups are the only way to refill it, and an unfunded wallet fails closed instead of using personal money. Organization workspaces also get a default generation concurrency of 10, rather than the free-tier limit, and the team's own subscription is read for the plan so admission and rate-limit tiers agree even though keys authenticate as the member who minted them.

If you need the numbers in a spreadsheet, pull them from the usage API per key and per day instead of copying the page, then join with the member table by hand. Keep the Admin who reads event rows to a minimum, because those rows carry model names and job ids that producers may consider part of their working notes.