veri run <config.toml> is a thin shortcut over the explicit veri jobs create / veri deployments create / veri evals create. It reads the required kind field from the config and dispatches.
The contract is plural-noun-verb (veri jobs create configs/train.toml); veri run exists to save typing on the common path.
Scaffold a project: veri init
veri init NAME writes 9 files into ./NAME. With no NAME, scaffolds into the current directory.
init refuses to write into a non-empty directory. Use --force to scaffold alongside existing files (existing files are preserved):
Dispatch rules
Every config starts with a requiredkind line:
veri run <path> reads kind and routes:
Missing
kind or an unknown value errors with a “did you mean” hint:
Override TOML fields from the CLI
Use--set <dotted.key>=<value> to override any nested value. Convenience long-flags expand to --set internally.
Type coercion
Values parse as TOML scalars:true / false, integers, floats, ISO timestamps, quoted strings. To force a string on a numeric-looking value, use --set-string:
Repeated flags build a list
Conflict detection
The merger rejects setting a scalar and a sub-key at the same path:Convenience long-flags
These flags are sugar over--set on veri jobs create:
Config schemas
veri.toml (project root)
configs/train.toml
In Phase-1,
[dataset].id and [reward].id must reference already-registered IDs. Upload first with veri datasets upload / veri rewards upload, then paste the returned IDs into the config.configs/deploy.toml
configs/eval.toml
--dry-run before submitting
On veri jobs create (and veri run with kind="train"), --dry-run validates the config without submitting:
It prints the resolved GPU config plus a cost estimate (illustrative values):
--format json for the same fields as a JSON object (gpu_type, gpu_count, provider, duration_minutes, rate_usd_per_hour, estimated_cost_usd, markup).
What’s next
Datasets
Upload, connect HuggingFace, validate.
Training
Rewards + jobs end-to-end.

