ML-Dash API Reference
Complete API reference for ML-Dash Python SDK.
Table of Contents
Experiment
The Experiment class is the main entry point for ML-Dash. It represents a single machine learning experiment run.
Experiment Constructor
Prefix Format
The prefix is a universal key that identifies your experiment:
- owner: First segment (e.g., your username)
- project: Second segment (e.g., project name)
- path: Remaining segments form the folder structure
- name: Derived from the last segment
| Parameter | Type | Default | Description |
|---|---|---|---|
prefix | str | None | Universal key in format owner/project/name |
readme | str | None | Human-readable description of the experiment, stored as its description on the server |
tags | List[str] | None | Tags for categorization and search |
bindrs | List[str] | None | Binders for advanced organization |
metadata | Dict[str, Any] | None | Additional structured metadata |
dash_url | str | bool | None | Server URL. True uses ML_DASH_API_URL, or https://api.dash.ml if unset. None means no server |
dash_root | str | ".dash" | Local storage directory. None means no local copy |
Any other keyword argument is passed to the run configuration (RUN).
Unknown keywords are not an error, so a misspelled argument, or
description= instead of readme=, is silently ignored.
Mode Configuration
dash_url and dash_root together choose where data goes:
dash_url | dash_root | Mode | Writes to |
|---|---|---|---|
None (default) | ".dash" (default) | local | the local directory only |
a URL or True | ".dash" (default) | hybrid | the server and the local directory |
a URL or True | None | remote | the server only |
The chosen mode is available as experiment.mode (an OperationMode).
Lifecycle Management
Experiments are managed through the run property, which returns a RunManager instance. The RunManager supports three usage patterns:
1. Context Manager (Recommended)
Automatically starts and completes/fails the experiment:
2. Decorator Pattern
Perfect for wrapping training functions:
3. Manual Control
Explicit start/complete for fine-grained control:
RunManager Methods
| Method | Description | Status Set |
|---|---|---|
run.start() | Start the experiment | RUNNING |
run.complete() | Mark experiment as successfully completed | COMPLETED |
run.fail() | Mark experiment as failed | FAILED |
run.cancel() | Mark experiment as cancelled | CANCELLED |
Experiment Properties
| Property | Type | Description |
|---|---|---|
experiment.name | str | Experiment name (last prefix segment) |
experiment.project | str | Project name (second prefix segment) |
experiment.owner | str | Owner namespace (first prefix segment) |
experiment.readme | str | Experiment description, as passed to readme= |
experiment.tags | List[str] | Experiment tags |
experiment.mode | OperationMode | LOCAL, HYBRID, or REMOTE |
experiment.id | str | Experiment ID (remote mode only, after start) |
experiment.data | dict | Full experiment data (remote mode only, after start) |
Parameters
Access experiment parameters through the params property (not a method).
Setting Parameters
Getting Parameters
Parameters API
| Method | Returns | Description |
|---|---|---|
params.set(**kwargs) | ParametersBuilder | Set/merge parameters (supports nested dicts) |
params.get(flatten=True) | dict | Get parameters (flattened or nested) |
Note: Parameters are automatically flattened for storage using dot notation:
- Input:
{"model": {"lr": 0.001}} - Stored as:
{"model.lr": 0.001}
Logging
Log messages with different severity levels and optional metadata.
Basic Logging
Logging with Metadata
Fluent Logging API
Log Levels
| Level | Description |
|---|---|
debug | Detailed diagnostic information |
info | General informational messages (default) |
warning | Warning messages for potential issues |
error | Error messages for failures |
Metrics
Track time-series metrics like loss, accuracy, etc.
Basic Usage
Log train and eval metrics together:
Prefix-Based Logging
Log metrics using namespace prefixes:
A bare exp.metrics.log(epoch=epoch) writes to a separate unnamed series and
is not attached to the train/eval rows.
Buffer API
For high-frequency logging (per-batch), use the buffer API:
Multiple Aggregations
Reading Metrics
Metrics API
| Method | Parameters | Returns | Description |
|---|---|---|---|
metrics(prefix) | str | MetricBuilder | Create/get metric builder with prefix |
metrics.log(**data) | Flexible data fields | MetricBuilder | Log metric data point |
metrics("prefix").log(**data) | Flexible data fields | MetricBuilder | Log with prefix |
metrics("prefix").buffer(**data) | Flexible data fields | None | Buffer values for summary |
metrics.buffer.log_summary(*aggs) | aggregation names | None | Log summary statistics |
metrics.flush() | - | None | Flush pending metrics |
metrics("prefix").read(start_index, limit) | int, int | dict | Read data points |
metrics("prefix").stats() | - | dict | Get metric statistics |
Files
Upload, download, and manage files associated with experiments.
Basic File Upload
Enhanced File Operations
Save JSON Objects
Save PyTorch Models
Save Pickle Objects
Save Matplotlib Figures
Save Videos
File Organization with Bindrs
Listing Files
Downloading Files
File Management
Files API
| Method | Parameters | Returns | Description |
|---|---|---|---|
file(**kwargs) | See below | FileBuilder | Create file builder |
save() | - | dict | Upload file |
save_json(content, filename) | Any, str | dict | Save JSON object as file |
save_torch(model, filename) | Any, str | dict | Save PyTorch model as file |
save_pkl(content, filename) | Any, str | dict | Save Python object as pickle file |
save_fig(fig, filename, **kwargs) | Optional[Any], str, **kwargs | dict | Save matplotlib figure as file |
save_video(frames, filename, fps, **kwargs) | Union[List, Any], str, int, **kwargs | dict | Save video frame stack as file |
list() | - | List[dict] | List files |
download(pattern, to) | Optional[str] | str | Download file |
update() | - | dict | Update file metadata |
delete() | - | dict | Delete file |
FileBuilder kwargs:
| Parameter | Type | Description |
|---|---|---|
path | str | Logical path/prefix (e.g., "models", "configs") |
description | str | File description |
tags | List[str] | File tags |
bindrs | List[str] | File bindrs |
metadata | dict | File metadata |
file_id | str | File ID (for download/update/delete) |
dest_path | str | Destination path (for download) |
Auto-Start (dxp)
The ml_dash.auto_start module provides a pre-configured, auto-started experiment singleton named dxp for quick prototyping and scratch work.
Overview
The dxp singleton is:
- Pre-configured: Name is "dxp", project is "scratch", storage is local (
.dash) - Auto-started: Ready to use immediately on import - no need to call
.run.start() - Auto-cleanup: Automatically completed on Python exit via
atexithandler - Fully-featured: Works exactly like a normal
Experimentinstance
Import
Usage
Basic Usage
Interactive/Notebook Usage
Perfect for Jupyter notebooks and interactive Python sessions:
Prototyping Scripts
Great for quick experiments and throwaway scripts:
Configuration
The dxp singleton has a fixed configuration:
| Property | Value | Changeable |
|---|---|---|
| Name | "dxp" | No (read-only) |
| Project | "scratch" | No (read-only) |
| Storage Mode | Local (.dash) | No (fixed at initialization) |
| Local Path | ".dash" | No (fixed at initialization) |
| Parameters | Empty (initially) | Yes (during lifecycle) |
| Tags | Empty (initially) | No |
| Description | None | No |
Lifecycle
Unlike normal experiments, dxp handles lifecycle automatically:
Manual Lifecycle Control
You can still manually control the lifecycle if needed:
Comparison with Regular Experiment
| Feature | Regular Experiment | dxp Singleton |
|---|---|---|
| Import | from ml_dash import Experiment | from ml_dash.auto_start import dxp |
| Configuration | User-defined | Fixed (dxp/scratch/local) |
| Lifecycle | Manual or context manager | Auto-started, auto-completed |
| Use Case | Production experiments | Quick prototyping, notebooks |
| Storage | Local or remote | Local only (.dash) |
| Reusable | Create multiple instances | Single global instance |
Best Practices
- Use for Prototyping:
dxpis perfect for quick experiments and scratch work - Not for Production: Use regular
Experimentfor production code - Notebook Sessions: Ideal for Jupyter notebooks and interactive sessions
- Single Session: Best for single-run scripts; for multiple runs, use regular
Experiment - Local Development: Great for local development and debugging
Example: Complete Prototype
Complete Examples
Complete Training Workflow
Hyperparameter Search
Decorator Pattern for Training Functions
Remote Mode with Team Collaboration
Error Handling
Experiments handle errors gracefully:
The experiment status will be set to FAILED automatically, and all logs, parameters, and metrics are preserved for debugging.
Best Practices
- Use Context Managers: Prefer
with exp.run as exp:for automatic lifecycle management - Descriptive Names: Use clear, descriptive experiment names and project names
- Add Tags: Use tags for easy filtering and organization
- Log Liberally: Log important events, errors, and milestones
- Structured Metadata: Use metadata for searchable, structured information
- Organize Files: Use logical prefix paths for file organization
- Version Control: Use bindrs and tags to track model/data versions
- Remote for Teams: Use remote mode for team collaboration and data persistence