Skip to main content
Complete authentication and context selection first. These examples use your active profile and saved project context. Confirm the destination before starting work:
Choose commands according to the resource you are operating on: A Flow ID, task ID, and MLOps job ID identify different resources. A Flow run does not necessarily create an MLOps job. Do not pass an arbitrary returned id into another command group.

​
Run an existing Flow

Discover the Flow and inspect its id, mode, device, and input_schema:
This command returns the project’s Flow array and has no list limit option. Read only the fields needed for your chosen Flow. Prepare ./flow-input.json as a JSON object matching that Flow’s input schema. Use {} only when the Flow accepts no required inputs. Replace FLOW_ID_FROM_LIST below with the exact selected ID:
The command submits to the Flow runs endpoint and prints the returned JSON object. Inspect it before selecting any ID, status, result, or follow-up URL: the CLI does not impose a single response schema or automatically wait for completion. There is no universal Flow results or logs command in this command group. Follow the instructions for checking progress and retrieving results for that Flow’s execution mode. If the response identifies a separate MLOps job, use that confirmed job ID with the job commands below. --device overrides the device for an IoT-backed run. The current flows run --dry-run request preview shows a different endpoint from the actual run submission, so it is not an authoritative preview of the executed request. Confirm the selected Flow and inputs before invoking a run.

​
Send work to an Agent task

Find the Agent in your saved project context:
Inspect IDs and names before selecting an Agent. Agent and task lists support --offset for subsequent slices. Use an existing task when continuing its conversation. For a new chat runtime, replace example Agent ID 27 with the selected Agent’s ID:
Inspect the response’s task_id, thread_id, status, and reused. This operation can reuse a runtime. Use its numeric task_id for tasks commands; the thread ID is a different identifier. Alternatively, tasks create --agent-id 27 --title "Review the sample" creates a task record and returns its id. Creating a record or preparing a runtime alone does not demonstrate that your requested work completed. Replace example task ID 83 with the returned task ID. Review the prompt preview, then submit:
Inspect the returned status fields for completion, errors, or a request for user input. A successful post-message request confirms acceptance of that request, not successful completion of the task. messages --summary reports message counts and sizes without message content, but still fetches the messages. For a bounded read of recent checkpoint content, use the thread_id returned by runtime preparation or task details:
Inspect messages and returned in the checkpoint page; a recent slice is not the complete conversation. If you need the task messages response, use:
That command has no message-limit option. The CLI has no generic task wait command; space out status checks and impose a deadline in your own automation.

​
Follow an MLOps job

For one training submission, find a registered dataset and a supported architecture in your saved project context:
Replace the quoted names with discovered values. Read the architecture’s schema and prepare ./hyperparameters.json as a matching JSON object. Choose the intended output model name. The architecture list and schema reads have no local limit option. Check compatibility with the dataset before submitting; training can allocate compute. Review the request, then submit it once:
Inspect the full submission response. Copy its actual job_id into the commands below, after confirming it identifies the submitted MLOps job. The response comes from the server without a fixed client model; if no usable job_id is present, inspect the response and job inventory before continuing. Do not substitute a model ID, a Flow run ID, or a guessed job name. To find an existing job or reconcile a submission:
Inspect the returned collection before extracting an ID. Local --name, --status, --limit, and --offset shape the fetched job collection; they do not guarantee backend pagination. Replace JOB_ID_FROM_RESULT with the exact job ID:
wait returns job_id, status, terminal, polling details, and the last job. It exits 0 for a recognized successful terminal state and 1 for a recognized failure or a polling timeout. A timeout result has timed_out: true and terminal: false; it stops waiting and does not cancel the job. Unknown statuses continue polling until the deadline. watch provides the same bounded polling with progress output when JSON mode is off. logs --tail 50 trims the fetched logs locally. Use --contains to filter or --output ./job.log to save them. stream-logs waits for the backend stream to finish and has no command-level duration limit, so prefer fetched logs for bounded inspection. Metrics and job details are separate from application result artifacts: inspect the actual returned metadata and use the workload’s documented artifact retrieval workflow. Do not assume a generic results command exists. If a run submission, runtime preparation, or message post times out, the server may already have accepted it. Reconcile task lists, messages, job inventories, and any returned identifiers before retrying. Do not automatically repeat mutations: duplicate runs or prompts can create duplicate work. See scripting and output for exit status and partial-output handling, and troubleshooting for recovery checks.