> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/train/model-ids.md).

# Model IDs

Every trained model has a model ID that identifies it when you deploy it, run inference, or select it in a Workflow model block. This page describes the current structure of model IDs, as well as how a previous (legacy) format of ID is still supported under some circumstances.

## Model ID Structure

A model ID has the form `{workspace}/{model-slug}`. The first part is your Workspace URL slug. The second part, the model slug, identifies the model within the workspace and is built from four parts joined by hyphens:

```
{project}-{version}-{architecture}-t{n}
```

* `project`: the URL slug of the project the model belongs to. Example: `construction-safety-xpv3w`.
* `version`: the number of the dataset version the model was trained on. Example: `12`.
* `architecture`: the model architecture used for training. Example: `rfdetr-small`.
* `t{n}`: a training counter for the version. The first training started on a version is t1, the second is t2, and so on.

For example, the second RF-DETR Small training on version 3 of a project with the URL slug `construction-safety-xpv3w` in the workspace `my-workspace` produces the model ID `my-workspace/construction-safety-xpv3w-3-rfdetr-small-t2`.

The model slug is assigned when a training starts, so you can see the ID a model will have while it is still training. Training counter suffixes are never reused: if a training fails or is cancelled, its number is skipped and the next training on the version gets the next one.

A [Neural Architecture Search](/train/neural-architecture-search.md) training produces many candidate models. NAS candidate model IDs look like other model IDs, but with a double hyphen and a 6-character hash appended (ex: `my-workspace/construction-safety-xpv3w-3-rfdetr-nas-t1--9589f2`). In the v2 trainings endpoints, a NAS training reports its `modelType` as `rfdetr-nas-parent`, while each of its candidate models reports `rfdetr-nas`.

## Find a Model ID

You can look up the ID of any trained model in the web UI, through the REST API, or with the Roboflow MCP Server.

{% tabs %}
{% tab title="Web UI" %}
Click "Models" in your project sidebar to open the [Models page](/train/view-trained-models.md). Each model shows its ID next to the "ID:" label, with a "Copy Model ID" button next to it. The same ID and copy button appear on the model's detail view and in the models table on each version page.
{% endtab %}

{% tab title="REST API" %}
The [List Project Models](/developer/rest-api/list-project-models.md) endpoint returns every model trained in a project. The `url` field of each entry in the response is the model ID:

```
GET https://api.roboflow.com/{workspace}/{project}/models?api_key=YOUR_API_KEY
```

```json
[
  {
    "url": "my-workspace/construction-safety-xpv3w-3-rfdetr-small-t2",
    "version": "3",
    "modelType": "rfdetr-small",
    "train": { "status": "finished" },
    ...
  },
  ...
]
```

To find the models trained on a specific version, use the v2 trainings endpoints. Listing a version's trainings returns each training with the IDs of the models it produced in its `modelIds` field. On a legacy single-model version, the training `id` is a path of the form `{workspaceId}/{version}/training/0` (rather than the hash shown below), and `modelIds` contains the version's [legacy ID](#legacy-model-ids) instead:

```
GET https://api.roboflow.com/{workspace}/{project}/{version}/v2/trainings?api_key=YOUR_API_KEY
```

```json
{
  "trainings": [
    {
      "id": "0a1b2c3d4e5f67890abc",
      "versionId": "3",
      "status": "finished",
      "modelType": "rfdetr-small",
      "modelIds": ["my-workspace/construction-safety-xpv3w-3-rfdetr-small-t2"],
      ...
    },
    ...
  ]
}
```

Getting a single training returns per-model details, including each model's ID in the `modelId` field of its `models` list. You may omit `trainingId` when the version has only one training, but such a request fails with a 409 error if the version has multiple trainings.

```
GET https://api.roboflow.com/{workspace}/{project}/{version}/v2/trainings/get?api_key=YOUR_API_KEY&trainingId={trainingId}
```

```json
{
  "trainingId": "0a1b2c3d4e5f67890abc",
  "versionId": "3",
  "status": "finished",
  "modelType": "rfdetr-small",
  "modelCount": 1,
  "models": [
    {
      "modelId": "my-workspace/construction-safety-xpv3w-3-rfdetr-small-t2",
      "modelType": "rfdetr-small",
      "status": "finished",
      "metrics": { ... }
    }
  ],
  ...
}
```

{% endtab %}

{% tab title="MCP" %}
The [Roboflow MCP Server](/developer/mcp-server.md) provides tools that return model IDs. `models_list` lists the trained models of one project (the workspace comes from the connection's credentials, and the project is passed as `project_id`) and returns each model's ID in its `url` field, with optional filtering by version or NAS run. `trainings_get` and `trainings_list` return the IDs of the models each training produced. Agents can pass these IDs to other tools, such as `models_infer`.
{% endtab %}
{% endtabs %}

## Legacy Model IDs

In the past, Roboflow dataset versions could only have one training run on them, so models used to be uniquely determined by an ID of the form `{project}/{version}`.

For example, `construction-site-safety/3` used to refer to *the* model trained on version 3 of that project. The first part is the project URL slug, not the workspace, and the second part is the version number. This is the format older SDKs, code snippets, and Inference installations use (ex: `model_id="construction-site-safety/3"`).

Because it is now possible to run [more than one training](/train/versions-trainings-and-models.md) on a dataset version, these legacy-format IDs are no longer preferred. If you try to use such IDs for new trainings launched after June 30th, 2026, they will resolve under-the-hood to the new style of ID.

## How Legacy IDs Resolve

Legacy-format IDs keep working through aliases. When the first training started on a version completes successfully, Roboflow links the version's legacy `{project}/{version}` ID to the new model ID. Requests that use the legacy ID, including weights downloads from older Inference installations, resolve to that model automatically.

The alias is created only by the *first* training on a version and does not change afterward:

* If the first training completes successfully, the legacy ID refers to that model permanently, even after you train more models on the same version. Reference later models by their own model IDs.
* If the first training fails or is cancelled, no alias is created, and later trainings on the version do not create one.

A version without an alias can still be referenced by its legacy ID as long as it holds exactly one model. If it holds several models and has no alias, requests using the legacy ID fail because the reference is ambiguous, and you must use the model's own ID.

{% hint style="info" %}
Legacy IDs exist for backwards compatibility. Prefer full model IDs in new integrations: they are unambiguous and work for every model on a version.
{% endhint %}