Skip to main content

leasehold

ci Python 3.12+ Linux Apache-2.0

Run several coding agents on one Linux machine without it grinding to a halt.

Four agents each decide to run cargo test or pytest -n auto at the same moment. Each one sizes itself for the whole machine, so together they ask for four machines' worth of CPU and memory: memory fills and the machine swaps, your editor and git status stutter, and sometimes the OOM killer takes one of the jobs.

leasehold sits between the agents and the machine. A heavy command takes a lease on a share of the machine before it starts: it waits its turn when the machine is full, runs sized to the share it was given (CARGO_BUILD_JOBS, PYTEST_XDIST_AUTO_NUM_WORKERS, a make jobserver), and, where systemd allows it, runs in a cgroup weighted to that share. When the agent's session ends, whatever it left running is stopped.

leasehold top on a busy machine

What it changes, measured

Eight simulated agents start test runs and memory-hungry builds at random on an 8-CPU, 16 GiB machine (method and full tables):

jobs killed (OOM) git status p95 10 ms sleep, p99 late swap read back same work took
unmanaged 0 of 52 981 ms 25 ms 2.8 GiB 566 s
nice -n 19, a low-weight slice, or a fixed -j4 5 to 9 of 52 970 to 1130 ms 19 to 27 ms 4.9 to 9.8 GiB 579 to 630 s
leasehold 0 of 52 103 ms 3.3 ms 0.2 GiB 848 s

The machine stays usable and nothing is lost, at a price: the same work took up to 1.5 times as long, because heavy jobs wait their turn instead of overlapping. One machine and one run per condition so far; the memory results vary from run to run.

Since 0.4, a config setup writes for a machine of 4 to 7 slots runs two heavy jobs at once (weight 3 each on 6 slots) instead of one at weight 4. In a pre-registered gate of 8 rounds on the same machine, that cut the time to finish the same work by 14% and each job's mean time by 20%, with git status and wakeup latency within the gate's margins (the verdict).

Start

uv tool install leasehold
leasehold setup                 # a config sized for this machine, your own daemon, the PATH shims
leasehold run -- claude         # or codex, gemini, aider, any agent
leasehold top                   # who holds the machine, who waits and why

setup says what it did at each step, is safe to repeat, and leasehold setup --remove undoes it. It needs no root. Try it without installing anything first: uvx leasehold demo runs a made-up busy machine in top.

Inside leasehold run, the agent's heavy commands (pytest, cargo, make, npm test, go test and the like; leasehold commands lists the rules) go through small PATH shims that take a lease first. Light commands run as they are. A heavy command waits in line, keeping its place, for up to five minutes; one still waiting then is refused with the reason, which the agent reads:

