Skip to main content
A project is the stable behavior your application requests. It owns a W&B project, datasets, fine-tunes, evaluations, analytics, and one or more routing versions. This page explains how projects, proxy model names, and versions relate, so you can change a project’s routing without disrupting the traffic your application already sends.
The management API calls a project a task. API paths start with /tasks/{alias}, where alias is the proxy model name. See API conventions.

Proxy model name

The proxy model name is the model string your application uses, such as ticket-classifier. It’s unique within a W&B entity and remains stable as models change. It can differ from the name of the W&B project that stores the project’s traces. The bare proxy model name always means version 1:
Pin a later version explicitly:

When to create a version

Create a new version when you need to experiment with a different model mix or provider parameters without affecting the application’s current traffic. Each version has an independent routing configuration.
Creating a version doesn’t move traffic. A caller reaches it only after changing model to name@vN.

What versions do not copy

A version isn’t a copy of the project. Datasets, fine-tunes, and evaluations remain project-level resources. Dataset queries can select which project version’s traffic to use. To validate a new version before any production traffic reaches it, follow this progression:
  1. Keep production on the bare proxy model name and version 1.
  2. Create a new version with the proposed routing.
  3. Send internal or canary traffic to name@vN.
  4. Inspect analytics and evaluations.
  5. Change the application’s configured model only when the new version is ready.
At this point, your application’s traffic uses the new version’s routing.
This request creates the next version with its own routing. The response contains the assigned version number.
For the complete operation, see Create a task version.
Last modified on September 2, 2026