wandb: the API key prompt that decides whether your CI job runs

The API key is viewable once, and a fresh machine stops to ask for it

Installation is one command.

pip install wandb

Everything after that depends on an identity. You sign up for a W&B account, create an API key at wandb.ai/settings, and store it somewhere secure. The key can only be viewed once when it is created, so there is no settings page to return to if it is lost. A password manager or an environment variable is the suggested answer, and a lost key means rotating it rather than retrieving it.

The login step is described as optional in the sense that the `wandb login` CLI is optional, because W&B prompts you to create an API key the first time you use the library. That prompt is the part that bites. On a developer laptop it is a convenience. On a fresh container, an ephemeral CI runner, or a training node that has never run the SDK before, the first call into the library stops for interactive input at whatever step your script reaches, and a job with no terminal attached fails in a way that has nothing to do with your model. If you run W&B in an automated environment, set the key in the environment up front and treat the prompt as evidence that the key is missing, not as a step in the normal flow.

Run names are generated, and the with block is the only finish signal shown

A run is created from a project name and a config dictionary holding the hyperparameters you intend to compare:

`config = {"epochs": 1337, "lr": 3e-4}`

opened with `with wandb.init(project=project, config=config) as run:`. Two things follow from that shape. First, nothing in the snippet names the run, and each run object appears in the Runs column with a generated name, so a hundred runs of the same script produce a hundred rows you have to disambiguate by their metadata rather than by their titles. Second, the with block is doing two jobs at once: it finishes the run on the way out and it marks the run failed if an exception passes through. The notebook variant is `run = wandb.init()` with a manual `run.finish()`, which trades that automatic failure marking for explicit control over when the run closes.

What the block does not do is retry. A run that dies at hour nine of a long job is recorded as failed and stays failed, and the README does not mention resuming a run or attaching a restart to the same run. If crash recovery matters to your pipeline, you have to record something yourself that lets you correlate the new attempt with the old one, because the platform side is happy to keep both as separate generated-name entries in the same project.

Three hosting options, and the real difference is who operates the server

The hosting question has three answers, all of them a W&B Server in a production environment. Multi-tenant Cloud is fully managed and deployed in W&B's own Google Cloud Platform account in GCP's North America regions, which fixes geography for you and puts you on shared infrastructure. Dedicated Cloud is still fully managed but single-tenant, deployed in W&B's AWS, GCP, or Azure accounts, with its own isolated network, compute, and storage separated from other Dedicated Cloud instances, so you choose the cloud and W&B still operates the platform. Self-Managed deploys the server in your own AWS, GCP, or Azure account or inside your on-premises infrastructure, and with it the whole operational burden: upgrades, backups, and availability become yours.

The decision that bites is not cost but reach. If a rule in your organization forbids experiment metadata, dataset references, or metric history sitting in another tenant, Multi-tenant is out and the choice narrows to Dedicated Cloud, the most managed option that survives the rule, or Self-Managed, the only one where the storage account is yours. One gap is worth closing early: the quickstart never names which endpoint your API key belongs to, so verify that before you assume your runs are landing where you think they are.

Python 3.10 is the floor, and dropping a version moves the minor number

pyproject.toml sets `requires-python = ">=3.10"`, with classifiers for 3.10 through 3.15 and none below. On 3.9 or older the install is simply not offered, so a base image pinned to an older interpreter fails at resolution time before any W&B code runs.

The support policy is spelled out and has one unusual property: the minimum required Python version is supported for at least six months after its official end-of-life date as defined by the Python Software Foundation, and when support for a version is discontinued the library's minor version number is incremented to reflect the change. That gives you a mechanism for planning upgrades and a trap at the same time, because the floor moves in two directions. New interpreter releases enter the classifier list as they appear, and old ones are eventually dropped so the floor rises. The only way to stay on an old interpreter is to pin a specific wandb minor version, and that pin then freezes you out of every fix released after it. A security patch in a newer minor cannot reach an environment holding an older floor for interpreter support reasons.

