Projects
Understand AI Studio projects: members, API keys, model access, usage, and budgets
A project is where day-to-day AI work is grouped in AI Studio. Each project has its own members, API keys, model access, usage, and optional monthly budget.
Projects belong to your organization. Use them to separate environments (prod, staging, experiments), teams, or clients. The active project is what the sidebar and dashboards scope to. Switch it from Projects in the sidebar anytime you belong to more than one.
What a project contains
Each project is self-contained:
- Members: users you invite to the project, as a member or an owner
- Model access: which models API keys in this project are allowed to call
- API keys: all keys belong to exactly one project and inherit its model access
- Usage and activity: request logs and spend roll up per project
Keys and model access do not bleed across projects. A model enabled in Project A does not apply to Project B unless someone configured it there too.
Structuring projects and API keys
A project is the boundary that keeps work separate in AI Studio. Your API keys, model access, usage, and budget each attach to exactly one project. A key inherits its project's model access, spends from its project's budget, and shows up in its project's usage. There is no environment field on a key, and no per-key budget or model limit, so anything you want to isolate needs its own project.
Recommended default: one project per environment
Model each environment as its own project, and put the environment in the project name. For an app called my-app, create my-app-test, my-app-acceptance, and my-app-prod. Issue keys inside the project that matches the environment they serve.
Two ways to lay this out
| Layout | Project | Keys | What it isolates |
|---|---|---|---|
| One project per environment (recommended) | One per environment, for example my-app-prod | One or more inside each project | Budget, model access, usage, members, and key rotation, per environment |
| One project per use case, keys per environment | One per use case, for example my-app | One per environment, for example prod and test | Nothing beyond the keys themselves; every environment shares one budget, one model-access set, one usage rollup, and one member list |
Why one project per environment
Keys, model access, usage, and budget all bind to the project, so the project is the finest unit you can isolate. Laying out one project per environment gives you:
- Separate budgets: cap production spend, or leave it open, without capping test, and the reverse.
- Separate model access: let test try a new model while production stays on a locked allow-list.
- Separate usage: read production activity and cost without test and CI traffic mixed in.
- Separate members: give QA access to test and acceptance only, not production.
- Separate keys: rotate or revoke a test key without touching production.
Worked example: an OTAP setup
An app called my-app runs four stages: development, test, acceptance, and production. Map each stage to its own project in your organization.
| Project | Stage | Model access | Budget | Members |
|---|---|---|---|---|
my-app-dev | Development | Full catalog | Unlimited | Engineering |
my-app-test | Test | Full catalog | Unlimited | Engineering, QA |
my-app-acceptance | Acceptance | Production allow-list | Low cap | Engineering, QA, product |
my-app-prod | Production | Production allow-list | Real spend cap | Operations only |
Within each project, create keys by function, such as backend and batch. Key names only need to be unique inside their project, so you can reuse the same name across environments.
When keys per environment is enough
If environments need no isolation at all, a single project works: same models, same budget, same members, and pooled usage, with separate keys only so you can rotate them independently. Most teams want at least production isolated for budget and access, so the default above is the safer starting point.
Naming
Project names are unique within your organization and can be anything, so make the environment part of the name. -dev, -test, -acceptance, and -prod is a clear convention. Keys are named freely and only need to be unique within their project.
Project roles
Set per person under Settings → Project → Members (and during invite flows that add people to a project).
| Role | What it means |
|---|---|
| Owner | Manages this project: teammates, model access, rename, archive, and budget. Can do everything a member can. |
| Member | Normal build and operate work: create API keys, call models, view dashboards for this project. Cannot change project members, model access, or budget unless they are also an owner. |
| Viewer | Read-oriented access to project data; how prominently this role appears in the UI may vary. |
Organization owners always have full access to every project, whether or not they appear on that project's member list.
Quick reference
| Organization owner | Project owner | Project member | |
|---|---|---|---|
| Day-to-day work inside a joined project | ✓ | ✓ | ✓ |
| Manage project people, model access, and budget | ✓ | ✓ | — |
| Create or archive projects, org-wide billing and analytics | ✓ | — | — |
Usage and cost
Qualified inference traffic tied to your API keys automatically appears in AI Studio; you don't toggle metering on anywhere.
| Where in Studio | What it shows |
|---|---|
| Inference → Activity log | Request trail for the active project: when, which key, which model, outcome, and volume |
| Inference → Usage | Aggregates for a period, often split by model or key, scoped to the active project |
| Settings → Organization → Usage (organization owners) | Compare projects side by side at organization scale |
Usage totals may include estimated spend depending on your subscription. Treat these as indicators, not your invoice. Failures (4xx/5xx) usually still appear in activity logs, which helps when debugging integration issues.
For organization-wide billing and cost roll-ups, see Organization.
Monthly project budget
Project owners and organization owners can set a monthly spending limit for a project under Settings → Project → Budget. This helps prevent accidental overspending by capping how much a project can consume in a calendar month.
- Usage resets at the start of each calendar month.
- Budgets are set in whole euros, with a minimum of €10.00.
- Leave budget unset for unlimited usage within your organization's subscription.
When a project's budget limit is reached, further API requests using keys belonging to that project are denied with HTTP status code 429.
Best-effort enforcement
Budget limits are enforced on a best-effort basis. Usage totals are updated asynchronously, so there may be a delay between billed requests and the consumption shown in Studio. A project can exceed its budget until aggregated usage reflects recent activity.
See Organization for how organizations, billing, and projects fit together.