Review member usage and visibility
Review readable, recorded Runs, Tokens and model usage while respecting private Runs and controlled content access.
Usage records explain which recorded executions consumed resources, not how much work an employee accomplished. Run counts are neither task counts nor measures of productivity or employee performance.
Prerequisites and permissions
- This guide describes the current Console's team-management interface. Confirm that your deployment provides Team → Member usage and check the target workspace. Source-code support does not establish business acceptance in that deployment.
- The current Team navigation is for platform administrators. Workspace administrator status alone does not guarantee access to that navigation. Workspace access and Run reads still require server authorization; a platform operations role does not automatically grant team-governance access.
- Runs must already have been recorded by the observability pipeline. The page summarizes records that the current account can read and that the query returns, not every entry point, time period or employee activity.
- Reading aggregates does not require Prompt or Response content. Check Roles and permissions first; do not widen content access just to inspect consumption.
Steps
- Sign in to your organization's Console and confirm that the workspace in the address is the one you intend to manage.
- Open Team at the bottom of the sidebar, then Overview. The page heading is Team dashboard. Select This week or Last 30 days in the reporting-period control. The current “This week” implementation filters the last seven days, not a calendar week or monthly quota period.
- Inspect members, Tokens and model distribution. Click Export if you need to retain this aggregate, and handle the CSV under company policy. Exporting does not expand data permissions or export raw conversation content.
- Open Member usage in the team sidebar. Review members, task totals/succeeded/failed, Tokens, cost and frequent models. Attribution groups Runs by their Owner user identifier; the frequent model is determined by recorded Token consumption.
- Record the workspace, operator, query time, page scope and any gaps. Member usage currently has no reporting-period selector equivalent to Overview's; do not treat the two pages as reports for an identical period. Continue to Tokens and estimated costs for cost interpretation.
The Console route patterns are /w/{workspaceId}/settings?section=team-overview and /w/{workspaceId}/settings?section=team-members. Use them to check your organization's product address. They are not website documentation links and cannot bypass authorization.
Interpret the results
| Displayed information | What it establishes | What it does not establish |
|---|---|---|
| “Task” totals, succeeded and failed | Returned Run counts and their completed/failed statuses | Distinct Task counts, delivery quality or employee output |
| Tokens | Recorded input and output Tokens in readable Runs | Complete capture of every model call, or greater contribution from greater consumption |
| Frequent models and distribution | Models and Token distribution in these records | Every model a member may use, or the model a future execution will select |
| Cost | A USD estimate calculated from catalog prices | A provider invoice, complete spending or a promise of free usage |
No records can mean no activity, missing collection, records outside the query range, expired retention or insufficient visibility. It does not by itself mean “not using AI.” A loading or request failure is not evidence of zero usage either.
Private Runs and content access
Private development-machine Runs with workload kind development_machine are readable only by their owner. Team-administrator status does not open another person's private Runs. Team pages are not a complete team-wide aggregate of all private development-machine activity.
Visibility of execution statistics does not grant Prompt/Response content access. Outside another person's private development-machine scope, content reveal requires an explicit request and an Owner or qualifying administrator permission check. Access must be audited; if the audit fails, the read is denied. Being authorized also does not guarantee content is still retained or available. Neither “administrators can read all private content” nor “administrators can never read content” is the rule.
This guide does not invent a “click a member to read every conversation” procedure. Diagnose consumption using Run identifiers, status, model and usage before requesting content, and do not bulk-copy content into management reports.
Verification and troubleshooting
- Entry and scope: confirm the workspace. If the entry is missing or denied, ask the identity administrator to check roles and membership. Editing the URL is not an authorization workaround.
- Attribution and counts: choose an existing, readable Run with an Owner and check its member attribution. Align time, query scope and permissions before comparing totals. “Succeeded” confirms only execution status; validate delivery through result review.
- Empty values and failures: distinguish loading, failed requests, valid empty results and missing data. If the page does not expose the uncertainty, ask authorized platform operations staff to inspect the records rather than inferring zero.
- Privacy and auditing: permission acceptance should confirm that administrator status does not open other members' private development-machine Runs. For failed content reads, check authorization, retention and audit availability separately. Do not disable auditing to restore access.
Limits
Usage trends can support adoption and resource analysis. Linking them to business outcomes requires separate goals, delivery evidence and human acceptance; execution counts cannot replace those checks. Aggregates, exports and content reads neither expand existing permissions nor guarantee record coverage across every work entry point.