Jobs: one command on its own GPU

Most GPU work is a command that should run once and then stop: a fine-tune, an evaluation, a batch of transcriptions, a test suite that needs CUDA. On an instance you start the machine, run the command, watch it, and remember to shut it down. A job does all of that for you.

Every job carries a maximum runtime (up to 7 days), so a command that hangs never runs unbounded.

Ask your agent

Connect Runcrate to your agent (one line in Claude Code or Codex, one click in Cursor), then say what you want:

The agent finds the volume, submits the job with run_job, follows the logs with get_job_logs until the job is done, reads the loss from the output, and checks the final status, exit code and cost with get_job. From a terminal, the CLI does the same, and follows the logs until the job ends:

1runcrate run --gpu A4000 \
2  --template ubuntu-train \
3  --volume <volume-id> \
4  --max-runtime 2h \
5  -- python train.py

The Python and TypeScript SDKs have the same calls under jobs, and send an Idempotency-Key with every submit, so a retried request never starts a second job.

What a job handles for you

• Capacity. Give a list of GPUs to try in order, and the job waits for one instead of failing: 30 minutes by default, up to 24 hours.
• Failed machines. With retries on, a machine that fails is replaced and the command runs again, up to 10 times.
• Many runs at once. One request can start up to 100 jobs, as shards with count or a sweep with params, a few at a time with max_parallel.
• Your code. Send a directory as an upload or point at a git repository; it lands in /workspace/code before your command starts.
• Outputs. Whatever your command writes to $RUNCRATE_OUTPUT_DIR is kept 30 days after the job ends, without a volume.
• Containers. Set image and the command runs in your container with the GPUs passed in, private registries included.
• Secrets. Every job gets its environment's secrets as variables; one-off values go in env and are stored only encrypted.

Watch it, or don't

Logs stream live and are kept 30 days. While the command runs, the machine samples each GPU's use and memory every 15 seconds, and every job has a timeline (machine up, driver ready, code fetched, image pulled, started, exited) so you can see where its time went or why it failed before your command ran. A signed webhook tells your code when a job ends, and you get an email when one fails, at most one an hour for a workspace.

The Jobs page follows your first job step by step, then lists every run with its logs, outputs and cost. A job's machine belongs to the job: it never shows on the Instances page.

What it costs

A job is billed at its machine's hourly rate from when the machine is running until it stops; setup is included and waiting for capacity is free. The maximum runtime counts from when your command starts, so setup never uses it up. cost_usd on the job is the total so far, every attempt added up.

Read the Jobs docs for every field and limit, or run your first job.