wandb/wandb: A Python Client for a Hosted Experiment Tracking Service
The AI developer platform. Use Weights & Biases to train and fine-tune models, and manage models from experimentation to production.
At a glance
- What is it?
- The wandb library is MIT licensed and pip installable, but the tracking itself runs against W&B's cloud or a self-managed W&B Server. This article covers the client's mechanism, its setup, and where the split between client and platform matters.
- Who is it for?
- Adopt wandb if you already train in Python and want run metrics and configs recorded without building a tracking store yourself, and if the hosted model or a self-managed W&B Server fits your data rules. Do not adopt it if you need a fully offline tracker with no server at all, or if you want a single tool that versions code and data alongside metrics.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What wandb.init and run.log actually do
The library's job is narrow and clear: it gives a Python process a run object, attaches a config dictionary to it, and sends metric values to a W&B backend. The README's example is short. You call wandb.init(project="my-awesome-project", config={"epochs": 1337, "lr": 3e-4}), then inside that context you call run.log({"accuracy": 0.9, "loss": 0.1}). The with block marks the run finished on exit and marks it failed if an exception escapes. In a notebook the README suggests run = wandb.init() followed by a manual run.finish() instead, which is a practical detail rather than a stylistic one: notebook cells do not guarantee the block exits cleanly.
The audience is anyone running training loops in Python who wants the numbers from those loops stored somewhere they can compare later. The README points at PyTorch, TensorFlow, Keras, JAX, and reinforcement learning work through its integrations list, and the topics on the repository name hyperparameter search and data versioning alongside experiment tracking. That is a wide net, and it is worth being precise about what the client does versus what the platform does. The client collects and ships. The platform stores, compares, and displays. Every claim about dashboards, sweeps, or artifact lineage in the README routes to docs.wandb.ai, not to code in this repository.
The client is MIT licensed; the place your metrics land is not in this repository
This is the distinction that decides most adoption questions. The LICENSE file at the root is MIT, and pip install wandb gets you that code. But the README's own quickstart sends you to wandb.ai/login to create an account and to wandb.ai/settings to create an API key, and the hosting section describes three ways to run W&B Server: multi-tenant cloud in W&B's GCP account, dedicated cloud in W&B's AWS, GCP, or Azure accounts, or self-managed on your own cloud account or on-premises infrastructure.
So the MIT licence covers the client you install. It does not describe the terms under which the service stores your runs, and the README does not state those terms. If your organisation has rules about where training metadata may live, the licence question and the hosting question are separate questions, and only the first one is answered by the repository. I would treat the hosting documentation as required reading before any pilot, not after. Nothing here is legal advice; the point is that the permissive licence on the client should not be read as a statement about the platform.
Getting a first run recorded: install, key, init
The README gives three steps. Install with pip install wandb. Create an account and an API key, then optionally run wandb login to configure the key on the machine. The README notes you can skip the login step because W&B will prompt you for a key the first time you use the library, and it warns that API keys can only be viewed once when created, so they belong in a password manager or an environment variable.
Then the training script. The README's example passes project and config to wandb.init and logs a dictionary of scalars with run.log. That is the whole surface needed for a first run. Two details in the example are easy to skim past. First, config is where hyperparameters go, which is what makes a run comparable to another run later; the README's config holds epochs and a learning rate. Second, the with form is doing error handling for you, marking the run failed on an exception. If you use the notebook form with a manual run.finish(), you take that bookkeeping on yourself.
For framework users, the README points to the integrations documentation rather than showing per-framework snippets, so the exact hook for a given trainer is something to look up there. The repository also carries a docs/ directory and a CONTRIBUTING.md for people working on the client itself.
Hosting choice is the real deployment decision
There are three options in the README, and they differ in who operates the infrastructure. Multi-tenant cloud is fully managed and runs in W&B's GCP account in GCP's North America regions, which is a geographic constraint stated plainly in the README. Dedicated cloud is single-tenant and managed, deployed in W&B's AWS, GCP, or Azure accounts, with each instance on its own isolated network, compute, and storage. Self-managed puts W&B Server in your own cloud account or on-premises.
Read those three as a ladder of operational burden. Multi-tenant is the least work and the least control, and the README pins it to North America regions, which rules it out for teams with data residency requirements outside that footprint. Dedicated cloud adds isolation without handing you the servers. Self-managed gives the most control and makes your team responsible for running the server. The README does not describe sizing, upgrade procedures, or backup expectations for a self-managed deployment, so those are questions for the hosting documentation and for whoever will actually operate it. If nobody on the team wants to own a server, the self-managed path is the wrong one regardless of how attractive the isolation sounds.
Where the client is the wrong tool
The clearest limitation follows from the architecture: this is a client for a service. A run recorded through run.log goes to a W&B backend, whether that is W&B's cloud or a W&B Server you deployed. If your environment has no route to that backend and you are not prepared to run one, the library has nothing to write to. That is not a bug in the client; it is what a client is. Teams that want metrics to stay in a local file or a database they already operate should look at tools built around that assumption instead of trying to bend this one.
A second boundary is scope. The repository is the Python client. Sweeps, dashboards, artifact lineage, and the LLM tooling the README mentions under the Weave name are platform features reached through the hosted service and documented elsewhere. Anyone evaluating this repository alone is evaluating the collection and upload path, not the analysis side. That matters when comparing against a self-contained tool: the comparison is not library versus library, it is client plus service versus a single piece of software.
A third practical constraint: the README states a Python version support policy, committing to support the minimum required version for at least six months past its end-of-life, and bumping the library's minor version when support is dropped. That is a clear policy, but it means a minor version bump can carry a Python floor change rather than only new features. Pin your dependency if an unattended upgrade would be disruptive.
The alternative to weigh: local-first trackers such as MLflow
The obvious comparison is MLflow, which also offers a Python logging API but is built around a tracking server and artifact store you run yourself, with a local file-backed mode that works with no server at all. The difference in approach is where the default lives. With wandb, the README's quickstart assumes an account and an API key, and the storage is W&B's cloud or your W&B Server deployment. With MLflow, the default is a store you point at, and hosted offerings are a separate choice.
That difference cuts both ways. If you want a managed service and do not want to operate storage, the wandb path removes work that MLflow leaves to you. If you want the tracker to run entirely inside your own infrastructure with no external dependency, MLflow's local mode is the shorter path, and the wandb client is not trying to be that. There is also a narrower distinction worth noting: the README positions wandb's integrations as covering PyTorch, TensorFlow, Keras, and JAX through documented hooks, so if your framework is unusual, check the integrations documentation for both tools before deciding, rather than assuming parity.
Maintenance cost and upgrade risk
The release cadence is visible in the repository: v0.30.0, v0.29.0, and v0.28.2, with the two most recent landing roughly two weeks apart. That is frequent enough that an unpinned dependency will move under you during a long training campaign. The Python support policy compounds this, since dropping a Python version is announced by a minor version bump, so a minor upgrade can be the one that ends support for the interpreter you are on.
The practical response is to pin the version in whatever you use to manage dependencies and to read the release notes before moving the pin. If you self-manage W&B Server, there is a second upgrade surface, the server itself, and the README does not describe that process here; it points to the hosting documentation. Dedicated cloud and multi-tenant cloud move that burden to W&B. Budget for the client upgrade separately from the server upgrade, because the two are released and operated by different paths even though they must stay compatible. On the licence side, MIT on the client is permissive and imposes no copyleft obligation on your training code; the service terms, again, are a separate matter that the repository does not cover.
Editorial conclusion
Adopt wandb if you already train in Python and want run metrics and configs recorded without building a tracking store yourself, and if the hosted model or a self-managed W&B Server fits your data rules. Do not adopt it if you need a fully offline tracker with no server at all, or if you want a single tool that versions code and data alongside metrics. Before committing, verify three things: whether your runs can reach W&B's service or your own deployment, where your API key will live given that keys can only be viewed once at creation, and which of the three hosting options your organisation is permitted to use, because that choice determines who operates the storage behind run.log.
Community notes