Skip to main content

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

Request & Tool Metrics

Timing Metrics

Cost Metrics

Aggregation Metadata

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.