Skip to main content
Glama

train_start

Manage LoRA training jobs: launch runs on local GPU or RunPod, check progress, cancel, delete, and preview job configurations before starting.

Instructions

Run and inspect LoRA training JOBS — launch a run, poll it, stop it, delete it, and read back the settings behind it. Jobs are keyed by id; the datasets they train on live in the separate train_prepare_dataset tool and are keyed by name. Driven by the action parameter:

  • action:"start" — Start a LoRA training job: target 'local' builds the config and launches the GPU trainer container (docker run --gpus all); target 'pod' ssh-drives pod-native training on a connected RunPod pod (pod_id, or the connector's currently connected pod). Requires name + datasetPath. Returns a job id for action:"status"/action:"cancel". Long-running — returns immediately; poll action:"status". On completion the LoRA is delivered per deliverTo (pod/local/both) and cataloged when local. Run train_doctor first if unsure the image/docker/GPU (local) or bootstrap (pod) are ready.

  • action:"status" — Check training progress: pass an id for one job (step/total, loss, recent samples, log tail, result paths when done) or OMIT id for all jobs newest-first. Read-only.

  • action:"cancel" — STOP a RUNNING job (docker stop) by id and mark it cancelled. Nothing is erased: checkpoints already saved stay in the job's output dir; no LoRA is handed off to models/loras, so the run can be inspected afterwards. Returns ok:false when the container could not be confirmed stopped (the job reverts to running). This is the RECOVERABLE stop — use action:"delete" only when you also want the artifacts gone.

  • action:"delete" — DESTROY a finished job by id: its record AND its output dir with checkpoints/samples, unless keep_outputs is true. Irreversible — confirm with the user first. The delivered LoRA in models/loras is NOT removed. Running/queued jobs must be cancelled first (action:"cancel"). THIS DELETES A JOB, NOT A DATASET: to delete the staged images and captions a run consumed use the separate train_prepare_dataset tool with action:"delete", which is keyed by name rather than id.

  • action:"list_flows" — List the LoRA training flows and base models the local trainer supports (phase 1: character LoRA on FLUX.1-dev), with the default training params. Read-only, takes no other parameters — call this first to see what action:"start" accepts.

  • action:"job_config" — Show the effective settings a job ran with by id (steps/lr/rank/resolution/batch/saveEvery/sampleEvery/quantize), read back from the ai-toolkit config.yml it consumed, plus flow/model/trigger/datasetPath — everything needed to run the job again with tweaks. Read-only.

  • action:"preview_config" — Show the RAW ai-toolkit config.yml action:"start" WOULD write for these settings (the ostris-UI 'raw config' view) — no side effects, nothing is written or started. Requires name + datasetPath. Use it to review a run before launching; pass the same params to action:"start" to execute.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoTraining job id, as returned by action:"start" (e.g. "t8f3k2ab") — NEVER a dataset name. REQUIRED and must be non-empty for actions "cancel", "delete" and "job_config". OPTIONAL for action:"status": omit it (or pass an empty string) to list every job newest-first. Unused by "start", "list_flows" and "preview_config".
flowNoaction:"start" — training flow (see action:"list_flows").character
nameNoJob name — becomes the output .safetensors basename (e.g. 'aria_character'). REQUIRED for actions "start" and "preview_config". This names the RUN, not the dataset it reads.
modelNoaction:"start" — base model (see action:"list_flows").flux1-dev
actionYesWhich training-job operation to perform. "list_flows" takes no other parameters; "status" takes an OPTIONAL `id` (omit for all jobs); "cancel", "delete" and "job_config" require `id`; "start" and "preview_config" require `name` + `datasetPath`. NOTE "delete" here destroys a training JOB — deleting a staged DATASET is train_prepare_dataset action:"delete".
deviceNoaction:"start" — GPU selector, default cuda:0.
paramsNoTraining param overrides for actions "start" and "preview_config" (steps/lr/rank/resolution/batchSize/saveEvery/sampleEvery/quantize). Omitted keys fall back to the defaults from action:"list_flows". action:"preview_config" enforces the SAME bounds action:"start" does, so a preview always reflects a run that could actually launch.
pod_idNoaction:"start" — RunPod pod to train on (target 'pod'). Default: the connector's currently connected/watched pod.
targetNoaction:"start" — 'local' = docker on this rig; 'pod' = pod-native over ssh on a RunPod pod.local
triggerNoUnique trigger word (e.g. 'ohwx person') — injected as trigger_word and usable in prompts.
deliverToNoaction:"start", pod jobs only: where the finished LoRA lands.both
model_pathNoaction:"start" — override the base model path AS THE TRAINER SEES IT (pod path for target 'pod', container path for 'local') — e.g. a pre-uploaded local HF snapshot dir when the default HF repo id is gated/unreachable.
datasetPathNoDataset dir from train_prepare_dataset (images + same-basename .txt captions). REQUIRED for actions "start" and "preview_config".
keep_outputsNoaction:"delete" — keep the job's output dir (checkpoints/samples) and delete only the record.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully discloses behavioral traits: launching docker containers, ssh-driven pod training, long-running behavior with polling, docker stop for cancel, irreversibility of delete, and no-side-effect guarantees for preview_config. It also documents what happens on completion (delivery per deliverTo, cataloging when local) and recovery behavior if cancel fails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but perfectly structured with a front-loaded summary followed by action-based bullets. Each sentence earns its place, covering all seven actions, required parameters, side effects, and safety warnings. The organization makes the density manageable and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex 14-parameter tool with six actions, nested params, and no output schema or annotations. The description addresses all operational aspects: prerequisites, side effects, safety, read-only actions, and next steps after completion. It even covers edge cases like cancel reverting to running and delete requiring cancellation first. The coverage is comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description adds significant meaning beyond the schema: it specifies which parameters each action requires, clarifies that `name` names the run not the dataset, gives examples for id and trigger, and explains parameter fallback behavior. It also notes that preview_config enforces the same bounds as start, adding practical semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear, specific statement: 'Run and inspect LoRA training JOBS — launch a run, poll it, stop it, delete it, and read back the settings behind it.' It also explicitly distinguishes from the sibling train_prepare_dataset tool by noting jobs are keyed by `id` while datasets are keyed by `name`. This is a specific verb+resource combination that fully disambiguates the tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage guidance per action, including when to omit `id` for status, when to use `cancel` vs `delete`, and when to call `list_flows` first. It names alternatives like train_prepare_dataset for dataset deletion and train_doctor for readiness checks, providing clear when-to-use and when-not-to-use context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/artokun/comfyui-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server