Skip to main content
Initialize a W&B Run with wandb.init(). By default, W&B supports one active run per Python process. If you call wandb.init() while a run is active, W&B either returns the active run or finishes it before creating a new one. The behavior depends on the environment and the reinit configuration. To manage multiple active runs in one process, see Multiple runs in one process.
W&B recommends using a context manager (with block) when calling wandb.init(). This ensures that W&B finishes the run and uploads its data when the block ends.

Single run per process

The following example initializes a run:
basic.py
The command produces output similar to the following:
In this example, W&B logs the run exalted-darkness-6 to the awesome-project project under the nico entity. W&B assigns the run the unique ID pgbn9y21.

Multiple runs in one process

Use the reinit parameter in wandb.init() or wandb.Settings to manage multiple runs in one Python process. For example, keep a primary run active while creating short-lived secondary runs for other tasks. Common use cases include:
  • Creating secondary runs for evaluations or subtasks while a primary run remains active.
  • Running multiple sub-experiments from one script.
  • Logging different tasks or time periods to separate runs from one process.
RequirementsTo manage multiple runs in a single Python process, you must have W&B Python SDK version v0.19.10 or newer.

reinit options

Use the reinit parameter to control what happens when you call wandb.init() while another run is active. The following table compares available options and common use cases. For the complete parameter definition, see the wandb.init() reference documentation.
W&B does not support create_new mode for W&B Integrations that assume a single global run, such as Hugging Face Trainer, Keras callbacks, and PyTorch Lightning. If you use these integrations, you should run each sub-experiment in a separate process.

Configure reinit

  • Use wandb.init() with the reinit argument directly:
  • Use wandb.init() and pass a wandb.Settings object to the settings parameter. Specify reinit in the Settings object:
  • Use wandb.setup() to set the reinit option globally for all runs in the current process. This is useful if you want to configure the behavior once and have it apply to all subsequent wandb.init() calls in that process.
  • Specify the desired value for reinit in the environment variable WANDB_REINIT. Defining an environment variable applies the reinit option to wandb.init() calls.
The following code snippet shows a high level overview how to set up W&B to create a new run each time you call wandb.init():

Example: Concurrent processes

Suppose you want to create a primary process that remains open for the script’s entire lifespan, while periodically spawning short-lived secondary processes without finishing the primary process. For example, this pattern can be useful if you want to train a model in the primary run, but compute evaluations or do other work in separate runs. To achieve this, use reinit="create_new" and initialize multiple runs. For this example, suppose “Run A” is the primary process that remains open throughout the script, while “Run B1”, “Run B2”, are short-lived secondary runs for tasks like evaluation. The high level workflow might look like this:
  1. Initialize the primary process Run A with wandb.init() and log training metrics.
  2. Initialize Run B1 (with wandb.init()), log data, then finish it.
  3. Log more data to Run A.
  4. Initialize Run B2, log data, then finish it.
  5. Continue logging to Run A.
  6. Finally finish Run A at the end.
The following Python code example demonstrates this workflow:
Note three key points from the previous example:
  1. reinit="create_new" creates a new run each time you call wandb.init().
  2. You keep references of each run. wandb.run does not automatically point to the new run created with reinit="create_new". Store new runs in variables like run_a, run_b1, etc., and call .log() or .finish() on those objects as needed.
  3. You can finish sub-runs whenever you want while keeping the primary run open until.
  4. Finish your runs with run.finish() when you are done logging to them. This ensures that all data is uploaded and the run is properly closed.