wandb/examples: runnable references for every W&B feature

A catalogue, not a library

The wandb/examples repository contains scripts and notebooks that show how to use Weights and Biases in machine learning workflows. The stated purpose is to use these examples to add experiment tracking, model and dataset versioning, hyperparameter tuning, rich media logging and collaborative reports to your own projects.

The primary language is recorded as Jupyter Notebook, and there are no GitHub releases, which fits the nature of the thing. There is nothing to install from this repository. The homepage is wandb.ai, and the last push was on 2026-10-15, so it is actively maintained.

What the repository is, then, is a set of worked examples that you copy from. That is a different kind of artifact from a library, and it changes how you should read it. The value is in the pattern each file demonstrates, not in the code itself, and the code is expected to be adapted to your project rather than imported.

The README points at the product documentation at docs.wandb.ai and at the integrations guide for the details, which is a hint about the division of labour. The repository shows, the documentation explains.

The licence field for the repository is unrecorded, with no license file named in the top level entries. That is a real consideration if you plan to lift example code into a commercial project, and it is worth resolving before you do.

Three directories, three different ways to work

The repository layout is described in a small table, and the three paths are organised around how you would consume the example rather than around the technology.

`colabs/` holds Google Colab notebooks for W&B features, frameworks and workflows. `examples/` holds runnable scripts organised by framework or W&B feature. `wandb-scim/` holds SCIM administration examples, which is a different thing entirely: SCIM is the protocol for provisioning users in an identity system, so those examples are about administering a W&B organisation rather than tracking a training run.

The `examples/` directory is where the breadth shows. The listing includes `api-examples/`, `boosting-algorithms/`, `data/`, `fastai/`, `java/`, `jax/`, `keras/`, `launch/`, `llama-cpp/`, `machine-learning/`, `marimo/`, `minimal-hydra-example/`, `model-evaluation/`, `pytorch-ignite/`, `pytorch-lightning/`, `pytorch/`, `ray-tune/`, `sacred/`, `sagemaker/`, `scikit/`, `streamlit/`, `tensorboard/`, `tensorflow/` and `wandb-automations/`.

Some of those names are more interesting than others. `wandb-automations/` is about automating responses to run events, `model-evaluation/` about evaluation rather than training, `wandb-sweeps/` referenced elsewhere in the README is about hyperparameter search. `marimo/` and `minimal-hydra-example/` point at the newer notebook and configuration tooling, and `launch/` and `sagemaker/` are about getting runs onto infrastructure.

The README's warning is the practical bit: the examples use different frameworks and dependency sets, and before running one you should check the README or the requirements.txt file in that example's directory.

Getting a run on the board

The setup path is short. Install the SDK and authenticate, then clone the repository:

pip install --upgrade wandb
wandb login

git clone https://github.com/wandb/examples.git
cd examples

Then, for a local script, install the example-specific dependencies listed in that directory and run the training file:

cd examples/pytorch/pytorch-cnn-fashion
python train.py

For notebooks, you open the matching Colab from the `colabs/README.md` index, or run the notebook locally in whatever environment you prefer.

The core API the README teaches is three functions. `wandb.init()` creates a run, `run.config` stores the input settings, and `run.log()` records metrics during training. The example is deliberately artificial, a simulated training loop over random values, which is the right choice for a reference: it shows the shape of the call without burying the mechanism under a model's real complexity.

with wandb.init(project=project, config=config) as run:
    offset = random.random() / 5
    print(f"lr: {config['lr']}")
    
    # Simulate a training run
    for epoch in range(2, config['epochs']):
        acc = 1 - 2**-config['epochs'] - random.random() / config['epochs'] - offset
        loss = 2**-config['epochs'] + random.random() / config['epochs'] + offset
        print(f"epoch={config['epochs']}, accuracy={acc}, loss={loss}")
        run.log({"accuracy": acc, "loss": loss})

The rule the README states alongside it is the one that trips people up: configuration values are for inputs and independent variables such as learning rate, batch size, dataset name and model architecture, while logged metrics are for outputs and values that change during training. Putting a changing value in the config rather than in a log call is the single most common mistake in a first integration, because the config is fixed for the run and a chart of it is then meaningless.

The five features, and what each one is for

The README walks through five W&B Models features, and each one is a different kind of object.

Framework integrations cover PyTorch, Keras, TensorFlow, HuggingFace Transformers, PyTorch Lightning and XGBoost, and the pitch is that you log metrics, system stats, artifacts and model checkpoints with minimal code changes. If your framework is not on the list, the README points at the guide for adding W&B to any Python library, or at the core SDK shown in the previous section.

Sweeps is the hyperparameter search feature, where you define a search space, launch agents and compare results in the app. The supported strategies are grid search, random search and Bayesian optimization, and the README links both a walkthrough and the PyTorch Sweeps Colab, plus the `examples/wandb-sweeps/` directory.

Artifacts version datasets, models and other files as inputs and outputs of a run, and the stated benefits are reproducibility, lineage inspection and sharing assets across teams. The example is short: create an `Artifact` with a type, add a file, log it to the run.

Tables log structured data, rich media, predictions and evaluation results, and the README says they are useful for comparing examples across models, finding misclassifications and sharing qualitative results. The example logs a table with id, prediction and label columns.

Reports are the collaborative layer, where charts, tables, media, Markdown and links to the underlying runs are organised into something you can share with collaborators.

Who should read this and who should not

There is a clear case for this repository and a clear case against, and pretending otherwise would be unhelpful.

The case for it is a developer adding experiment tracking to a training script they already have. The alternative is reading the documentation and reverse-engineering what a call should look like in your specific framework, which is exactly the situation where a working example saves an hour. The framework list in the examples directory is broad enough that most people will find their own stack represented, and the `examples/pytorch/pytorch-cnn-fashion` directory that the README walks through is a small, realistic script rather than a toy.

It also serves a second audience, the person evaluating whether W&B fits at all. Reading a set of examples for Keras, TensorFlow, XGBoost and scikit-learn tells you how much of your work is covered and how the coverage differs between them, which a feature list does not.

The case against is that these are examples. They are not a supported surface, they are not versioned with the SDK, they are not covered by the same compatibility guarantees, and the repository's own README tells you to check the dependency set in each directory because they differ. Copying an example and then expecting it to keep working as the SDK changes is on you.

The `wandb-scim/` directory also deserves a mention as the odd one out. Administering users through SCIM is a different problem from tracking experiments, and the fact that the repository covers it says something about how much surface W&B exposes. If you are only tracking runs, that directory is not for you.

Editorial conclusion

wandb/examples fits a developer adding experiment tracking to an existing training script, or a team deciding whether W&B fits their framework, since each integration is demonstrated in runnable code rather than described. It does not fit a production system that needs a supported dependency, since there is no package to install and the licence is unrecorded. Before copying anything, read the README or requirements.txt inside the example directory you are taking, since each one carries its own dependency set, and check the licences yourself before shipping example code in a product.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. wandb/examples on GitHub