Awaitless

Adaptive durable execution for coding agents.

Run commands through one execution layer. Quick work returns inline; longer or queued work becomes durable across local, SSH, and Slurm. Your workload stays on infrastructure you already own.

Agents submit work. Awaitless owns execution.

Awaitless is the adaptive durable execution layer between coding agents and the compute they use. It gives agents one stable job contract while reusing your local machine, SSH hosts, and Slurm clusters underneath.

简体中文 · Documentation · Benchmarks · PyPI

One job lifecycle across your existing compute

Coding agent → submit work → Awaitless owns the job lifecycle → Local / SSH / Slurm

Awaitless owns the job lifecycle, not the hardware. It does not discover resources, understand GPU topology, allocate multiple resources, or replace a cluster scheduler. Operators name queues and set fixed concurrency; Slurm continues to handle requests such as --gpus 2 --mem 64G and all physical cluster scheduling.

Your coding agent should write code, not babysit jobs

An agent can write its own run → sleep → check loop. The harder problem is making job identity, disconnect recovery, queue admission, cancellation, and result delivery reliable across long workloads and changing sessions. Without that execution layer, the agent repeatedly pulls the same growing log back into its context:

ssh gpu 'run_benchmark > job.log 2>&1 &'
ssh gpu 'tail -n 200 job.log'  # again...
ssh gpu 'tail -n 200 job.log'  # and again...

Awaitless turns that lifecycle into one adaptive execution call and one result boundary:

awaitless run --json --host gpu --artifact results.json -- ./run_benchmark
# quick: {"state":"succeeded","delivery":"inline","exit_code":0,...}
# longer: {"job_id":"job_019F...","state":"running","delivery":"detached",...}

awaitless wait job_019F... --json
# {"state":"succeeded","exit_code":0,"parsed_results":{...}}

Detached JSON also includes job_state, wait_state, delivery_state, and a ready-to-copy next_command. A client-side wait timeout is not a workload failure: use awaitless wait --last --json for the most recently detached Job, or use the returned command with its stable Job ID. To inspect benchmark lines without reading a large tail, use awaitless logs <job-id> --grep 'PASS|FAIL|median|CV'.

Every run is durable before launch. Finishing within the inline window looks like an ordinary command result; crossing it only detaches the waiter. Interrupt the waiter, close the MCP client, or start a fresh agent session: the Job keeps running and its stable ID recovers the result.

Queue work before a named resource is free

Create a durable FIFO queue once, then submit every command immediately:

awaitless queue create gpu0 --concurrency 1

awaitless submit --queue gpu0 -- python train_a.py
awaitless submit --queue gpu0 -- python train_b.py
awaitless submit -

... [View full README on GitHub](https://github.com/xpluspro/awaitless#readme)