- datasets and their versions
- labelling, prompt tuning and evaluations
- fine-tunes, families and models
- decisions
- project keys
The Default project
Every organisation has a Default project, whose id is the organisation’s. Work and keys that name no project belong to it, so a project key whoseproject_id is null works there with no header. An admin key’s project_id is null too, but it works in no project.
The Default project can be renamed, but never archived (409 default_project).
A personal workspace has its Default project alone. The console shows it no projects, and making or changing one gets 409 personal_organization.
Make, rename and archive
In the console, the project menu, in the sidebar under the organisation menu, switches the project a tab works in, and New project makes one. Each tab keeps its own choice. Project settings, the button beside the menu, renames and archives the project. The Projects tab of Organisation settings lists the projects, each opening its own settings.- An organisation has at most 20 live projects, its Default one included. Another gets
409 project_limit. Archived projects don’t count. - A name has 1 to 80 characters, and is unique among the organisation’s live projects whatever its case (
409 project_exists). - Archiving keeps the project’s work, but nobody can work in it, and its keys are revoked at once. It also removes the project’s spending limit. It can’t be undone.
- A project with a fine-tune, evaluation, labelling job or prompt tuning job queued or running can’t be archived until that work ends (
409 project_working). Cancel it, or wait for it, first. - A project that still keeps a model warm, stores a dataset that pays for storage, or answers calls with a family or model that is switched on, can’t be archived until they stop (
409 project_in_use). Switch keep warm and those families and models off, and archive or delete those datasets, first. - A project that a developer works in alone can’t be archived until an owner gives them another (
409 project_only_access, which names them).
GET /v1/projects lists the live projects, the Default one first, each with its spending limit, and ?archived=true lists the archived ones. A project key with full or read access lists its own project alone, unless it is an older key whose role is billing, and an admin key lists them all. Only the console and an admin key make, rename and archive projects, and a project key gets 403 console_only.
Who works in which project
Every member works in every project, including new ones. An owner can limit a developer to some projects instead, to keep a contractor out of production, say. Owners and billing members always work in every project.- To limit someone: with more than one project, the Members tab in Organisation settings shows the projects each member works in. On a developer’s row, choose Change, then Only these projects, and tick them. All projects, including new ones lifts the limit.
- When inviting: the invite dialog offers the same choice for a developer. Accepting keeps the projects that are still live. If every one was archived, accepting gets
409 invitation_projects_gone, and an owner sends a new invitation. - What they see: a limited developer works in their projects with their developer role, and sees nothing of the others. The project menu and
GET /v1/projectslist their projects alone, and a project outside them gets404 project_not_found. They make no projects. Usage and Request history count their projects alone. - Their keys: keys they made in a project they no longer work in go to the owners’ review. Giving the project back ends no review: an owner keeps or revokes each key.
- A change of role from developer lifts the limit.
- Archiving a project takes it off the lists of the developers who work in it and in others.
project_access on GET /v1/account is some for a limited developer, and for a project key that works as a developer, as it works in its own project alone. It is all otherwise.
Keys and projects
A project key works in its own project alone, withfull, inference or read access. The API keys page lists the keys of the project the tab works in, and makes new ones there. An admin key makes one in any project.
A project key needs no header: its requests work in its project. A request whose OneHot-Project header names another project gets 403 key_project. project_id on GET /v1/account/keys names a key’s project, and is null for a Default-project key and for an admin key. A project key’s GET /v1/account/keys lists its own project’s keys alone. Its GET /v1/account/usage and GET /v1/account/usage/requests count its own project’s usage alone, and a project naming another gets 404 project_not_found.
An Idempotency-Key belongs to one project, and a retry in the same project gets the first answer. In another project, the same key on a decision gets 409 idempotency_conflict. On a dataset, fine-tune or Decision Lab job it makes a new one in that project, and a new dataset there pays its own storage above the free size.
A request sees its own project’s work. A path that names a dataset, job, evaluation, family or model of another project gets 404 not_found. A family’s name is unique across the organisation’s projects, so a name another project uses gets 409 family_exists.
Copy a dataset into another project
On a dataset’s page, Copy to project copies it into another project of the organisation. Owners and developers copy, in the console alone.- The copy is a new dataset in that project, with one version: the version you choose. Its rows are the same, and each one is on the same side, training or evaluation, so a fine-tune or an evaluation there works on exactly the same data.
- It is made as an upload is. It takes storage and its charge, and counts toward the project’s limits.
- It shares nothing with the source afterwards, so either can be renamed, grown or deleted on its own.
- A project stopped by its spending limit can’t receive a copy (
402 project_spend_limit). A copy out of a stopped project works, as it only reads the source. - A copy into the dataset’s own project gets
409 same_project.
Spending limits
A project can have a monthly spending limit, in USD to the cent. It counts what the project’s work cost in the calendar month (UTC): its decisions, its Decision Lab work, keep warm for its models and storage for its datasets. The Default project takes one too. To set it, choose Change beside Monthly limit in Project settings. Owners and billing members set it. Every member reads the limits of the projects they work in, so a limited developer reads their own projects’ alone, and a key that works as a developer its own project’s.GET /v1/projects/{project_id}/spending reads the limit (monthly_limit_usd), whether it stops new work (limit_stops), whether it has stopped the project (stopped), and what the project spent this month (month_spent_usd), as USD amounts. The console and an admin key set it. The organisation’s billing email gets an email for each of 50%, 80% and 100% of its limit that the project’s spending passes, once each a month for that limit. Several shares passed between two checks each get their email, and a new limit gets its own. Without the stop, that is all a limit does.
An organisation has no spending limit of its own. Its low-balance alert says when its credit runs low.
Stop new work at the limit
When a project whose limit stops new work (limit_stops, Stop new work when the limit is reached in the console) reaches its limit:
- Its new decisions and new Decision Lab work, such as a new dataset, labelling job, evaluation or fine-tune, get
402 project_spend_limit, and so does switching keep warm on. That holds for its keys and in the console. - It reads what it has, and ends or cancels what it holds. Work already running carries on, keep warm and storage included.
- A retry of a decision it accepted before it stopped, with the same
Idempotency-Key, still gets that decision’s answer. - The organisation’s keys, billing, members and projects stay open, so an owner or a billing member can act. Its other projects work on.