Organizations and Projects

Organizations and projects provide the main control structure for enterprise customers.

Organization layer

An organization is the top-level container for:

Area	Typical organization-level ownership
Members	Invite, remove, and govern users across the organization
Projects	Create project boundaries for teams, environments, or workloads
Billing	Own plan, invoices, renewals, and finance contacts
Settings	Define organization-wide defaults and governance preferences
Security policies	Control SSO, session policy, and other enterprise access requirements

The organization creator becomes the first Admin.

Project layer

Projects create operational isolation inside one organization.

Use projects to separate:

Separation target	Example
Teams	Support, product, data, internal tools
Environments	Development, staging, production
Workloads	Chat, extraction, media generation, batch jobs
API keys	Different keys for each project or environment
Usage views	Cost and usage attribution by owner or product line

Why projects matter

Projects solve three real problems:

knowing which usage belongs to which team
letting project owners manage their own resources
keeping cost attribution clean

Practical model

One user can belong to multiple organizations and multiple projects. A project owner should only see and manage the project context they own, while the organization admin sees the full org.

Suggested project designs

Company shape	Suggested structure
Small team with one product	One organization with separate `development`, `staging`, and `production` projects
Multiple product teams	One organization with one project per product or team, plus separate production keys
Agency or service provider	Separate organizations or projects per client, depending on billing and access boundaries
Security-sensitive deployment	Separate projects for high-risk workloads, with narrower keys and stricter owner review

What to avoid

Anti-pattern	Risk
One shared production key for every team	Hard to rotate, audit, or attribute usage
Mixing development experiments with production workloads	Test spikes can consume production limits or hide incidents
Giving every user organization admin access	Key, billing, and member changes become hard to govern
Creating too many projects without owners	Alerts, invoices, and usage reports become unclear

Suggested mental model

Organization owns policy. Project owns execution context.

Before launch, document each project owner, key owner, primary workload, expected spend pattern, and escalation contact.