Create one OpenAI project for each feature or use case that someone owns, keep development work in a project of its own, and give every deployment its own service-account key named for what runs it. OpenAI can group usage and cost by project and by API key, so with this layout its reports show which feature spent the money. OpenAI doesn't record what a project is for or who owns it, so keep a short register alongside.
How organizations, projects and API keys fit together
| Level | What it holds | Who creates it |
|---|---|---|
| Organization | Billing, members, Admin keys and organization-wide limits | Created with the account |
| Project | Members, API keys, service accounts, model access, per-model rate limits, spend alerts and limits, and stored files, vector stores and assistants | Organization owners |
| Service account | A non-human member of one project, which owns keys for workloads | Organization and project owners |
| API key | Starts with sk-proj- and belongs to one project. Owned by a user or a service account, with All, Restricted or Read Only permissions | Project members, unless the organization restricts key creation |
An organization can have up to 2,000 projects by default. Projects can be archived but not deleted, archiving is permanent, and OpenAI keeps each project's history for usage and billing. Every organization also has a Default project, which can't be deleted and can't have members or service accounts added to it directly.
Create one project per use case
Make a project for each thing the company does with AI that one person could own: the support assistant, the document pipeline, internal search. Organize by use case rather than by team. Teams get reorganized and use cases outlive them, and a team that runs two features needs two projects if the bill is going to tell them apart.
Name projects the way people talk about them, "Support assistant" rather than "backend-svc-2". The name is what you'll see in the usage dashboard and in every CSV export.
Production workloads shouldn't stay in the Default project. Service accounts can't be added to it directly, so deployments there tend to run on someone's personal key.
If you need cost per customer and have a handful of large ones, a project or key per customer fits within the default limit. With many customers, record a customer ID in your own request logs instead. Our post on tracking AI API costs per feature, team or customer compares the options.
Keep development out of production projects
Evals, prototypes and experiments cost real money, but they shouldn't make a production feature look expensive. Either give each use case its own development project, or put all non-production work in one shared Development project with its own spend limit. The shared project is simpler and enough for most teams. That's also where user-owned keys belong: OpenAI's guidance is that a personal key is for your own development and shouldn't be the identity of a production app.
Give each deployment its own service-account key
For anything that runs unattended, create a service account in the project (Organization settings, select the project, then Members and + Service account) and use its key. A personal key in production stops working when its owner leaves the project, and it makes one person look responsible for a workload.
Create one key per deployment: per service and environment, and per region if you run more than one. Since August 4, 2026, OpenAI's usage and cost dashboards and APIs can filter and group by API key, so with a key per deployment you can see which deployment moved the spend. Name keys for what runs them, in a fixed pattern such as support-assistant-prod-api. Our guide to OpenAI costs by project, key and model shows where those names appear.
Three more settings are worth turning on:
- Restrict permissions to what the workload uses. A new service-account key can read and write everything in its project by default, so edit it in the project's API Keys settings after creating it.
- Set an expiration date. Project keys can have one since September 2026, and administrators can enforce a maximum lifetime for the organization or a project.
- Limit who can create keys. Since September 15, 2026, organizations and projects can allow only service-account keys, only user-owned keys, or no new keys at all.
Storage, rotation and what to do after a leak are covered in OpenAI API key security.
Set model access, rate limits and spend limits per project
Each project has its own guardrails. Model access, rate limits and spend limits are on the project's Limits page: Organization settings, select the project, then Limits.
| Setting | What it does |
|---|---|
| Model usage | Allows or blocks specific models, so a project meant for a small model can't switch to a large one by accident |
| Rate limits per model | Caps requests and tokens below the organization's limits, so one runaway job can't take the whole organization's capacity |
| Monthly spend limit and alerts | Emails project and organization owners at the thresholds you set. A new limit gets an alert at 100%, and Add Alert adds more |
| Enforce a hard limit | Makes requests fail with a 429 error, project_spend_limit_exceeded, once tracked spend reaches the limit |
| Service tiers | Since October 21, 2026, restricts which service tiers the project can use, set in Platform settings |
Turn on hard limits only for work that can tolerate failed requests, and keep in mind that OpenAI says enforcement isn't instantaneous. The guide to OpenAI spend alerts and limits covers how to size them.
Write down what each project and key is for
OpenAI holds the projects and keys but not their purpose or owner. Keep a register with one row per project and key: the use case, the owner, the models you expect and a monthly budget. When a key with spend appears that isn't in the register, ask about it first.
| Project | Key | Use case | Owner | Expected models | Monthly budget |
|---|---|---|---|---|---|
| Support assistant | support-assistant-prod-api | Drafting replies to support tickets | Support engineering lead | One mid-size model | $6,000 |
| Invoice extraction | invoice-extraction-prod-worker | Reading supplier invoices | Finance systems lead | Small model, Batch API | $1,500 |
| Development | User-owned keys | Evals and prototypes | Platform lead | Any | $800 |
An illustrative register. The projects, keys and budgets are made up.
How to move off a single shared project
If everything runs in the Default project today, move one use case at a time, starting with the most expensive. It has the most spend to explain, and the first move shows you what the rest will involve.
- Create the project, its service account and key, and set its model access and spend limit.
- Recreate anything the service stores in OpenAI. Files, vector stores, assistants and threads belong to their project and can't be moved. Fine-tuned models in the Default project are the exception, since other projects can use them.
- Deploy the service with the new key.
- Group usage by API key in the usage dashboard and watch the old key's usage for that service fall to zero.
- Revoke the old key once nothing uses it.
The service's earlier usage stays with the old project, so its spend history splits on the day of the move. Note the date in your register.
Common questions
Should I use one OpenAI project per environment or per feature?
Per feature for production, so each project's spend belongs to one use case. For non-production work, one shared Development project with its own limit is usually enough. Separate staging projects per feature are worth it only when staging traffic is large enough to matter.
How many API keys should an OpenAI project have?
One service-account key per deployment, plus user-owned keys for the developers working on it, ideally in a development project. A key shared by several services makes usage by key hard to read, and a leak of that key means rotating it everywhere at once.
Can I move an API key or files to another OpenAI project?
No. Keys are created inside a project, and files, vector stores, assistants and threads stay in the project they were created in. Moving a workload means creating a new key in the new project and recreating its stored resources there.
Can I delete an OpenAI project?
No. Projects can only be archived, archiving is permanent, and OpenAI keeps the history for usage and billing. Archived projects are listed on the Archived tab of the Projects page.
Where Braid fits
Braid keeps the register as part of the product. It calls each use case an Implementation and maps the OpenAI projects and keys behind it, with an owner, a team, the models it's expected to use and a monthly budget. Spend from keys that aren't mapped yet shows up as unmapped usage, and every Monday Braid emails a report of last week's spend by Implementation.
Braid reads through a read-only Admin key. It doesn't create projects or keys, and it doesn't change any of the settings above, which stay in OpenAI.