Overview
Every team exposes a single read-only team.usage property. It returns an AggregatedUsage view derived from the centralized usage registry on each access, scoped to this team’s team_usage_id.
Each member’s model calls — including sub-pipeline calls like memory summarization, reliability passes, culture, policy, and sub-agents — inherit the team scope and roll into team.usage automatically. Nested sub-teams contribute to their parent team’s view as well.
Accessing Team Metrics
Read team.usage on any Team instance. It always returns an AggregatedUsage — zero-valued before the first run, populated thereafter.
Token Metrics
Timing Metrics
Cost Metrics
Team Identity
Example
JSON-Friendly Output
Scope & Propagation
- Across members — Every team member’s model call records an entry tagged with the team’s
team_usage_id. Reading team.usage re-aggregates all of them.
- Per-member breakdown — Each agent still has its own
agent_usage_id. To see one member in isolation, read that agent’s agent.usage. The same entries contribute to both views (one entry, multiple scope tags).
- Sub-teams — When a
Team is nested inside another Team, the nested team’s entries carry both team_usage_id tags, rolling up into the parent automatically.
- Sub-pipeline rollup — Memory summarization, reliability validator/editor, culture, policy, and sub-agent calls dispatched by team members inherit the team scope via context variables.
- Retry idempotency — The registry is keyed by
entry_id. Retried requests replace their prior entry instead of double-counting.
- JSON snapshot — Call
team.usage.to_dict() for a flat dict suitable for logs and dashboards.
Per-Member Breakdown
Legacy Migration
team.usage is the unified entry point for all team-level metrics. There is no legacy team.total_cost / team.input_tokens / team.get_session_metrics() surface — team.usage was introduced as part of the centralized usage registry rollout.