Skip to main content
Training a model on Veri is a single CLI step: submit a job with veri jobs create (or veri run). GRPO jobs carry their reward function as a local Python file, attached to the job at submit. Once submitted, manage the job through completion with list / get / cancel / download.
For a script-driven flow, you can also use veri train <file.py>: it reads a @training_job(...)-decorated function from the file, attaches the decorated function’s source as the job’s reward, resolves the dataset, and submits the job in one call. See the managed GRPO quickstart for the decorator and veri run for the TOML reference.

​
Reward files

A method=grpo job needs a reward function (see Reward functions for the contract). Point the config at a local file:
Or pass it from the command line (this overrides reward.file in the config). With a config file, a relative --reward path also resolves against the config file’s directory:
Before submitting, the CLI runs an AST-only structural check on each reward file:
  • File parses as valid Python.
  • The file defines at least one function.
The check deliberately stops there: verifying the exact signature would require importing user code, which the CLI refuses to do in its own process. If your reward function imports modules missing from the training runtime, the failure surfaces in the training logs once the job starts. Multiple weighted rewards:
Limits: up to 8 files, 256 KiB each. The server re-validates at submit and rejects violations with HTTP 400. The submitted source is stored with the job and viewable on the job’s dashboard page.

​
Training jobs

​
Submit from a config

The config must declare kind = "train". See veri run for the full schema. create returns the job ID. Pipe-friendly form:

​
Submit inline (no config file)

Inline form requires --base-model AND --dataset (a registered dataset’s name or id). Inline jobs always use grpo, so --reward is required too; for another method, use a config file with [method] type.

​
Override config values

The convenience flags --base-model, --gpu-type, --gpu-count, --dataset, --reward expand to --set internally. See Override syntax for type coercion and conflict detection.

​
List, get, cancel, delete

list supports --limit, --after, --status, --method. All commands accept --format json. Under the job’s row, veri jobs get prints what a live job has cost so far at its hourly rate (a finished job shows the rate; its settled cost is in the cost_usd column) and every lifecycle timestamp the job has reached:
--format json carries the same values as cost_so_far_usd, user_rate_per_hour_usd, created_at, launched_at, provision_started_at (billing start), started_at, completed_at and terminated_at. The Training jobs API explains each field.

​
Stream logs

veri jobs logs prints everything the job has logged so far (bootstrap and worker output) and exits. Pass -f/--follow to attach to the live stream until the job reaches a terminal state:
Ctrl+C while following detaches; the job keeps running. Cancel explicitly with veri jobs cancel. Following an already-finished job prints its full log. For scripting, poll status instead:

​
Events

veri jobs events lists the job’s lifecycle events: the launch, each setup stage (dependencies, data, model download), checkpoints, warnings, the outcome and billing. Newest first by default:
--limit is 1 to 500 (default 50). The table shows each event’s time, level, type and message; --format json adds its metadata (download and load durations, checkpoint sizes, the GPU inventory). When more events match an --order asc page, the CLI prints the --after command for the next one. The event types are listed in the API reference.

​
Download a completed checkpoint

The download URL is only populated after the job reaches completed. Trying to download an in-flight job exits 1 with a clear message.

​
Exit codes

​
What’s next

Deploy this model

Serve the checkpoint with an OpenAI-compatible endpoint.

Manage datasets

Upload, connect, and validate training data.

The run verb

Config schemas and --set overrides.

​
Resume a job from a checkpoint

Continues a finished managed job from one of its intermediate checkpoints as a new job, reusing its model, dataset, method, hyperparameters, GPU count and reward functions. See Checkpoints and resume and veri checkpoints.