Team collaboration overview

Team collaboration currently isolates workloads with projects, controls management permissions with member roles, and identifies the caller with team API keys. Define the resource boundaries first, then invite members and issue keys, instead of letting every application share one credential and one budget.

Resource relationships

Workspace
├─ Members and roles
├─ Project A (production)
│  ├─ Team keys
│  ├─ Model and routing policies
│  ├─ Budget
│  └─ Usage records
└─ Project B (test)
   ├─ Team keys
   ├─ Model and routing policies
   ├─ Budget
   └─ Usage records

Here “workspace” is the concept of a team organization, not another resource you must create. Projects are the current permission, budget and reporting boundary; a team key represents an application, environment, Agent or automated task. A member can take part in several projects, and each project membership should be authorized separately.

Recommended rollout order

Create projects per application and environment, for example customer-service-production and customer-service-staging.
Set a budget for each project, then set the routing mode and the allowed models on the team keys.
Invite members and assign the minimum roles required.
Create separate team keys for services, Agents and CI.
Use the usage records page to review cost, latency, errors and retries by project and key.
Configure budget, error-rate and abnormal-traffic alerts.

Common ways to split

Scenario	Recommended boundary
Development and production for one application	Two projects, two key groups, separate budgets
Several business teams	At least one project per business, members authorized per project
Several Agents	One team key per Agent, which makes limits and tracing easier
Outsourced or temporary members	Restricted project and role, removed as soon as the work ends
CI/CD	A dedicated key that exposes only the models and budget the deployment needs

Security and audit principles

Production services do not use personal keys.
Different applications, environments and Agents do not share a team key.
Admin permissions go only to the people responsible for projects, budgets or member management.
When a member leaves, revoke the keys they can access before removing the membership.
Traces and usage records keep request metadata for billing and diagnostics; the platform does not write prompts or completions to the database.
Periodically review unused keys, unusual costs, 429 responses, retry counts and unfamiliar model calls.

Next, configure projects and budgets, members and roles and team keys and usage.