1.16.0 — 2026-10-21

Release Notes

The route map is laid out in reading order, so a workflow with shortcuts and loops reads along its
main path; and the documentation is reorganised around what a person looks for: a first factory
that runs on one CLI, pages for updating and troubleshooting, the design inside the book, and a site
that describes the release you can install.

Compatibility. Nothing a factory does changes. Its route map — on the dashboard and from
layover graph --svg — may look different: columns follow the order its routes are declared in
rather than hop distance, so listing routes roughly in the order work flows keeps the map readable.
layover validate and layover explain say exactly what they said. The first factory,
examples/planner.toml, now runs every agent on Copilot CLI instead of Claude Code, Copilot CLI
and Codex; a factory copied from it before is unaffected. Links to sections of configuration.html
about runners, routes and updating, and of dashboard.html about chains, runs and cost, now land at
the top of the page that held them: those sections have pages of their own. For code that uses
layover-core as a library, diagram::Edge gains a via field.

Changed

• The route map is laid out in reading order, not hop distance. Columns come from a depth-first
  walk from the way in, visiting routes in the order layover.toml declares them; a route that
  closes a loop is drawn back. A production workflow whose analyst may send straight to agents
  several phases on had five agents in one column; it now reads analyst, consults, reviewer,
  developer, tester, operator, messenger. An edge that skips columns crosses each one clear of its
  boxes, a route back runs just below the columns it spans rather than under the whole map, and
  each agent's tooltip gives its hop depth as layover validate measures it. A sweep that spawns
  its reviewer now draws the reviewer's consults after it rather than beside the sweep's entry.
• The documentation recommends a CLI home of the factory's own — COPILOT_HOME,
  CLAUDE_CONFIG_DIR, CODEX_HOME, forwarded with env_from — so a factory's sessions stay out of
  the user's history and its agents never load the user's personal plugins and MCP servers. The
  install guide says how a variable reaches a Tower autostart starts; risk 30 records the hazard.
• The first factory needs one CLI. examples/planner.toml asked for three CLIs and an
  ANTHROPIC_API_KEY, and its Codex reviewer could not reach Layover, so the loop broke at its
  third agent. Every agent now uses the copilot preset.
• The site's root is the latest release's book, rebuilt when a release is published; main's
  is at /dev/, with a banner on every page saying it may describe what no release does yet.
• New pages: Updating Layover, Troubleshooting (by the message you see), Glossary, Runners,
  Routes and joins, and the dashboard's Chains and Runs views, each split from a page that had grown
  past 500 lines. The design documents — architecture, routing, the decision log and the risks —
  are pages of the book, written from docs/ when it is built.
• The decision log is split by topic into docs/decisions/, and the risks of releasing and updating
  into docs/risks-releases.md. Cutting a release moved from the install guide to RELEASING.md.
• The README is shorter, and the book's Status is the one list of what is and is not built. The
  CHANGELOG's older sections are cut to bullets, their Compatibility paragraphs unchanged.
• cargo xtask verify checks #anchors as well as links, absolute links to the repository and the
  site, that every docs/ file is a page of the book, and that every CLI command and flag,
  layover.toml key and HTTP endpoint is in its reference page. cargo xtask book writes the
  design pages.

Install layover-cli 1.16.0

Install prebuilt binaries via shell script

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/KotkaZ/layover-project/releases/download/v1.16.0/layover-cli-installer.sh | sh

Install prebuilt binaries via powershell script

powershell -ExecutionPolicy Bypass -c "irm https://github.com/KotkaZ/layover-project/releases/download/v1.16.0/layover-cli-installer.ps1 | iex"

Install prebuilt binaries via Homebrew

brew install KotkaZ/tap/layover

Install prebuilt binaries into your npm project

npm install @layover/layover-cli@1.16.0

Download layover-cli 1.16.0

File	Platform	Checksum
layover-cli-aarch64-apple-darwin.tar.xz	Apple Silicon macOS	checksum
layover-cli-x86_64-apple-darwin.tar.xz	Intel macOS	checksum
layover-cli-x86_64-pc-windows-msvc.zip	x64 Windows	checksum
layover-cli-aarch64-unknown-linux-gnu.tar.xz	ARM64 Linux	checksum
layover-cli-x86_64-unknown-linux-gnu.tar.xz	x64 Linux	checksum

Verifying GitHub Artifact Attestations

The artifacts in this release have attestations generated with GitHub Artifact Attestations. These can be verified by using the GitHub CLI:

gh attestation verify <file-path of downloaded artifact> --repo KotkaZ/layover-project

You can also download the attestation from GitHub and verify against that directly:

gh attestation verify <file-path of downloaded artifact> --bundle <file-path of downloaded attestation>

1.15.0 — 2026-10-19

Release Notes

A Tower that is asked to stop now lets what it is running finish, and Layover can update itself: it
hears of a new release, gets it ready, verified and checked against the factory, and — asked —
installs it between runs and restarts on it, rolling back one that cannot prove itself.

Compatibility. Additive for layover.toml and the HTTP API: every factory that loaded under
1.14 loads unchanged, and the one new table, [update], is optional. What an existing factory will
notice:

• The first Ctrl+C on layover serve drains instead of exiting at once: nothing new starts, what
  is running finishes, and then it exits. A second Ctrl+C cuts what is running off and exits.
• The Tower makes one request a day to github.com, for the newest release's manifest, and says
  when a newer release exists. It downloads and changes nothing. [update] mode = "off" stops it
  for a factory and LAYOVER_UPDATE=off for a machine.
• layover doctor begins with a line saying which Layover runs and what this machine last
  learned about releases.
• One Tower serves a factory. A second serve on a factory another is serving refuses to start,
  where it used to race the first for its queue.
• The service files layover autostart writes for systemd and launchd set
  LAYOVER_SUPERVISOR, so a Tower installing a release exits 75 for the service to restart it.
  Regenerate an older one; a systemd service is recognised without it.
• validate warns when [update] max_drain is shorter than a run's timeout, which the
  defaults never are.
