Projects
The unit everything hangs off: keys, budgets, members, usage and an audit trail.
A project is a named container for API access. Every API key belongs to one, and that is the constraint the rest follows from.
Find them under Platform in the app sidebar. An organisation administrator can create them, and can allow others to.
Why every key belongs to one
Because "who spent this, and can I turn it off without turning everything off?" is the question you will actually be asking in three months.
A key that belongs to a project inherits an answer to all of it: what it is for, who may use it, how much it may spend, and what it has been doing. A loose key answers none of that, and revoking it is a guess about what breaks.
The practical shape most teams land on:
- One project per environment: Production, Staging, Development. Different keys, separate spend, and rotating the staging key cannot take the website down.
- One project per product surface when several teams share an organisation, so the mobile app's usage is legible on its own.
Splitting by environment first is the one that saves you. Splitting by team as well is optional, and worth it once "why did the bill double?" is a question somebody asks.
What a project holds
Open one and you get eight tabs.
Overview is the summary you will look at most: how many API keys, when it was created and by whom, and for the last 30 days the request count, estimated cost and average chat latency. Plus the budget, if one is set.
API keys creates and revokes the keys scoped to this project. A new key is shown once, at creation. Copy it then, or make another.
Members decides who can see and administer the project, with a role each. Adding somebody here does not create an account: they must already be in the organisation.
Usage is the detailed breakdown behind the Overview figure.
Logs is what the project's keys have actually been doing.
Evaluation ties evaluation runs to the project.
Resources is what the project owns. Worth knowing that a collection or an agent can be owned by a project rather than by a person, which is the right answer for anything a team depends on: it does not leave when its author does. See Sharing your work.
Settings is the name, description, budget and archival.
Budgets
A project can carry a monthly budget, and the Overview shows what remains, what is used, or that it is exceeded.
A budget covers what your organisation spends through us. If your organisation runs models on its own provider keys, that spend appears separately and the budget does not limit it. The Overview says so where it applies.
Worth reading twice before treating a budget as a hard ceiling on everything.
Recent activity
Each project keeps an audit trail: members added, removed or re-roled, API keys created, revoked or toggled, settings updated, the project archived or restored.
This is the thing you want when a key you did not expect is in production, and it is retrospective only, so it does not prevent anything. Which is the argument for the next section.
Archiving
Archive deactivates every API key in the project at once.
It is the correct way to retire a surface: one action, no hunting for keys, and the usage history stays readable. A project can be restored with Unarchive, and its keys do not come back to life on their own.
Administrators can see archived projects in the list; everyone else sees only active ones.
Keys, briefly
Two kinds, and the distinction matters more than it looks:
Project keys (sk-ast-…) call /v1/chat/completions, /v1/models and /v1/agents. This is what goes in your application.
Admin keys (sk-ast-adm-…) call everything under /v1/organization/: creating projects, managing users, reading org-wide usage. An organisation administrator makes them under Settings then Admin API Keys.
An admin key can add users and mint project keys. It is not a "more powerful" project key, it is a different thing, and it does not belong in an application that only needs to send chat messages.
If you find yourself using an admin key to call /v1/chat/completions, something has gone wrong in the setup.
Managing projects over the API
Everything on this page has an endpoint, under /v1/organization/projects, callable with an admin key: create, retrieve, update, archive, plus members, keys and usage. Useful when environments are provisioned from a pipeline rather than by hand.
See Projects, Project keys and Project members under Endpoints in the sidebar.