Skip to main content

Artifact

An artifact is a file or directory the platform stores and can put on a device: a dataset, a set of model weights, a script, a config file, a compiled engine bundle, an archive. Anything a job or a service needs on disk arrives as an artifact.

Why it exists​

A benchmark is only reproducible if the inputs are. An artifact gives a file an identity (a name, a version, a checksum) so a run can say exactly what it used, and so the platform can decide whether the file already needs transferring at all. It is also the boundary for cleanup: the platform knows what it put on a device, which is what lets it take it away again.

Fields​

FieldWhat it is for
name, descriptionHow you find it again.
versionYour own version string (v1.0, 2026-03-05, q4-quantized). Optional and worth setting.
typedataset, model_weight, script, config, docker_context, binary, archive, docker_image, git_repo, other. A label for humans, not a behavior switch.
size_bytes, checksum_sha256Computed on upload. The checksum is why a repeat push transfers nothing.
content_formatfile (default) or directory. A directory artifact is stored as a tar.gz and extracted into the destination path on the device.
tagsKey and value pairs you filter on.
expires_atWhen the artifact is swept, if a retention window applies.

Versions and tags​

Uploading a new version keeps the artifact in the same lineage and moves the latest tag to it. You can add your own tags (stable, v2, golden) and point them at any version in the lineage, the way Docker tags work.

A job or service definition refers to an artifact by lineage plus an optional tag, and the platform resolves the tag to a concrete version at dispatch. That is the useful part: a definition that says tag: latest picks up your new upload without being edited, and a definition that says tag: golden keeps running the version you blessed. A tag that does not exist fails the dispatch rather than falling back to something else.

Transfer and deduplication​

Before pushing an artifact the agent checks whether the destination path already holds a file with the same SHA-256. If it matches, the transfer is skipped entirely.

This is worth knowing because it shapes how definitions are written. A benchmark that stages a multi-gigabyte engine bundle is slow the first time on a device and fast afterwards, which is why definitions that push large engines usually leave them in place instead of cleaning them up after every run.

External artifacts​

An artifact does not have to be a file the platform stores. It can also be a reference the device fetches itself, which is how a container image or a repository of code joins the same library as an uploaded file.

Two kinds exist.

A Docker image (docker_image) carries a standard image reference: nginx:1.25, ghcr.io/org/app:v2.1, my-registry.example.com:5000/team/model:latest. At dispatch the agent runs docker pull, optionally for a named platform on a multi-architecture image, and reports the digest and size it actually got.

A Git repository (git_repo) carries an HTTPS clone URL. The agent runs a shallow clone into the destination path, at a branch, tag or commit when the reference names one, and reports the commit it landed on.

What you can do with them:

  • Keep a benchmark harness in Git rather than in an upload. Point a job definition at the repository and every run clones the current state of the branch you named, so fixing the harness is a push rather than a re-upload.
  • Run a container as a managed service. A Docker image artifact plus a service definition of type compose or process is how a device runs something the platform did not build.
  • Version them like any other artifact. A new version of an external artifact points at a different tag or ref, so the lineage records which image or commit each run used.
  • Authenticate to a private registry or repository. The artifact stores a reference to a registry credential rather than the secret. The platform resolves the credential at dispatch and hands the agent what it needs for that one pull, so rotating the credential does not mean editing artifacts.

Three properties follow from the platform holding no file:

  • The artifact's size is zero until the agent reports what it pulled, and its checksum is the digest or commit the agent saw rather than one the platform computed.
  • There is nothing to download from the platform, so the download endpoint answers 404 for an external artifact.
  • The device has to be able to do the pull. An agent reports whether it has Docker and Git available when it registers, and a dispatch that needs a capability the agent lacks is refused at dispatch time rather than failing halfway through a run.

Retention and cleanup​

Artifacts accumulate, and a benchmark campaign's intermediates can reach tens of gigabytes, so the library has an explicit lifecycle.

  • Filters that express a cleanup. The artifact list filters on type, tag, search text, creation date and size, so "older than 30 days and bigger than 1 GB" is a query rather than a manual review.
  • Batch delete over the same filters, bounded per call and with a dry run that shows you what would go. An artifact still referenced by a job or service is reported as in use and skipped, so a batch never has to be all-or-nothing.
  • A retention window. An organization can set a default retention in days, which stamps an expiry on every upload; an individual artifact can carry its own expiry or none at all. Platform-generated artifacts (job outputs, dataset builds) are not stamped.
  • A sweeper removes expired artifacts after a grace window, skipping anything still referenced or mid-transfer, and every deletion is recorded in the audit log.

Job output becomes an artifact​

When a benchmark job finishes, the platform fetches the file at the job's declared output path and stores it as an artifact linked back to the job. If the job declared structured results, that same file is also parsed into the result you read in the UI. The raw file stays downloadable either way, which is what you reach for when you want the numbers in their original form.

Where you see it​

Artifacts in the sidebar is the library: upload, register an external source, browse versions and tags, set an expiry. A device's Files tab can also push straight from the library, and save a file fetched from a device back into it.

  • Job: where artifacts are pushed and output is collected.
  • Service: the other consumer of artifacts.
  • Write a job definition: how a definition refers to an artifact and its tag.