• The HTTP API: GET /health gains stopping, and /update is new, with apply, skip and
  rollback beneath it.

Added

• layover stop asks the Tower serving a factory to stop, from another terminal or a script: it
  drains and exits, and --now cuts what is running off. It writes .layover/stop-request.json,
  which the Tower honours and removes, and which a Tower starting later ignores.
• Cutting off kills the runs. A Tower cut off — a second Ctrl+C, or layover stop --now — kills
  each live run's process tree and leaves it for the next Tower to record as interrupted, rather
  than leaving it running with nobody listening. Every way of stopping exits 0, so a systemd or
  launchd service that restarts on failure leaves a stopped Tower stopped.
• Draining. While a Tower stops, nothing new starts — queued work stays queued for the next
  start, and schedule ticks are held — except work that completes a rendezvous already holding an
  arrival, which would otherwise be lost. The Tower exits once nothing is alive and nothing is
  parked, so stopping it no longer interrupts runs or loses arrivals.
• The dashboard says when a Tower is stopping: the version pill reads · stopping, also from a
  --watch-only dashboard in another process.
• Hearing about a newer Layover. [update] — mode (notify by default, or off), channel
  (stable, or prerelease for release candidates) and check_every ("24h"). The Tower looks on
  that schedule; the version pill reads v1.14.0 → 1.15.0 and opens the release's Compatibility
  note and notes; doctor says so. What was found is kept per machine, so factories sharing a
  binary ask once between them.
• layover update check looks now and prints what a newer release changes; layover update skip <version> stops offering one on this machine, and --clear undoes it.
• layover about says what a binary is — version, platform, state layout, HTTP API and the
  oldest release it can be updated from — and --json says it to a program.
• Staging a release, with [update] mode = "stage" or layover update stage: the newest
  release is downloaded (capped at 64 MB), its SHA-256 matched to the manifest and its .sha256
  file, its GitHub attestation verified with gh attestation verify pinned to this repository's
  release workflow and tag, its binary unpacked with nothing allowed outside the staging folder and
  asked what it is with layover about --json, and the factory validated by it. Nothing downloaded
  runs before it is verified; without gh, --trust-checksum-only runs it on a person's say-so.
  Nothing is installed.
• Installing a release: layover update apply, or Update now in the dashboard. The
  Tower drains — up to [update] max_drain ("4h"), then cuts off what is still running for
  recovery to restart on the new version, unless an agent with recovery = "manual" is running,
  which postpones it — swaps its binary, keeping the old one for [update] keep_previous ("7d"),
  and hands over: on Windows it starts the new version at its own address and waits for it to
  answer, putting its own binary back if it does not; under systemd or launchd it exits 75. The new
  Tower keeps the dashboard's token, proves itself healthy, and writes to .layover/serve.log.
  With no Tower serving, the binary is replaced at once. A Homebrew or npm install is left to its
  package manager, with the command to run. Exit codes say how it went.
• Installing unattended, with [update] mode = "auto": a patch or minor release (allow), a
  day or two after it was published (min_age = { patch = "24h", minor = "48h" }), staged,
  verified (require_provenance) and validating the factory with no new warning, is installed in
  the window ("Sat 02:00-06:00", local time) or once the factory has been idle for idle_for
  ("10m"). A major release and one that changes the state layout always wait for a person. An
  install whose window closes before runs finish is postponed to the next. The dashboard's bell
  rings for a new release, an update and a rollback.
• layover update rollback goes back to the version the last update replaced; status
  says where things stand; log prints .layover/updates.jsonl.
• GET /update: what this machine last learned about releases, for this factory, and — once a
  release is staged — how far staging got (staged), what it made of this factory (gate), the
  install under way (request), the last update (last_update) and the version kept to go back
  to (previous). POST /update/apply, DELETE /update/apply, POST /update/skip
  and POST /update/rollback do from the dashboard what the commands do.