leasehold: machine busy for 300s: cargo test (session claude_3f9a1c) holds 8 slots, 2 other
leases hold 4; pool work holds 12 of 12; this needs 4; gave up its place in line (#1). The
command did not run. Do lighter work first, then run it again.

In Claude Code, the plugin does the same through a hook, without the shims:

/plugin marketplace add chalkworth/leasehold
/plugin install leasehold@leasehold

What it promises

leasehold decides when a command starts and how much of the machine it may use while it runs. It never decides what runs, and it only touches the processes it started itself.

  • A heavy command takes a lease on slots (one slot per CPU, a few kept back for you) before it starts and gives it back when it ends. A holder that crashes gives it back within seconds. Commands that run the job count they are given stay off the kept CPUs; one that ignores it can still fill every CPU unless [contain] hard_cpu = true caps it (leasehold doctor warns while it is off). Turns go round fairly by user, then by agent session, so one busy agent cannot starve the others.
  • The lease's size reaches the command as the job-count variables that cargo, make, ninja, CMake, pytest-xdist, Go and others read, and optionally as a GNU make jobserver shared by the whole build tree.
  • Where there is a systemd user manager (most desktop and server distributions), each command runs in a user scope with CPUWeight in proportion to its lease and, when a rule says so, a MemoryHigh. leasehold doctor says whether this machine is enforced (systemd) or advisory, and why. Advisory means the lease and sizing still apply, but a command that ignores its job count is not held back.
  • A command can declare the memory it will use (hold --memory, or its rule's memory), and declared sizes are counted against a budget: the machine's memory less a share kept for you. A command that declares nothing counts a share in proportion to its weight, which never holds back more than the slots already do, so the budget only binds declared and standing memory. When memory pressure rises, nothing new starts until it eases, and then only within the memory measured free. Other programs' memory is not counted: the guard reacts to it once it shows as pressure (measured).
  • leasehold run puts the agent's session in a slice of its own and stops what it leaves behind (a stray test server, a hung build) when the agent exits.

How it compares

The first question is why not a systemd slice, or nice; the first row answers it.

Tool What it does Next to leasehold
nice, a systemd slice with a low CPUWeight Shares the CPU among what is already running Nothing waits: four builds sized for the whole machine still all start, compete for memory, and each runs at a quarter speed. leasehold uses the same cgroup weights, and adds the waiting and the sizing
flock, sem (util-linux, GNU parallel) A lock, or a counting semaphore of N slots, around a command No weights, sessions or load, and nothing to tell the command its size. Enough for one kind of job
pueue, task-spooler, nq A queue that runs your commands later, N at a time They own and run the job; leasehold only admits it, so the command keeps running in the agent's own shell with its output and exit code
agent-semaphore Coordinates parallel coding agents on one repository: claims on code scopes, conflict warnings, a landing queue About who edits and merges what, not the machine. The two fit together
steve, guildmaster One GNU make jobserver shared by every build on the machine Reaches only tools that speak the jobserver protocol. leasehold can size a jobserver from a lease
Slurm, HTCondor, Nomad Cluster schedulers Built for many machines; out of proportion for one

Also works for

The same daemon serves a machine several people or CI runners share: one system daemon under systemd, --kind external leases for self-hosted runner jobs, fair turns across Unix users, spare capacity lent out and revoked when work arrives, and a webhook, Prometheus metrics and a browser view. docs/reference.md has the system setup, every config key, the command line, the HTTP API and the exit codes; examples/ has a runnable example of each.

A Python tool can take leases itself, without running hold:

import leasehold

with leasehold.lease(4, kind="external", timeout=600) as lease:
    lease.run(["make"], jobserver=True)  # make's jobs follow the slots granted

The reference's From Python section covers the errors, cancelling a wait, running commands under a lease, and a fake daemon for tests.

What it is not

  • It is not a scheduler: it never runs, places or retries your jobs.
  • It is not a sandbox. Containment shares CPU by weight and throttles memory softly; it does not stop a command from using an idle machine, and it cannot prevent every out-of-memory kill. Without a systemd user manager, it is advisory only.
  • It runs on one machine, Linux only. It reads /proc/pressure and uses cgroup v2.

Stability

leasehold is alpha and before 1.0. The command line, exit codes, config file, HTTP API with its status schema, the names leasehold exports (leasehold.__all__: lease(), Lease, Command and their errors), and the library modules model, admission, ledger, quota and client are its interface; a minor release may change them, and CHANGELOG.md says how. The ledger file is not an interface.

Licence

Apache-2.0. See LICENSE. SECURITY.md says what leasehold trusts and how to report a problem; CONTRIBUTING.md how to work on it.

Metadata

Release files for leasehold 0.4.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for leasehold 0.4.0
File Size Uploaded Provenance
leasehold-0.4.0.tar.gz 3.2 MB With provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for leasehold 0.4.0
File Interpreter ABI Platform
leasehold-0.4.0-py3-none-any.whl Python 3 none any Details

Total release size: 3.5 MB

Release files / leasehold-0.4.0.tar.gz

Download URL leasehold-0.4.0.tar.gz
Size 3.2 MB
Tags Source
SHA-256 checksum
How to use checksums
be191709138d978af99676992e7069345c83352157e6f3374e540b8c50e609f1
BLAKE2b-256 checksum
How to use checksums
31aadc80402ba01a0a449a0fc0f3a977ce00e73567d705123340e1e77b828ace
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.16

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 22, 2026.

Transparency log

Release files / leasehold-0.4.0-py3-none-any.whl

Download URL leasehold-0.4.0-py3-none-any.whl
Size 283.7 kB
Tags Python 3
SHA-256 checksum
How to use checksums
5226621d106d3476bda4abc86a5031bb3453c98bc8e7c1d094742ff0a1e2561b
BLAKE2b-256 checksum
How to use checksums
b3af53539696342d3db76550ec3177ac5d551aab758592a06deac38692210d12
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.16

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 22, 2026.

Transparency log

Security for leasehold 0.4.0

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for leasehold-0.4.0.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 22, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page