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
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 thereinit 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 thereinitargument directly: -
Use
wandb.init()and pass awandb.Settingsobject to thesettingsparameter. Specifyreinitin theSettingsobject: -
Use
wandb.setup()to set thereinitoption 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 subsequentwandb.init()calls in that process. -
Specify the desired value for
reinitin the environment variableWANDB_REINIT. Defining an environment variable applies thereinitoption towandb.init()calls.
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, usereinit="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:
- Initialize the primary process Run A with
wandb.init()and log training metrics. - Initialize Run B1 (with
wandb.init()), log data, then finish it. - Log more data to Run A.
- Initialize Run B2, log data, then finish it.
- Continue logging to Run A.
- Finally finish Run A at the end.
reinit="create_new"creates a new run each time you callwandb.init().- You keep references of each run.
wandb.rundoes not automatically point to the new run created withreinit="create_new". Store new runs in variables likerun_a,run_b1, etc., and call.log()or.finish()on those objects as needed. - You can finish sub-runs whenever you want while keeping the primary run open until.
- 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.