Skip to main content
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, contact support.Not all resources are Multi-Project supported yet. See Early Access Limitations for how unsupported resources behave.

​
How projects work

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.

​
Project slugs

A project slug is a short, URL-safe, human-readable identifier for a Project. It’s globally unique across Together and distinct from the Project’s internal project_id, the permanent identifier behind ownership, permissions, and billing. The slug is the friendly handle. The project_id never changes. You choose a slug when creating a new Project, and you can copy any Project’s slug from the Projects list in Organization Settings. When you create an endpoint with dedicated model inference, the Project’s slug becomes part of its endpoint string, <project_slug>/<endpoint_name>. You choose only the endpoint name. The slug prefix is added automatically and makes the endpoint string globally unique.

​
Changing a project slug

Project Admins can change an existing Project’s slug from Project Settings: find the Project Slug field and select Change. The new slug takes effect immediately.
Changing a slug breaks existing API requests, scripts, and integrations that reference resources by their slug-qualified path (for example, <slug>/<endpoint_name>). There is no redirect from the old slug. Update any references that rely on the old slug.

​
Managing project collaborators

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

​
Adding collaborators

  1. Go to Settings > Project > Collaborators.
  2. Select Add Collaborator.
  3. Enter the user’s email address.
  4. Select Confirm.
New Collaborators are added with the Editor 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. Select 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.

​
External collaborators

This feature is in beta. Contact support to enable it.
To add users from outside your Organization as Collaborators, enable Allow external collaborators on the Project’s Settings > Project page. Once enabled, you can add External Collaborators the same way as any other Collaborator. See External Collaborators to learn more about their permissions.

​
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

Volumes aren’t Project-aware yet. Usage attributes back to the Default Project of the Organization, and 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. Custom and fine-tuned models aren’t fully Project-aware yet either: some may be visible across all Projects even when they’re set to private. Additionally, costs in the Projects list and in cost analytics may be inaccurate for any Project running legacy v1 dedicated endpoints.

​
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.
Together is 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:

​
Next steps

Roles & Permissions

What Admins and Editors can do within a Project

API Keys

Create Project-scoped credentials

Cluster Access

Product-specific guide for managing cluster access