AxonOS is a GPU-native interface for research work. This post walks through the shape of a typical workflow rather than the API surface.

Staging a dataset

Workflows begin with a dataset definition rather than an ad-hoc upload. The definition records where the data came from, what transformations were applied, and which access conditions govern it.

A run that cannot state which version of a dataset it consumed cannot be re-executed with confidence later.

Defining the run

A run specifies:

  1. The dataset version to read.
  2. The container image and its pinned dependencies.
  3. The GPU class requested.
  4. The output location and retention.

Pinning the image is the step most often skipped and most often regretted. An unpinned base image means a run repeated six months later is a different experiment.

Execution

Runs are scheduled onto available fleet capacity, submitted with axonos run submit, passing --dataset cohort-2026-06:v3, --image registry.example/analysis@sha256:..., --gpu v100, and --out s3://results/run-4417.

Queue position depends on the requested GPU class and current utilization — a smaller GPU class will often start sooner than waiting for the largest available.

Reproducibility

Every completed run emits a manifest recording the dataset version, image digest, hardware class, and duration.

A result that cannot be re-executed by a third party is a claim, not a finding.

Current limitations

Multi-node distributed training is not yet exposed through the workflow interface, and long-running jobs beyond the scheduling window need manual checkpointing. Both are on the roadmap.