• LAYOVER_UPDATE, LAYOVER_UPDATE_SOURCE (a mirror laid out as GitHub's releases) and
  LAYOVER_GITHUB_TOKEN (for the API, on the prerelease channel).
• cargo xtask verify refuses a CHANGELOG release section without a **Compatibility.**
  paragraph, which the updater shows before an install, and a dist upgrade until the pinned
  release manifest the updater is tested against is refreshed.

Tried

Released first as two candidates, 1.15.0-rc.1 and rc.2, on GitHub only. A throwaway 1.14.0 install
found rc.1, verified it with gh, waited for a live run, installed it in place and rolled it back.
A factory on rc.1 in mode = "auto" then found rc.2, staged and verified it, waited out its day,
and installed it by itself once idle, keeping its dashboard's token. What the candidates turned
up — an install marked done before the new Tower had answered, and layover update check not
mentioning apply — is fixed here.

Install layover-cli 1.15.0

Install prebuilt binaries via shell script

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/KotkaZ/layover-project/releases/download/v1.15.0/layover-cli-installer.sh | sh

Install prebuilt binaries via powershell script

powershell -ExecutionPolicy Bypass -c "irm https://github.com/KotkaZ/layover-project/releases/download/v1.15.0/layover-cli-installer.ps1 | iex"

Install prebuilt binaries via Homebrew

brew install KotkaZ/tap/layover

Install prebuilt binaries into your npm project

npm install @layover/layover-cli@1.15.0

Download layover-cli 1.15.0

File	Platform	Checksum
layover-cli-aarch64-apple-darwin.tar.xz	Apple Silicon macOS	checksum
layover-cli-x86_64-apple-darwin.tar.xz	Intel macOS	checksum
layover-cli-x86_64-pc-windows-msvc.zip	x64 Windows	checksum
layover-cli-aarch64-unknown-linux-gnu.tar.xz	ARM64 Linux	checksum
layover-cli-x86_64-unknown-linux-gnu.tar.xz	x64 Linux	checksum

Verifying GitHub Artifact Attestations

The artifacts in this release have attestations generated with GitHub Artifact Attestations. These can be verified by using the GitHub CLI:

gh attestation verify <file-path of downloaded artifact> --repo KotkaZ/layover-project

You can also download the attestation from [GitHub](https://github.com/KotkaZ/layover-project/...

1.15.0-rc.2 — 2026-10-16

Release Notes

A second release candidate, published as a GitHub pre-release like the first: what trying
1.15.0-rc.1 on a real install turned up.

Compatibility. Nothing changes for a factory from 1.15.0-rc.1.

Fixed

• An install is done when the new Tower answers as itself. The new Tower used to mark the
  install applied as it started, so layover update apply stopped following one line before the old
  Tower said it was done — and, under a service manager, before the new Tower had proved anything.
  Now the old Tower says so when the new one answers, or, under a service manager, the new Tower
  once it is healthy; one that rolls itself back marks the install failed.
• layover update check says how to install what it found: layover update apply, or for a
  Homebrew or npm install the command to run, rather than "the way you installed Layover".

Install layover-cli 1.15.0-rc.2

Install prebuilt binaries via shell script

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/KotkaZ/layover-project/releases/download/v1.15.0-rc.2/layover-cli-installer.sh | sh

Install prebuilt binaries via powershell script

powershell -ExecutionPolicy Bypass -c "irm https://github.com/KotkaZ/layover-project/releases/download/v1.15.0-rc.2/layover-cli-installer.ps1 | iex"

Install prebuilt binaries via Homebrew

brew install KotkaZ/tap/layover

Install prebuilt binaries into your npm project

npm install @layover/layover-cli@1.15.0-rc.2

Download layover-cli 1.15.0-rc.2

File	Platform	Checksum
layover-cli-aarch64-apple-darwin.tar.xz	Apple Silicon macOS	checksum
layover-cli-x86_64-apple-darwin.tar.xz	Intel macOS	checksum
layover-cli-x86_64-pc-windows-msvc.zip	x64 Windows	checksum
layover-cli-aarch64-unknown-linux-gnu.tar.xz	ARM64 Linux	checksum
layover-cli-x86_64-unknown-linux-gnu.tar.xz	x64 Linux	checksum

Verifying GitHub Artifact Attestations

The artifacts in this release have attestations generated with GitHub Artifact Attestations. These can be verified by using the GitHub CLI:

gh attestation verify <file-path of downloaded artifact> --repo KotkaZ/layover-project

You can also download the attestation from GitHub and verify against that directly:

gh attestation verify <file-path of downloaded artifact> --bundle <file-path of downloaded attestation>

1.15.0-rc.1 — 2026-10-16

Release Notes

A release candidate, for trying the updater against a real release before stable factories do. It
is published as a GitHub pre-release: only [update] channel = "prerelease" sees it, and it is not
on Homebrew, npm or crates.io.

A Tower that is asked to stop now lets what it is running finish, and Layover can update itself: it
hears of a new release, gets it ready, verified and checked against the factory, and — asked —
installs it between runs and restarts on it, rolling back one that cannot prove itself.

Compatibility. Additive for layover.toml and the HTTP API: every factory that loaded under
1.14 loads unchanged, and the one new table, [update], is optional. What an existing factory will
notice:

• The first Ctrl+C on layover serve drains instead of exiting at once: nothing new starts, what
  is running finishes, and then it exits. A second Ctrl+C cuts what is running off and exits.
• The Tower makes one request a day to github.com, for the newest release's manifest, and says
  when a newer release exists. It downloads and changes nothing. [update] mode = "off" stops it
  for a factory and LAYOVER_UPDATE=off for a machine.
• layover doctor begins with a line saying which Layover runs and what this machine last
  learned about releases.
• One Tower serves a factory. A second serve on a factory another is serving refuses to start,
  where it used to race the first for its queue.
• The service files layover autostart writes for systemd and launchd set
  LAYOVER_SUPERVISOR, so a Tower installing a release exits 75 for the service to restart it.
  Regenerate an older one; a systemd service is recognised without it.
• validate warns when [update] max_drain is shorter than a run's timeout, which the
  defaults never are.
• The HTTP API: GET /health gains stopping, and GET /update is new.

Added

• layover stop asks the Tower serving a factory to stop, from another terminal or a script: it
  drains and exits, and --now cuts what is running off. It writes .layover/stop-request.json,
  which the Tower honours and removes, and which a Tower starting later ignores.
• Cutting off kills the runs. A Tower cut off — a second Ctrl+C, or layover stop --now — kills
  each live run's process tree and leaves it for the next Tower to record as interrupted, rather
  than leaving it running with nobody listening. Every way of stopping exits 0, so a systemd or
  launchd service that restarts on failure leaves a stopped Tower stopped.
• Draining. While a Tower stops, nothing new starts — queued work stays queued for the next
  start, and schedule ticks are held — except work that completes a rendezvous already holding an
  arrival, which would otherwise be lost. The Tower exits once nothing is alive and nothing is
  parked, so stopping it no longer interrupts runs or loses arrivals.
• The dashboard says when a Tower is stopping: the version pill reads · stopping, also from a
  --watch-only dashboard in another process.
• Hearing about a newer Layover. [update] — mode (notify by default, or off), channel
  (stable, or prerelease for release candidates) and check_every ("24h"). The Tower looks on
  that schedule; the version pill reads v1.14.0 → 1.15.0 and opens the release's Compatibility
  note and notes; doctor says so. What was found is kept per machine, so factories sharing a
  binary ask once between them.
• layover update check looks now and prints what a newer release changes; layover update skip <version> stops offering one on this machine, and --clear undoes it.
• layover about says what a binary is — version, platform, state layout, HTTP API and the
  oldest release it can be updated from — and --json says it to a program.
• Staging a release, with [update] mode = "stage" or layover update stage: the newest
  release is downloaded (capped at 64 MB), its SHA-256 matched to the manifest and its .sha256
  file, its GitHub attestation verified with gh attestation verify pinned to this repository's
  release workflow and tag, its binary unpacked with nothing allowed outside the staging folder and
  asked what it is with layover about --json, and the factory validated by it. Nothing downloaded
  runs before it is verified; without gh, --trust-checksum-only runs it on a person's say-so.
  Nothing is installed.
• Installing a release: layover update apply, or Update now in the dashboard. The
  Tower drains — up to [update] max_drain ("4h"), then cuts off what is still running for
  recovery to restart on the new version, unless an agent with recovery = "manual" is running,
  which postpones it — swaps its binary, keeping the old one for [update] keep_previous ("7d"),
  and hands over: on Windows it starts the new version at its own address and waits for it to
  answer, putting its own binary back if it does not; under systemd or launchd it exits 75. The new
  Tower keeps the dashboard's token, proves itself healthy, and writes to .layover/serve.log.
  With no Tower serving, the binary is replaced at once. A Homebrew or npm install is left to its
  package manager, with the command to run. Exit codes say how it went.
• Installing unattended, with [update] mode = "auto": a patch or minor release (allow), a
  day or two after it was published (min_age = { patch = "24h", minor = "48h" }), staged,
  verified (require_provenance) and validating the factory with no new warning, is installed in
  the window ("Sat 02:00-06:00", local time) or once the factory has been idle for idle_for
  ("10m"). A major release and one that changes the state layout always wait for a person. An
  install whose window closes before runs finish is postponed to the next. The dashboard's bell
  rings for a new release, an update and a rollback.
• layover update rollback goes back to the version the last update replaced; status
  says where things stand; log prints .layover/updates.jsonl.
• GET /update: what this machine last learned about releases, for this factory, and — once a
  release is staged — how far staging got (staged), what it made of this factory (gate), the
  install under way (request), the last update (last_update) and the version kept to go back
  to (previous). POST /update/apply, DELETE /update/apply, POST /update/skip
  and POST /update/rollback do from the dashboard what the commands do.
• LAYOVER_UPDATE, LAYOVER_UPDATE_SOURCE (a mirror laid out as GitHub's releases) and
  LAYOVER_GITHUB_TOKEN (for the API, on the prerelease channel).
• cargo xtask verify refuses a CHANGELOG release section without a **Compatibility.**
  paragraph, which the updater shows before an install, and a dist upgrade until the pinned
  release manifest the updater is tested against is refreshed.

Install layover-cli 1.15.0-rc.1

Install prebuilt binaries via shell script

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/KotkaZ/layover-project/releases/download/v1.15.0-rc.1/layover-cli-installer.sh | sh

Install prebuilt binaries via powershell script

powershell -ExecutionPolicy Bypass -c "irm https://github.com/KotkaZ/layover-project/releases/download/v1.15.0-rc.1/layover-cli-installer.ps1 | iex"

Install prebuilt binaries via Homebrew

brew install KotkaZ/tap/layover

Install prebuilt binaries into your npm project

npm install @layover/layover-cli@1.15.0-rc.1

Download layover-cli 1.15.0-rc.1

File	Platform	Checksum
layover-cli-aarch64-apple-darwin.tar.xz	Apple Silicon macOS	checksum
layover-cli-x86_64-apple-darwin.tar.xz	Intel macOS	checksum
layover-cli-x86_64-pc-windows-msvc.zip	x64 Windows	checksum
layover-cli-aarch64-unknown-linux-gnu.tar.xz	ARM64 Linux	checksum
layover-cli-x86_64-unknown-linux-gnu.tar.xz	x64 Linux	checksum

Verifying GitHub Artifact Attestations

The artifacts in this release have attestations generated with GitHub Artifact Attestations. These can be verified by using the GitHub CLI:

gh attestation verify <file-path of downloaded artifact> --repo KotkaZ/layover-project

You can also download the attestation from GitHub and verify against that directly:

gh attestation verify <file-path of downloaded artifact> --bundle <file-path of downloaded attestation>

1.14.0 — 2026-10-14

Release Notes

A run the model service ended is restarted like an interrupted one, and a chain that ends on a
failed run no longer reads as finished.

Compatibility. Additive for layover.toml: every factory that loaded under 1.13 loads unchanged,
and the one new key, a runner's provider_errors, is optional. What an existing factory will notice:

• A Copilot run the model service ended is restarted, after a minute, where its agent's
  recovery is automatic — the default — up to max_recovery_attempts (default 2). It is on by
  default because recovery already says whether an agent's work is safe to repeat. To keep the old
  behaviour, set max_recovery_attempts = 0, recovery = "manual" on an agent, or
  provider_errors = { read = "none" } on a runner. No other failed run is restarted.
• Chains that ended on a failed, timed-out or interrupted run show as failed, in Chains'
  needs attention, the tab's count, the page title and notifications — including ones that ended
  that way before this release, within the window shown.
• layover run waits for a restart that is backing off rather than stopping with it queued.
• The HTTP API: ItineraryState gains failed and ItineraryList a failed count; a run gains
  cause and request_id; a queued flight gains attempt and not_before. A client that treats
  the chain state as a closed set should expect the new value.
• Run records in runs-*.jsonl gain cause and request_id, absent from older records.
• Going back to 1.13 or earlier: a restart this release queued, or one alive when the Tower
  stopped, is not understood by them and would be dropped. Let it start, or cancel it, first.

Added

• A run the model service ended is told apart from one that failed its own work. Copilot CLI's
  events are read: a failed run is a provider error when its last model call came back with a
  result other than success (http_400, transport_error, …) or a session.error of type
  query, and no tool started and no call succeeded after it. Only top-level event fields are read,
  so an agent quoting an error never counts. The run stays failed, with cause: provider_error,
  the provider's request id, and a detail saying what the service said.
• Such a run is restarted like an interrupted one: the agent's recovery policy and
  max_recovery_attempts, counted per piece of work, a Ground Stop forbidding it, and every rail
  applying to the restart. It waits a minute before the first restart, five before the second and
  fifteen after that, and is told the model service failed and that the earlier run's tools may have
  acted. Upcoming says when it starts.
• provider_errors on a runner: read = "copilot" for Copilot CLI under another name,
  read = "none" to turn it off, or the events that say the service failed (failed) and that the
  run carried on (carried_on), for a CLI Layover has no reader for. Claude Code and Codex have
  none yet. validate refuses a declaration that cannot decide or matches every event.
• The failed chain state, for a chain whose last run failed, timed out or was interrupted with
  nothing queued or running after it and nobody having continued it.

Install layover-cli 1.14.0

Install prebuilt binaries via shell script

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/KotkaZ/layover-project/releases/download/v1.14.0/layover-cli-installer.sh | sh

Install prebuilt binaries via powershell script

powershell -ExecutionPolicy Bypass -c "irm https://github.com/KotkaZ/layover-project/releases/download/v1.14.0/layover-cli-installer.ps1 | iex"

Install prebuilt binaries via Homebrew

brew install KotkaZ/tap/layover

Install prebuilt binaries into your npm project

npm install @layover/layover-cli@1.14.0

Download layover-cli 1.14.0

File	Platform	Checksum
layover-cli-aarch64-apple-darwin.tar.xz	Apple Silicon macOS	checksum
layover-cli-x86_64-apple-darwin.tar.xz	Intel macOS	checksum
layover-cli-x86_64-pc-windows-msvc.zip	x64 Windows	checksum
layover-cli-aarch64-unknown-linux-gnu.tar.xz	ARM64 Linux	checksum
layover-cli-x86_64-unknown-linux-gnu.tar.xz	x64 Linux	checksum

Verifying GitHub Artifact Attestations

The artifacts in this release have attestations generated with GitHub Artifact Attestations. These can be verified by using the GitHub CLI:

gh attestation verify <file-path of downloaded artifact> --repo KotkaZ/layover-project

You can also download the attestation from GitHub and verify against that directly:

gh attestation verify <file-path of downloaded artifact> --bundle <file-path of downloaded attestation>

1.13.0 — 2026-10-13

Release Notes

A dashboard for a factory that has been running for weeks: lists that open on what needs a person
and page through the rest, addresses for every view, pages that keep themselves current, a chain
drawn against the clock, spend day by day, and a tab title that says when something is waiting.

Compatibility. Additive. GET /costs gains by_day and day_zone; nothing is removed or
renamed. Links to #chain=<id> keep working.

Added

• Every view has an address, with its filters: #runs?status=failed&workflow=eagle-eye. A
  reload, a bookmark or a link opens the page as it was; changing tab is a step in the browser's
  history, changing a filter is not.
• Chains opens on what needs attention — working, waiting for you, stalled, halted — and can be
  searched, can hide a schedule's routine finished chains, and pages fifty at a time.
• Runs pages a hundred at a time, and says which chain each run belongs to and the model and
  effort it ran on. Learnings open on those in use, filtered by standing, agent and text.
• Trigger… beside each workflow on the route map. The header's opens on the workflow being
  shown, or the one last triggered from this browser; workflows started by hand come first, and the
  window says which agent the prompt goes to.
• The route map, Chains and Runs keep themselves current every fifteen seconds while showing,
  and say when they last read the Tower. A pinned agent on the map stays lit.
• Workflow cards fold: on a page of three or more workflows, one with nothing under way, failed
  or asking starts with its drawing folded, the busiest come first, and a choice is remembered.
• A chain against the clock: on a chain's page, a row per agent with each run a bar on one time
  axis, and its flags as chips marking those set otherwise than the default.
• Spend day by day on the Cost tab, with the most expensive chains and the Reserve's pace. GET /costs returns by_day, every day of the window including empty ones, and day_zone.
• The tab's title counts what needs you — (3) Layover — and a bell turns on browser
  notifications for a chain waiting for you, a stalled chain or a new help request.
• Sessions opens the newest running session when nothing is picked, and a terminal links to its
  chain and report.

Changed

• The Ground Stop stays on screen at any width: below 1180 px the tabs move to a row of their own.
• Diagrams are drawn at one scale, their natural size, so a small workflow is not blown up to
  look like a large one; a box's title too long for it is fitted rather than clipped.
• Times read the same way everywhere — 3 h ago, 2 d ago, the exact time on hover — and a
  running run says running · started 4 min ago rather than when it finished.
• Continue… is on a chain's own page rather than on every row of the Chains list, and is not
  offered for a workflow that only resumes layovers.
• The queue line on the route map is amber only when queued work has nothing to start it.

Install layover-cli 1.13.0

Install prebuilt binaries via shell script

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/KotkaZ/layover-project/releases/download/v1.13.0/layover-cli-installer.sh | sh

Install prebuilt binaries via powershell script

powershell -ExecutionPolicy Bypass -c "irm https://github.com/KotkaZ/layover-project/releases/download/v1.13.0/layover-cli-installer.ps1 | iex"

Install prebuilt binaries via Homebrew

brew install KotkaZ/tap/layover

Install prebuilt binaries into your npm project

npm install @layover/layover-cli@1.13.0

Download layover-cli 1.13.0

File	Platform	Checksum
layover-cli-aarch64-apple-darwin.tar.xz	Apple Silicon macOS	checksum
layover-cli-x86_64-apple-darwin.tar.xz	Intel macOS	checksum
layover-cli-x86_64-pc-windows-msvc.zip	x64 Windows	checksum
layover-cli-aarch64-unknown-linux-gnu.tar.xz	ARM64 Linux	checksum
layover-cli-x86_64-unknown-linux-gnu.tar.xz	x64 Linux	checksum

Verifying GitHub Artifact Attestations

The artifacts in this release have attestations generated with GitHub Artifact Attestations. These can be verified by using the GitHub CLI:

gh attestation verify <file-path of downloaded artifact> --repo KotkaZ/layover-project

You can also download the attestation from GitHub and verify against that directly:

gh attestation verify <file-path of downloaded artifact> --bundle <file-path of downloaded attestation>

1.12.0 — 2026-10-12

Release Notes

layover.toml says more with less: flags and a follow-up's routes are declared once, lengths of
time read as durations, a workflow sizes its own chains, and the numbers learnings live by are the
factory's — with lapsed learnings deleted rather than kept for ever.

Compatibility. Additive for the file format: every factory that loaded under 1.11 loads and
runs, and new keys are optional. What an existing factory will notice:

• Lapsed learnings are deleted after keep_lapsed_days, fourteen by default, counted from when
  each lapsed — or, for one that lapsed before this release, from when it was last proposed. The
  first layover serve deletes any already past that. Set [learnings] keep_lapsed_days higher
  first to keep more.
• An agent's fuel_usd is applied to chains starting at it, as documented; see Fixed.
• layover serve binds [layover] http_addr when --addr is not given. A factory that set it
  to something other than the default, believing it ignored, now listens there.
• validate --strict fails on [layover] state_dir, which is warned about now.
• The HTTP API: Pipeline.entry may be null, for a resuming pipeline that names none — only
  for factories that use that; Learning gains lapsed_at and deleted_after.

Added

• layover serve binds [layover] http_addr, which was accepted and ignored. --addr still
  wins, and without either it is 127.0.0.1:7878 as before. A factory started by autostart now
  serves where its layover.toml says.
• Lengths of time can be written as durations: [defaults] timeout = "2h",
  [reserve] window = "24h", [learnings] keep_lapsed = "14d" and a route's timeout = "30m",
  beside timeout_sec, window_hours, keep_lapsed_days and the route's timeout_sec, which keep
  working and also take a duration. Naming both is an error, and a duration that is not a whole
  number of hours or days, where the key counts in them, is refused rather than rounded.
• The numbers a learning lives by are the factory's, in a new [learnings] table:
  provisional_runs (20) runs it applies for, confirm_after (3) rediscoveries to make it
  permanent, max_chars (400) the longest an agent may propose, and max_per_run (25) the most one
  run is given. validate refuses 0 for any of them. A changed provisional_runs applies to
  learnings from then on.
• Lapsed learnings are deleted once [learnings] keep_lapsed_days have passed since they
  lapsed without an agent rediscovering them — fourteen by default, 0 to delete each as soon as it
  lapses. A rediscovery within the period still counts towards making a learning permanent; one
  after it starts a new learning. Deletion happens after every run and when layover serve starts.
  Each learning now records when it lapsed, and GET /learnings gives a lapsed one's lapsed_at and
  deleted_after, which the dashboard shows beside it. Rejected learnings are kept, as before.
• Flags can be declared once, for every workflow, in a top-level [flags] table. Every
  workflow accepts them as though it had declared them, and a workflow may still declare its own.
  The trigger window and layover explain offer each workflow only its own flags and the shared ones
  a prompt its agents read tests. validate warns about a workflow repeating a flag exactly as
  [flags] declares it. The workitem-factory and multi-workflow examples now declare theirs once.
• routes_from lets a workflow use another's scoped routes: [pipelines.follow-up] routes_from = "development" scopes every route scoped to development to the follow-up too, so
  those routes no longer each name both. It carries through chains of them; naming itself or an
  unknown pipeline is an error. The multi-workflow example's follow-up uses it.
• A workflow can set its own rails: max_hops, fuel_usd, max_runs and timeout on
  [pipelines.<name>], for every chain it opens, spawns or resumes, instead of [defaults]. A chain
  keeps the rails it started with. validate measures each workflow's reach, schedule and Reserve
  fit against its own rails, and refuses one of zero. The Reserve stays factory-wide.
• A pipeline that resumes may leave out entry. Its work goes back to whoever set it down,
  so the entry was required and unused. Without one it cannot be triggered by hand, and its map
  draws no arrow from it. GET /pipelines gives such a pipeline entry: null.

Changed

• [layover] state_dir is warned about by validate. It has never been honoured — everything
  Layover keeps is in .layover/ beside the factory definition — and a key that is silently ignored
  reads as though it works. A factory that sets it still loads; validate --strict now fails on it.

Fixed

• An agent's fuel_usd now applies to a chain that starts at it, as it was documented to. It
  was validated and shown as a workflow's Fuel on the dashboard, and every chain ran on
  [defaults] fuel_usd regardless. A factory that sets one now runs those chains on it — a tighter
  or looser budget than before, as the agent's value says.

Install layover-cli 1.12.0

Install prebuilt binaries via shell script

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/KotkaZ/layover-project/releases/download/v1.12.0/layover-cli-installer.sh | sh

Install prebuilt binaries via powershell script

powershell -ExecutionPolicy Bypass -c "irm https://github.com/KotkaZ/layover-project/releases/download/v1.12.0/layover-cli-installer.ps1 | iex"

Install prebuilt binaries via Homebrew

brew install KotkaZ/tap/layover

Install prebuilt binaries into your npm project

npm install @layover/layover-cli@1.12.0

Download layover-cli 1.12.0

File	Platform	Checksum
layover-cli-aarch64-apple-darwin.tar.xz	Apple Silicon macOS	checksum
layover-cli-x86_64-apple-darwin.tar.xz	Intel macOS	checksum
layover-cli-x86_64-pc-windows-msvc.zip	x64 Windows	checksum
layover-cli-aarch64-unknown-linux-gnu.tar.xz	ARM64 Linux	checksum
layover-cli-x86_64-unknown-linux-gnu.tar.xz	x64 Linux	checksum

Verifying GitHub Artifact Attestations

The artifacts in this release have attestations generated with GitHub Artifact Attestations. These can be verified by using the GitHub CLI:

gh attestation verify <file-path of downloaded artifact> --repo KotkaZ/layover-project

You can also download the attestation from GitHub and verify against that directly:

gh attestation verify <file-path of downloaded artifact> --bundle <file-path of downloaded attestation>

1.11.0 — 2026-10-12

Release Notes

Any workflow can be switched off — its schedule included — while the rest of the factory runs.

Compatibility. Additive. Factories load, validate and run unchanged, and nothing is switched off
until somebody switches it off. GET /pipelines gains switched_off and switched_off_since,
GET /flights gains held, and GET /upcoming gains switched_off. An older release ignores
.layover/journal/switched-off.jsonl, so under it every workflow runs as though switched on.

Added

• Every workflow can be switched off, scheduled or manual, from a switch beside its name on the
  dashboard's route map or with POST /pipelines/{name}/switch-off (and DELETE to switch it back
  on). Off, its schedule's ticks pass without firing or counting as skipped, a trigger is refused
  with a 409, a resuming workflow collects nothing, and a trigger already queued is held — marked
  held in GET /flights and halted on its chain. Chains of it already under way finish. Back on,
  held triggers start and the schedule fires at its next tick, without making up the ones it missed.
  The switch survives restarts in .layover/journal/switched-off.jsonl, which can be edited by hand.
  GET /pipelines and GET /upcoming say which workflows are off, and layover doctor names them
  and no longer warns that a switched-off schedule never fired.

Install layover-cli 1.11.0

Install prebuilt binaries via shell script

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/KotkaZ/layover-project/releases/download/v1.11.0/layover-cli-installer.sh | sh

Install prebuilt binaries via powershell script

powershell -ExecutionPolicy Bypass -c "irm https://github.com/KotkaZ/layover-project/releases/download/v1.11.0/layover-cli-installer.ps1 | iex"

Install prebuilt binaries via Homebrew

brew install KotkaZ/tap/layover

Install prebuilt binaries into your npm project

npm install @layover/layover-cli@1.11.0

Download layover-cli 1.11.0

File	Platform	Checksum
layover-cli-aarch64-apple-darwin.tar.xz	Apple Silicon macOS	checksum
layover-cli-x86_64-apple-darwin.tar.xz	Intel macOS	checksum
layover-cli-x86_64-pc-windows-msvc.zip	x64 Windows	checksum
layover-cli-aarch64-unknown-linux-gnu.tar.xz	ARM64 Linux	checksum
layover-cli-x86_64-unknown-linux-gnu.tar.xz	x64 Linux	checksum

Verifying GitHub Artifact Attestations

The artifacts in this release have attestations generated with GitHub Artifact Attestations. These can be verified by using the GitHub CLI:

gh attestation verify <file-path of downloaded artifact> --repo KotkaZ/layover-project

You can also download the attestation from GitHub and verify against that directly:

gh attestation verify <file-path of downloaded artifact> --bundle <file-path of downloaded attestation>

1.10.0 — 2026-10-08

Release Notes

A runner says only what its agents are denied: for Copilot CLI and Claude Code, Layover supplies
the rest. A workflow can run a shared agent at its own model, effort or context, and whoever
triggers a run can name it and choose those for that run alone.

Compatibility. Additive. Existing factories — written-out command runners included — load,
validate and run unchanged, and validate warns about nothing new in them. What is different:

• A written-out command containing the literal text {name} or {args} now has it filled in —
  the chain's name, the agent's args — or left out when there is none.
• POST /flights takes optional name and agents; GET /pipelines gains each workflow's
  agents, itineraries and pending flights a name, and runs a chain_name. Run records, queued
  flights, layovers and help requests keep the chain's name and choices where it has them; older
  releases ignore them, and older records simply lack them.

Added

• Runner presets. cli = "copilot" or cli = "claude" has Layover supply everything an
  unattended run of that CLI needs — the program, the agent's model, effort and context, Copilot's
  --no-ask-user and --name, the JSON output a cost is read from, and the MCP wiring — and, for
  Copilot, --allow-all-tools --allow-all-paths --allow-all-urls, since nobody is there to answer a
  permission prompt. A runner's args then say only what it takes away. command still works, for
  Codex, a script, or a runner that wants none of a preset's defaults.
• An agent's own args, added to its runner's command for that agent alone, so an agent that
  is denied one more thing than the rest needs no runner of its own. They go where a command has
  {args}, or at the end.
• A workflow can run an agent differently. [pipelines.<name>.agents.<agent>] sets the model,
  effort or context that workflow's chains run the agent at, and args it adds, so an agent shared
  by two workflows needs neither a second agent nor a second runner. It wins over the agent's own
  values and [defaults]; a choice made when triggering wins over it. Each workflow's map, explain and
  prompt --pipeline show the agent as that workflow runs it, and run records name what it ran on.
• A run can be named when it is triggered, and agents run differently for that run only. The
  dashboard's trigger window takes a name — "Login page: retry banner" — and, per agent the workflow
  runs, a model, effort or context to use instead; POST /flights takes them as name and
  agents. Both stay with everything the chain causes: hand-offs, spawned chains, follow-ups, and
  the work a reply to its help requests continues. The name is shown on Chains, the chain's page,
  Sessions, Upcoming and Runs, kept in run records as chain_name, and passed to Copilot as the
  session's --name. A choice its runner cannot carry, for an agent the workflow never runs, or
  that is not a plain value is refused with the reason. GET /pipelines lists each workflow's
  agents with what they run at in it, and a chain's own map shows what its agents ran at in it.
• layover validate refuses a runner with neither cli nor command, both, or args beside a
  command; and warns when a runner or agent repeats an option its preset already supplies, when
  an agent's args fix a value its runner carries a placeholder for, and when args would follow a
  command's final -; refuses a workflow override for an undeclared agent and warns about one no
  chain of the workflow can reach or whose value the runner cannot carry. An agent that leaves a
  preset's effort or context unset is not warned about: the CLI's own default is what it asked for.
• examples/multi-workflow/: four workflows sharing eight agents and one Copilot runner, shaped
  after a team's factory — a manually triggered development workflow, a follow-up that resumes its
  published pull requests, a review sweep that spawns one review per pull request and runs the shared
  reviewer at a lower effort with one more deny rule, and a daily upstream watch.

Changed

• The examples use presets. news-digest, pr-review, build-and-review and
  workitem-factory run Copilot and Claude Code through cli, so their Copilot agents now also get
  --allow-all-paths --allow-all-urls --no-ask-user. planner.toml keeps written-out command
  runners for Copilot and Codex, to show that shape. The examples' Claude runners previously lacked
  the --verbose Claude Code requires beside stream-json in print mode.

Install layover-cli 1.10.0

Install prebuilt binaries via shell script

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/KotkaZ/layover-project/releases/download/v1.10.0/layover-cli-installer.sh | sh

Install prebuilt binaries via powershell script

powershell -ExecutionPolicy Bypass -c "irm https://github.com/KotkaZ/layover-project/releases/download/v1.10.0/layover-cli-installer.ps1 | iex"

Install prebuilt binaries via Homebrew

brew install KotkaZ/tap/layover

Install prebuilt binaries into your npm project

npm install @layover/layover-cli@1.10.0

Download layover-cli 1.10.0

File	Platform	Checksum
layover-cli-aarch64-apple-darwin.tar.xz	Apple Silicon macOS	checksum
layover-cli-x86_64-apple-darwin.tar.xz	Intel macOS	checksum
layover-cli-x86_64-pc-windows-msvc.zip	x64 Windows	checksum
layover-cli-aarch64-unknown-linux-gnu.tar.xz	ARM64 Linux	checksum
layover-cli-x86_64-unknown-linux-gnu.tar.xz	x64 Linux	checksum

Verifying GitHub Artifact Attestations

The artifacts in this release have attestations generated with GitHub Artifact Attestations. These can be verified by using the GitHub CLI:

gh attestation verify <file-path of downloaded artifact> --repo KotkaZ/layover-project

You can also download the attestation from GitHub and verify against that directly:

gh attestation verify <file-path of downloaded artifact> --bundle <file-path of downloaded attestation>

1.9.0 — 2026-10-07

Release Notes

An agent declares its own reasoning effort and context tier beside its model, so one runner serves
every agent with the same permissions; and every run records which effort and context it ran at.

Compatibility. Additive. Existing factories — including ones whose runners fix an effort or a
context in their command — load, validate and run unchanged; validate warns about nothing new
unless a runner both fixes a value and has the placeholder for it. Two things are different in an
existing factory:

• A runner whose {model} an agent leaves unset no longer hands the CLI a flag without its value,
  or the literal {model}; the argument is left out, with its option. Such runs failed at spawn.
• Run records gain effort and context, and GET /runs gains reasoning_effort and context;
  older releases and records simply lack them.

Added

• An agent declares its own effort and context, beside its model, and a runner carries
  them with {effort} and {context} placeholders exactly as {model} carries a model —
  "--reasoning-effort={effort}", "--context={context}", or Codex's
  "-c", "model_reasoning_effort={effort}". A runner now describes a CLI and a permission set, and
  is shared by every agent with those permissions whatever its model, effort and context: tuning one
  agent no longer means a new runner and a copied deny list. [defaults] effort and
  [defaults] context fill in for agents that set none; an agent's own value wins. Values are
  passed through as written — Layover keeps no catalog of the levels a model accepts.
• layover validate warns when an agent's effort or context has no placeholder to reach its
  runner, when a runner with a placeholder serves an agent that sets no value and has no default,
  when a runner fixes a value beside its own placeholder (the CLI would get two), when a
  [defaults] value reaches no runner, and when a value is empty.
• Every run records the model, effort and context it ran with, in runs-*.jsonl as effort
  and context, and in GET /runs as reasoning_effort and context; a session's header shows
  them. History says which effort a run used without its transcript. Older records lack the fields.
• layover explain says what each agent runs on, and layover prompt prints it on stderr
  beside the prompt, both read from the command line with the agent's own values filled in.

Fixed

• An unset {model} no longer hands the CLI a flag without its value. "--model", "{model}"
  with no model left --model in front of the next flag, which Copilot CLI refuses outright, and a
  joined --model={model} reached the CLI as that literal text. An argument carrying an unset
  placeholder is now left out whole, together with the option it is the value of. The reference
  factory's Copilot and Codex agents, which declare no model, were affected.

Changed

• For anyone using the crates as a library: Runner::invocation and invocation_with_mcp take a
  Selection instead of a model, spawn::Plan carries a selection, and cost::of_run returns a
  ModelChoice. Runner and McpWiring moved to config/runner.rs and are still reached as
  layover_core::config::Runner.

A rate card is still keyed by model alone. A provider that bills a long-context tier at a higher
rate above a token threshold is not modelled, so a card for such a model is a lower bound on its
long-context runs; Copilot runs are priced from the credits they report and are unaffected.

Install layover-cli 1.9.0

Install prebuilt binaries via shell script

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/KotkaZ/layover-project/releases/download/v1.9.0/layover-cli-installer.sh | sh

Install prebuilt binaries via powershell script

powershell -ExecutionPolicy Bypass -c "irm https://github.com/KotkaZ/layover-project/releases/download/v1.9.0/layover-cli-installer.ps1 | iex"

Install prebuilt binaries via Homebrew

brew install KotkaZ/tap/layover

Install prebuilt binaries into your npm project

npm install @layover/layover-cli@1.9.0

Download layover-cli 1.9.0

File	Platform	Checksum
layover-cli-aarch64-apple-darwin.tar.xz	Apple Silicon macOS	checksum
layover-cli-x86_64-apple-darwin.tar.xz	Intel macOS	checksum
layover-cli-x86_64-pc-windows-msvc.zip	x64 Windows	checksum
layover-cli-aarch64-unknown-linux-gnu.tar.xz	ARM64 Linux	checksum
layover-cli-x86_64-unknown-linux-gnu.tar.xz	x64 Linux	checksum

Verifying GitHub Artifact Attestations

The artifacts in this release have attestations generated with GitHub Artifact Attestations. These can be verified by using the GitHub CLI:

gh attestation verify <file-path of downloaded artifact> --repo KotkaZ/layover-project

You can also download the attestation from GitHub and verify against that directly:

gh attestation verify <file-path of downloaded artifact> --bundle <file-path of downloaded attestation>