Skip to content

1.12.0 — 2026-10-12

Choose a tag to compare

View all tags
@github-actions github-actions released this 12 Oct 12:03
v1.12.0
365c382

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>
Assets 28
Loading