lote¶
One command plane for your machines.
A DGX over ssh, a slurm cluster, a pbs supercomputer, the spare box under the desk. Each runs jobs its own way, so the same experiment needs pueue here, sbatch there, and qsub somewhere else. lote is the plane that sits over all of them. You pick a machine, it rsyncs your repo there, runs your job under whatever scheduler that host has, and pulls the results back. One job script runs anywhere.
-
One submit
lote submit <host> job.shships the repo, launches the job, and prints a handle. No matter the scheduler. -
Any scheduler
lote detects each host's queue and adapts.
pueueon a plain box,sbatchon slurm,qsubon pbs. -
State across hosts
lote psandlote reconciletrack every run across every machine from your laptop. -
Just ssh
Targets are your
~/.ssh/confighost aliases. No agent to install, no control daemon to babysit.
Installation¶
pip install lote # the lote command, ready to use
chefe add lote --pypi # or pull it into a chefe project
lote dispatches its on-host executor over ssh as chefe run lote exec ..., so each host needs chefe (the sibling env tool), which lote setup installs and which brings up pixi on first run.
[sync]
include = ["research", "toolbox", "pixi.toml"] # what a compute node needs
exclude = ["**/.venv", "**/__pycache__", "**/*.ckpt"] # heavy, regenerable
lote setup miyabi # onboard a host: probe, sync, build the env
lote submit miyabi train.sh # ship the repo and launch, prints a handle
lote ps # recent runs across every machine
lote pull <handle> # rsync the results back
lote is early (0.0.x)
The config format and commands may still change.
Next¶
- How it works — the dispatch pipeline and its three layers.
- Commands — the full CLI.
- Configuration —
lote.toml, ssh targets, and the state store. - Examples — real end-to-end workflows.