Whoever asked first is not always who goes first
A shared runner pool serves whoever asked first, so an urgent one-line fix waits behind a queue of speculative work. awrun gives the runs YOU submit real dynamic priority: submit two, bump one, and the urgent one goes first — regardless of submit order.
awrun submit --kind agent --agent local-5090 \ --task "verify the deploy" --priority 5 awrun bump r-8k2n4p7q --priority 9 awrun queue # r-8k2n4p7q [ queued] p=9 agent 3s old verify the deploy
Priority, not arrival order
The real rule is sort by (-priority, created_at) — highest priority first, FIFO among ties. Submit a few items in any order, at any priority, and dispatch them one at a time.
queue is empty — submit one above
Runs client-side, in your browser — nothing here is submitted anywhere. The real CLI is awrun submit / awrun queue / awrun bump.
One store, sorted by priority
Modeled on the ADK's own decision-card store — the same durable, cross-process design already proven in this ecosystem, applied to a run queue instead of a human decision.
Priority, not arrival order
list() sorts by (-priority, created_at) — highest priority first, FIFO among equal priorities. Submit order stops mattering the moment priorities differ.
Change priority in flight
awrun bump <id> --priority N reprioritizes a queued or claimed item in place — a field rewrite, not a directory move, so a bump can never race a claim.
OS-level mutex, no lock file
Claiming an item is os.rename between status directories. Two workers racing for the same item: exactly one rename succeeds, the loser gets FileNotFoundError and moves to the next candidate — correct across processes and machines sharing the directory over a network mount, which a Python-level lock is not.
No daemon required
One JSON file per item under ~/.aither/awrun/<status>/, atomic os.replace writes. The dispatcher is a loop you run as a scheduled task or a one-shot --once invocation — not a new always-on service.
Dispatches ADK agents directly
Phase 1 claims the highest-priority kind=agent item and runs adk chat <agent> <task> — no GitHub Actions involved, so there is no opaque scheduler between a submit and a run.
Not a GitHub Actions scheduler
Reordering someone ELSE's push- or PR-triggered CI run is a platform boundary this does not cross. kind=ci items queue and bump today; the dispatcher for them is the next phase, and until it ships they are deliberately never claimed by the phase-1 agent loop.
Quick start
Install it, submit two runs at different priorities, and watch the order.
pip install awrun awrun submit --kind agent --agent local-5090 --priority 1 \ --task "regenerate the changelog" awrun submit --kind agent --agent local-5090 --priority 9 \ --task "verify the deploy" awrun queue
awrun self-test and the dispatcher's own --self-test pin the ordering guarantees above against a real temp-directory store, including a two-worker claim race and a nonzero exit recorded as failed rather than dropped.One estate, 8 doors
These projects are organs of the same system — the same identity plane, the same agent runtime, the same operational discipline. Follow any of them.
The ecosystem this belongs to
Every Aitherium repository publishes an aither-manifest.json beside its
page, and each surface reads all of them — so the network is browsable from any node in
it. A repository that publishes nothing shows as unknown, never as zero.