SIDERIUSSIDERIUS

Tutorial 1 of 3

Run your first workflow from the browser console

Start from an example workflow, review it in the browser console and launch one candidate.

The idea to keep in mind

The console separates save, prepare and launch. Saving and preparing never run anything. Only an explicit Launch runs code and may make paid model calls. Each run captures its own inputs, so later edits affect only future runs.

Before you start

Source of truth: the candidate console README (opens in a new tab)

Steps

  1. Step 1: Copy an example workflow into your project

    The repository ships example declarations in examples/workflow_declarations/ (opens in a new tab). reusable_candidate.py describes one Propose → Implement → Validate candidate; reusable_training.py adds a fourth, native Tune stage. Copy one into your external project and set its task references for your task. Ask your coding agent to do this if you prefer.

    Expected result: a workflow.py in your project. It is ordinary Python; your coding agent can edit it too.

  2. Step 2: Connect the project to the console

    The console reads one configuration file, console.json, in your project. It names the task, data, model profile, output directories and the workflow file. Follow the setup steps (opens in a new tab) to write it and create the access token. Then, from the SIDERIUS checkout:

    .venv/bin/python -m tools.candidate_console check --config /absolute/project/console.json
.venv/bin/python -m tools.candidate_console serve --config /absolute/project/console.json

    The server binds to 127.0.0.1 only. On a remote machine, open an SSH tunnel and browse to http://127.0.0.1:8740.

    Expected result: check prints the browser address and the token file location. It checks paths, file shape and permissions only; it does not prove provider access.

  3. Step 3: Connect and open the Workflow Editor

    Open the page, paste the console token and select Connect. Then choose Workflow Editor.

    Expected result: your workflow drawn as connected nodes. Selecting a node opens an inspector with its supported settings.

  4. Step 4: Review, then save

    Make a small edit, or none. Select Review changes and read the diff before saving. If the workflow is not yet bound to a task version, the task-version guide (opens in a new tab) shows how to bind it first.

    Expected result: the exact Python diff of your change. After Save reviewed source, those bytes are written to your workflow.py. Nothing has run.

  5. Step 5: Prepare a new run

    In New run, choose the configured task and resources, enter a run name and select Review preparation. Check the source, dataset, model profile, destinations and resource limits. Then select Prepare saved source.

    Expected result: the preparation reports prepared. Preparation is offline and needs no provider keys; it captures your saved source and inputs into a fresh run directory.

  6. Step 6: Review the capture and launch

    Select Open prepared run, then Review capture. Check the model routes and credential readiness; a known blocker disables launch. When you are ready to spend, select Launch captured run. Keep the operation ID: it is how you reopen the run later.

    Expected result: an operation ID and a monitor view. The candidate runs Propose → Implement → Validate, plus native Tune if your source declares it. A finished run is not a scientific success verdict: read its validation outcome.

Other ways to start from the console

  • Configured task: on Home, expand Prepare configured task to prepare and launch one candidate without the Workflow Editor.
  • Configured native chain: launch a multi-iteration chain captured beforehand by your coding agent. See the native-chain instructions (opens in a new tab).

Next, tutorial 3 shows how to follow the run you just launched.