CLI

There is no Ertas CLI today. Ertas is browser-only, the canvas is the primary surface, and every workflow described in the docs is keyboard-and-mouse rather than command-line. A CLI is on the roadmap, alongside a programmatic API; both are tracked in the Known limitations page.

This page exists so that pointers to "the CLI" from other docs do not lead to a 404. When the CLI ships, it will be documented here; until then, the page lays out what is coming and what to use today.

What the CLI will do

The intended surface, when it ships:

The shape will follow the conventions of common developer CLIs: configuration via ~/.ertas/config.yaml, output in human-readable or --json formats, exit codes that integrate with shell scripts.

What to use today

Ertas's UI covers everything the CLI will expose. If you are scripting something, the alternatives below are what most teams use in the meantime.

For training many configs in a sweep

Build the recipe variants on the canvas and queue them. Ertas's Parallel runs supports as many simultaneous runs as your plan allows; the canvas pattern is to drop one Action Module per variant and link them to a shared dataset.

For larger sweeps that exceed comfortable canvas drag-and-drop, the workaround is to author one Action Module, queue a run, then duplicate the module on the canvas (right-click, Duplicate) and edit the config. Ertas remembers the config snapshot per module, so the new run carries the new config independently.

For uploading or downloading data programmatically

There is no scripted upload path today. Datasets enter Ertas via the Data Craft upload dialog (Datasets overview) and leave Ertas via the per-dataset download action (when dataset export ships). Artifacts (LoRA, GGUF) leave Ertas via the per-run download action in Hub.

For teams that need bulk operations today, the practical workaround is browser-side: keep a single tab open with the project, download artifacts in sequence as runs finish, and write a unzip script to extract them into a known directory layout. It is ugly but it works for tens of runs.

For CI integration

There is no webhook today and no API endpoint to trigger a run. Teams that want a "merge a recipe PR, run the fine-tune" loop are blocked on the API roadmap.

The closest current pattern: the canvas auto-saves, so a designated reviewer can open the project, make the change, and press play. It is human-in-the-loop, not automated. The API and webhooks together will unblock the CI pattern when they ship.

For viewing logs

Run logs stream into the Run panel. There is no log-download button; if you need logs for a support ticket, the support flow is to send the run ID and Ertas pulls the server-side logs. The feature backlog tracks log-download as a possible-future-but-not-prioritised item.

Why a CLI is not a launch blocker

For most teams, the canvas is faster than a CLI for the work that defines a fine-tuning project: picking models, building datasets, configuring runs, comparing results. A CLI is the right tool for repeated bulk operations and CI integration, but the median user runs five to twenty fine-tunes total across a project's life and benefits from the visual surface more than from scripting.

When the CLI ships, the workflows that benefit most will be:

• Productionisation: continuously retraining a model as new data arrives, with the trigger in a CI pipeline.
• Bulk experimentation: large hyperparameter sweeps that exceed comfortable canvas drag-and-drop.
• Multi-project hygiene: scripted cleanup of stale runs, artifacts, and datasets across many projects.

Until then, this page is a placeholder. When the CLI ships, the placeholder will be replaced with the full command reference.

What's next