Skip to main content

Export data

Use the Public API to export or update data that you have saved to W&B. Before using this API, log data from your script. Check the Quickstart for more details. Use Cases for the Public API
  • Export Data: Pull down a dataframe for custom analysis in a Jupyter Notebook. Once you have explored the data, you can sync your findings by creating a new analysis run and logging results, for example: wandb.init(job_type="analysis")
  • Update Existing Runs: You can update the data logged in association with a W&B run. For example, you might want to update the config of a set of runs to include additional information, like the architecture or a hyperparameter that wasn’t originally logged.
See the Generated Reference Docs for details on available functions.

Export run data

Download data from a finished or active run. Common usage includes downloading a dataframe for custom analysis in a Jupyter notebook, or using custom logic in an automated environment.
The most commonly used attributes of a run object are: You can also modify or update the data of past runs. By default a single instance of an api object will cache all network requests. If your use case requires real time information in a running script, call api.flush() to get updated values.

Querying multiple runs

This example script finds a project and outputs a CSV of runs with name, configs and summary stats. Replace <entity> and <project> with your W&B entity and the name of your project, respectively.
Calling api.runs returns a Runs object that is iterable and acts like a list. By default the object loads 50 runs at a time in sequence as required, but you can change the number loaded per page with the per_page keyword argument. api.runs also accepts an order keyword argument. The default order is -created_at. To order results ascending, specify +created_at. You can also sort by config or summary values. For example, summary.val_acc or config.experiment_name.

Error handling

If errors occur while talking to W&B servers a wandb.CommError will be raised. The original exception can be introspected via the exc attribute.

Get a run’s name and ID during an active run

After calling wandb.init() you can access the random run ID or the human readable run name from your script like this:
  • Unique run ID (8 character hash): run.id
  • Random run name (human readable): run.name
If you’re thinking about ways to set useful identifiers for your runs, here’s what we recommend:
  • Run ID: leave it as the generated hash. This needs to be unique across runs in your project.
  • Run name: This should be something short, readable, and preferably unique so that you can tell the difference between different lines on your charts.
  • Run notes: This is a great place to put a quick description of what you’re doing in your run. You can set this with wandb.init(notes="your notes here")
  • Run tags: Track things dynamically in run tags, and use filters in the UI to filter your table down to just the runs you care about. You can set tags from your script and then edit them in the UI, both in the runs table and the overview tab of the run page. See the detailed instructions here.

Public API Examples

Read metrics from a run

This example outputs timestamp and accuracy saved with run.log({"accuracy": acc}) for a run saved to "<entity>/<project>/<run_id>".

Read specific metrics from a run

To pull specific metrics from a run, use the keys argument. The default number of samples when using run.history() is 500. Logged steps that do not include a specific metric will appear in the output dataframe as NaN. The keys argument will cause the API to sample steps that include the listed metric keys more frequently.

Compare two runs

This will output the config parameters that are different between run1 and run2.
Outputs:

Update metrics for a run, after the run has finished

This example sets the accuracy of a previous run to 0.9:

Rename a metric in a completed run

This example renames a summary column in your tables.
Renaming a column only applies to tables. Charts will still refer to metrics by their original names.

Update config for an existing run

This example updates one of your configuration settings.
See Configure experiments for more information.

Export system resource consumptions to a CSV file

The snippet below would find the system resource consumptions and then, save them to a CSV.

Get unsampled metric data

When you pull data from history, by default it’s sampled to 500 points. Get all the logged data points using run.scan_history(). Here’s an example downloading all the loss data points logged in history.

Get paginated data from history

To retrieve a run’s complete, unsampled history, use run.scan_history(). Unsampled history includes every history record for the run. By contrast, the sampled view from run.history() can omit individual records. The page_size parameter controls the maximum number of history records fetched per API request and defaults to 1000. If requests are slow or time out, try a smaller page size. Smaller pages can reduce timeout risk but require more API requests. The keys parameter independently filters which metrics are returned.

Export metrics from all runs in a project to a CSV file

This script pulls down the runs in a project and produces a dataframe and a CSV of runs including their names, configs, and summary stats. Replace <entity> and <project> with your W&B entity and the name of your project, respectively.

Get the starting time for a run

This code snippet retrieves the time at which the run was created.

Upload files to a finished run

The code snippet below uploads a selected file to a finished run.

Download a file from a run

This finds the file “model-best.h5” associated with run ID uxte44z7 in the cifar project and saves it locally.

Download all files from a run

This finds all files associated with a run and saves them locally.

Get runs from a specific sweep

This snippet downloads all the runs associated with a particular sweep.

Get the best run from a sweep

The following snippet gets the best run from a given sweep.
The best_run is the run with the best metric as defined by the metric parameter in the sweep config.

Download the best model file from a sweep

This snippet downloads the model file with the highest validation accuracy from a sweep with runs that saved model files to model.h5.

Delete all files with a given extension from a run

This snippet deletes files with a given extension from a run.

Download system metrics data

This snippet produces a dataframe with all the system resource consumption metrics for a run and then saves it to a CSV.

Update summary metrics

You can pass a dictionary to update summary metrics.

Get the command that ran the run

Each run captures the command that launched it on the run overview page. To pull this command down from the API, you can run: