Upgrading to Opik 2.0
Opik 2.0 reorganized the product around projects. A project now maps to a single agent or app and is the home for everything related to it. This page explains what changed, how to work with the SDK from now on, where your existing data was moved, and how to relocate it if it didn’t land where you want.
If you started on Opik 2.0, there’s nothing to do here — projects are the default. This guide is for users upgrading from Opik 1.x. For the full list of new features, see the 2.0 release notes.
What changed: projects are the home for everything
In Opik 1.x, traces and threads lived in projects, but datasets, prompts, experiments, optimizations, automation rules, alerts, and dashboards were workspace-wide. In 2.0, a project maps to one agent or app and scopes all of its work.
These entities are now scoped to a project:
- Datasets and test suites
- Experiments and optimizations
- Prompts
- Automation rules — in 1.x a rule could target multiple projects; in 2.0 a rule is scoped to a single project
- Alerts
- Dashboards — workspace-level dashboards remain supported through a dedicated view
You also get a workspace-level project selector, project-scoped navigation across the app, a unified Logs page (threads, traces, and spans in one place), and a redesigned trace view. The result is a focused view of everything tied to a single agent. See the 2.0 release notes for the full picture.
How to work now
Upgrade to the Opik SDK 2.0 or later:
Python
TypeScript
The main change is to pass the project to the methods you call. The dataset, test suite, prompt, and experiment APIs all take a project_name (projectName in TypeScript). Omit it and Opik uses the project from the OPIK_PROJECT_NAME environment variable or your config, falling back to Default Project.
Running opik configure now also prompts you to pick a project — it suggests your most
recent one and stores your choice as project_name in ~/.opik.config, so you only pass
project_name on a call when you want to override that default.
All snippets below assume a client:
Python
TypeScript
Datasets
Python
TypeScript
Test suites
Python
TypeScript
Prompts
Python
TypeScript
Experiments
An experiment — and every trace, span, and feedback score it produces — always lands in the same project as the dataset it runs against. You don’t scope an experiment separately: put the dataset in the project you want, and each run of it follows. This holds whether you call opik.evaluate(...) or create the experiment directly.
Python
TypeScript
Where your existing data lands
When your workspace is upgraded to 2.0, your workspace-scoped 1.x data — datasets, prompts, experiments, and optimizations — is moved into projects.
Each item is placed in the project Opik can infer from the runs that used it. When there’s nothing to infer from (no associated runs, or the original project had been deleted), the item is placed in your Default Project.
So if you don’t see a dataset, prompt, or experiment where you expected it, check the project its traces and experiments belong to — and check Default Project.
Opik Cloud (Comet-hosted): the move runs automatically — there is nothing to start by hand. A workspace is promoted to 2.0 as soon as its blocking workspace-level (orphan) data has been migrated into projects.
On self-hosted installations, migration requires enabling six background jobs on your
opik-backend deployment. See the self-hosted migration guide
for step-by-step instructions.
Moving data to a different project
If something landed in a project you don’t want, you can move it with the opik migrate CLI. It relocates a dataset (with its experiments, traces, and spans) or a prompt (with its full version history) into another project.
Preview any move with --dry-run first. See Migrate data for the full guide — what’s copied, the options, and troubleshooting.