Projects#

A project is a home for one AI deployment: an application, a pipeline or a pilot that calls ATLAS. It has its own API keys, allowed models, standing configuration, funding and members.

Projects and spaces#

A space groups people and gives them a shared budget. A project groups a deployment. Two kinds of caller reach a project:

Caller	Credential	What applies
A service	A project API key, owned by the project	Allowed models, standing instruction, request defaults and funding
A person	A personal key acting under the project	Allowed models, request defaults and funding. The standing instruction does not apply.

Projects and spaces are separate budget envelopes. Project spend never draws on a space budget, and the other way round. A personal key acts under a space or a project, never both.

flowchart LR
    Org[Organisation] --> P[Project]
    P --> K[Project API keys]
    P --> M[Allowed models]
    P --> C[Configuration]
    P --> F[Funding or monthly limit]
    P --> U[Members]
    U -. act under .-> PK[Personal keys]
    K --> GW[Gateway]
    PK --> GW

Lifecycle#

A project is Active or Archived.

Archive is the safe off switch. The gateway refuses all traffic, but ATLAS keeps keys, configuration, the model list and funding history. Reactivating restores service.
An archived project is read-only, apart from the actions that wind it down or tidy it.
Delete is permanent. It removes the project's keys, model list, configuration and memberships. Personal keys that acted under it survive, with their context cleared. ATLAS keeps recorded spend.
Name and code are unique within the organisation. If you leave the code blank, ATLAS generates one such as PRJ-2026-0001. The code appears in reports and statements and never changes.

Two funding modes#

You choose the mode when you create the project. You can't change it afterwards.

Aspect	Funded	Tracked
Idea	A budget the project stops at	Spend is recorded but not capped by a budget
Budget	The sum of all funding entries	None
Limit	Lifetime ceiling	Optional monthly spending limit
New project	Refuses traffic until funded	Serves traffic immediately

A ledger, not a balance#

You never type a funded project's budget as a single number. The budget is the sum of funding entries. Each entry has an amount, a mandatory reason, the person who made it and a timestamp. A correction is another entry (negative to reduce), never an edit. You keep a complete trail, and you can reverse a mistaken top-up without losing history.

What happens when money runs out#

The gateway checks a project before it serves a request.

An archived project refuses all traffic.
A funded project is served only while it has funding left. A new or exhausted project answers with a budget-exceeded error.
A tracked project is served immediately. It's refused only when it has a monthly limit and this month's spend has reached it.

The check happens before the call, so the request that crosses the line is delivered and the next one is refused. For more information, see Budget and cost.

Statements#

ATLAS generates a monthly statement at month close for each project that had usage. A top-up statement follows each funding entry. Both are PDFs for Admins and Owners, Account Managers and project managers. For more information, see who can see statements.

What a project controls on a request#

Allowed models. A project reaches only the models on its list. A project with no models can't serve requests. ATLAS prices each request at the model's price when the request is made. A later price change doesn't alter recorded cost.
Standing instruction. ATLAS adds it as a system message to requests made with the project's own keys, before any message the caller supplies.
Defaults. Temperature and maximum tokens apply only when the caller doesn't send them. A value from the caller always wins.

Saving the configuration replaces it as a whole, so send back every field you want to keep.

Roles and access#

Organisation level. Admins and Owners act on every project. Account Managers can create, fund, configure and manage models and members, but can't delete a project or reveal key secrets. Members have no access to projects they aren't in.
Project level. A project manager can rename, archive, manage members, configure, issue and revoke keys, and read statements. A project member can read the project, its funding, usage, keys and members. Allocating funds, adding models, deleting and revealing a key's secret stay with organisation-level roles.

If you have no relationship to a project, it looks as if it doesn't exist. If you can see it but lack a right, you're told you aren't allowed. The web app hides actions you can't use, but ATLAS checks every one again on the server.

Acting under a project#

A person can point a personal key at a project they belong to. The key is then subject to that project's model list, defaults and funding. ATLAS records its usage against the organisation, the project and the person. You can't choose archived projects. Removing the person from the project, or deleting the project, clears the setting and keeps the key. Changes reach the gateway within seconds.

Reporting#

Portfolio. Every project shows its allocated, spent and remaining amount, the share consumed and when it was last used.
Project usage. A dashboard scoped to one project. Per-person detail is limited to Admins and project managers. Service-key traffic appears as one "machine traffic" row.
Organisation reports. Add a project filter and ranking. Deleted projects keep counting in historical figures.

For more information, see Usage and audit and Budget and cost.