Projects

Create isolated workspaces to organize resources, manage team access, and scope API keys

A Project is an isolated workspace within your Organization. Resources, API keys, and Collaborator membership are all scoped to Projects. Think of a Project as the collaboration boundary: when you give someone access to a Project, they can use everything inside it.

Multi-Project support is currently in early access. Every Organization includes a Default Project. To enable additional Projects, please contact support.

Not all resources are Multi-Project supported yet. See Early Access Limitations for the full list and how unsupported resources behave.

How Projects Work

Organization
  Project A
    Cluster 1
    Cluster 2
    Fine-tuned Model
    Volume (shared storage)
  Project B
    Cluster 3
    Endpoint
    Evaluation

Each Project contains its own set of resources. Collaborators of Project A cannot see or access anything in Project B, and vice versa. This lets you separate work by team, environment (dev/staging/prod), workload type, or customer.

Default Project

Every Organization has a Default Project. A few things to know about it:

• All Organization Members are automatically granted access to the Default Project
• All historical account usage and resources that pre-date Projects are attributed to this Project (work in progress)
• All Playground usage is attributed to this Project
• It has an “Organization Default Key” that is only accessible to the Organization Owner (see API Keys & Authentication)
• Because all Organization Members have access, do not use the Default Project for sensitive resources. Create a separate Project for those.

Managing Project Collaborators

You can manage Project Collaborators from Settings > Project > Collaborators.

Adding Collaborators

1. Go to Settings > Project > Collaborators
2. Click Add Collaborator
3. Enter the user’s email address
4. Click Confirm

The target user must already have a Together account. The Collaborator is added immediately upon confirmation.

New Collaborators are added with the Member role by default, unless they are an Organization Admin (who are Admins for every Project by default). An Admin can change their role after they have been added.

The user must already belong to your Organization, unless they are being added as an External Collaborator.

Removing Collaborators

1. Go to Settings > Project > Collaborators
2. Find the Collaborator you want to remove
3. Click the three-dot menu next to their name
4. Select Remove User
5. Confirm the removal

Removing a Collaborator revokes their access to all resources in the Project, including clusters, volumes, SSH access, and management capabilities. This takes effect within minutes.

Project API Keys

Each Project has its own API keys. These keys authenticate API requests and are scoped to the Project’s resources.

For details on creating, managing, and rotating API keys, see API Keys & Authentication.

Early Access Limitations

During early access, not all products work correctly across multiple Projects. This applies across in-app experiences, the CLI, SDKs, and the public API.

What’s Supported

The following work correctly across multiple Projects:

• Instant Clusters — On-demand GPU clusters for training and inference
• API Keys — Create and scope API keys to a specific Project

Not Yet Supported

The following do not yet work correctly across multiple Projects:

• Dedicated Endpoints — Always-on inference endpoints
• Volumes — Shared and local storage attached to clusters
• Fine-tuned Models — Custom models trained on your data
• Evaluations — Model evaluation runs
• Files — Training data and uploads

Here’s what to expect when using a resource that isn’t yet supported:

For Organization Members and Project Collaborators

If you use a product that isn’t multi-Project aware, usage attributes back to the Default Project of the Organization. In-app views and API responses for those resources may be inaccurate — they might return all resources belonging to the Organization or only resources in the Default Project, not the Project you’re working in.

For External Collaborators

The behavior is more significant for External Collaborators. Because many product decisions are based on the user’s Organization, usage in unsupported products may attribute back to the External Collaborator’s own Organization rather than the Project and parent Organization they are collaborating within. This means billing and resource attribution can be incorrect for external collaborators using products that don’t yet work across multiple Projects.

If you have External Collaborators using unsupported resources, usage may be billed to their Organization instead of yours. If your External Collaborators are internal company employees, consider migrating them into your Organization using SSO or Org Invites. Contact support for help with migration.

We’re actively expanding multi-Project support to all products. This section will be updated as more products are supported.

Common Project Structures

Teams organize Projects differently depending on their needs:

Strategy	Example	Best for
By team	ml-research, platform-eng, applied-ai	Large Organizations with distinct teams
By environment	development, staging, production	Teams that want resource isolation across environments
By workload	training, inference, evaluation	Teams that want to separate compute budgets
By customer	customer-a, customer-b	Service providers managing multiple clients

Next Steps

Roles & Permissions

What Admins and Members can do within a Project

API Keys

Create Project-scoped credentials

Cluster Access

Product-specific guide for managing cluster access