Since the package sits on the 0.x line, treat the minor version as the compatibility unit and read CHANGELOG.md and BREAKING.md before moving it.

One preview dependency is pinned exactly and two protobuf releases are excluded

One dependency line carries more weight than the rest of the list.

The protobuf constraint is `protobuf>=5,!=5.28.0,!=5.29.0,<8`, which opens the range at 5, closes it below 8, and carves out two specific releases. An environment holding protobuf 5.28.0 or 5.29.0 gets a conflict rather than a warning, which is the intended outcome but also means you cannot install at all until you move off the excluded version.

The remaining bounds are ordinary: `requests>=2.0.0,<3`, `pydantic>=2.6,<3`, `Click>=8.2.0`, `typing_extensions>=4.8,<5`, plus PyYAML, platformdirs, packaging, and `xxhash>=3.0.0`. That is a wide install for a metrics client.

OpenTelemetry arrives as three packages that have to move together

Tracing is not an optional extra here. pyproject.toml requires `opentelemetry-api>=1.43.0`, `opentelemetry-sdk>=1.43.0`, and `opentelemetry-exporter-otlp-proto-http>=1.43.0`, so the OpenTelemetry API, the SDK, and the OTLP HTTP exporter are hard requirements of the wandb package rather than something you add when you want them. Three packages sharing one floor means your effective OpenTelemetry version is the highest of the three, and raising one of them in a shared environment drags the others along.

The exporter is chosen for you as well: the OTLP over HTTP exporter is the one that ships, so a deployment already wired for the gRPC OTLP exporter has to run both or reconcile the difference. Because these are required dependencies, there is no supported way to install wandb into an environment that has decided against OpenTelemetry. A resolver that refuses opentelemetry-sdk will refuse wandb too, whatever your own requirements say.

A separate product line sits alongside all of this: Weave is the suite for LLM apps, covering tracking, debugging, evaluation, and monitoring. It is linked as its own product rather than as a wandb feature, so expect a second package and a second set of concepts if your work needs both.

A Python package carrying Go, Rust, and protobuf build inputs

The declared language is Python, but the metadata also claims Go and Rust, and the tree supports that: a `core/` directory, `parquet-rust-wrapper/`, and a `buf.yaml` for protobuf generation. The build backend is hatchling with a custom `hatch_build.py` and `hatch.toml` beside it, so what pip hands you is assembled from more than the Python package named wandb.

The version is declared dynamic rather than written into pyproject.toml, with .bumpversion.cfg and CHANGELOG.unreleased.md in the repository root, and the release line is still 0.x: v0.29.0 on 2026-08-26, v0.30.0 on 2026-09-09, v0.31.0 on 2026-10-16. Three minor releases in about seven weeks is a brisk cadence for a package that also ships compiled pieces, and the Development Status classifier calls it Production/Stable while the version number stays below 1.0.

The gap worth knowing about: the README offers exactly one installation path, `pip install wandb`, and says nothing about installing from a checkout, building the Go or Rust components, or what happens on a platform with no prebuilt wheel. Contributors are pointed at CONTRIBUTING.md and the docs/ directory instead. If you need a source install, an unusual platform, or an internal wheelhouse, that answer is not on the front page, so go find it before you plan around it.

Editorial conclusion

wandb earns its place for teams that already have somewhere to put experiment history, and it is the wrong first dependency for a team that has not decided on a host or a credential policy. Before you commit, check which of the three hosting options your account and key belong to, since the quickstart never names the endpoint. Confirm your Python interpreter is 3.10 or newer and read CHANGELOG.md and BREAKING.md, since dropping an interpreter support window moves the minor version. Set the API key in the environment rather than relying on the first-run prompt, and look at requirements/ and docs/ before assuming a source install or a platform without prebuilt wheels will work.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wandb/wandb on GitHub