Changelog

What has changed in Cadence, in the terms of an operator running it. Newest first. This site describes only what has shipped, so everything below works now.

October 2026

• Revoking a credential that Heroku webhooks depend on now asks first. Over MCP, credentials_revoke revokes nothing and returns confirmation_required with the dependent webhooks, unless you pass confirm: true. In the browser, a Revoke <NAME>? dialog lists them, and Revoke anyway goes ahead. What to do: an MCP client or script that calls credentials_revoke must now check the response for confirmation_required and call again with confirm: true; otherwise the credential stays live. See Credentials.

• Re-run a refused inbound delivery. Once you have fixed the cause of a delivery the source's adapter refused — for example by creating a missing Heroku credential — re-run it with MCP inbound_deliveries_rerun, or with Re-run on the new Failed deliveries card in space settings → Integrations. Both need admin. A delivery received before this release has no webhook recorded, so a re-run of a Heroku release looks up HEROKU_TOKEN_<APP> whatever its webhook is bound to. See Inbound.

• A refused delivery now publishes an event your rules can match. When a source's adapter refuses a delivery, Cadence publishes <source>.delivery_refused, such as heroku.delivery_refused, so a rule can file a task or tell you about it. It is not published when a rule's action fails. A refused Heroku release still publishes no heroku.deployed or heroku.config_changed, and the delivery stays failed. See Inbound.

• Edit an inbound webhook, and bind a Heroku webhook to one credential. inbound_webhooks_update and the new Edit dialog change a webhook's label and its Heroku credential without changing its URL. A Heroku webhook bound to a credential name uses it for every release, whatever app the release names, instead of HEROKU_TOKEN_<APP>. Unbound webhooks behave as before. See Inbound.

• Post a comment over the HTTP API. POST /api/v1/tasks/:key/activities appends a comment to a task. It needs a user API token and an Idempotency-Key header. See Tasks.

• A worker is now warned before its lease reaches the pool's max lifetime. In the last 120 seconds before the cap, the worker's heartbeat answers the new control word expire, so the worker can save its work before Cadence kills the lease and holds the task. A worker that does not handle expire behaves as before: Cadence kills its lease after the cap. See Fleet and Command-line client.

• Boards are now called workflows, and the old names no longer work. The ordered set of stages a task moves through is now a workflow everywhere in Cadence. "Board" now means only the board view, the kanban that draws a workflow as columns. No old name was kept as an alias, so a call, script or bookmark that uses one no longer works. What changed:

  • The MCP tools boards_list, boards_get, boards_create, boards_update and boards_delete are now workflows_list, workflows_get, workflows_create, workflows_update and workflows_delete, with the same behaviour and fields. See Workflows and stages.

  • Tool parameters board_slug, board and board_id are now workflow_slug, workflow and workflow_id, and the export's board_slugs is now workflow_slugs. Responses carry workflow and workflow_id in place of board and board_id, including the lease scope whoami returns, now scope.workflow. See Tasks, Stage rules, Leases and Authentication.

  • Over the API, creating a task takes workflow in place of board, and the refusals read unknown workflow, workflow is archived and workflow has no stages. PATCH /api/v1/spaces/:space_key/boards/:slug is now PATCH /api/v1/spaces/:space_key/workflows/:slug.

  • Stored values were renamed, and the ones you already have were migrated for you: the pool lease scope workflow (Fleet), the lease and scheduled-rule subject_kind workflow (Scheduled rules), the notification rule filter key workflow and the template variables task.workflow and task.workflow_name (Messaging and contacts), and the inbound upsert-task parameter workflow (Inbound). The values of these you already have keep working and need no change. Anything you create or update from now on must use the new names. For example, a script that calls inbound_rules_create must send workflow, and a template that uses task.board is refused when you save it.

  • A space export is now schema_version "2.0", with a top-level workflows list, and every rule scope names its workflow. See Export a space.

  • A transferred entry in a task's activity now carries from_workflow, from_workflow_id, to_workflow and to_workflow_id. Entries recorded earlier keep their from_board-style names, so a script that reads them must accept both. See Tasks § Move a task to another workflow.

  • Audit events about a workflow now read subject_type Workflow and kinds workflow.created, workflow.updated and workflow.deleted. Earlier events were rewritten to match. A workflow's events are listed only while the workflow exists, so once you delete a workflow none of its events, including workflow.deleted, can be listed. See Audit events.

  • Workflow pages moved to /spaces/:space_key/teams/:team_slug/workflows/:slug. Addresses containing /boards/ no longer open anything, including the two older shapes that used to redirect. Each workflow now has a permalink, /spaces/:space_key/workflows/:id-:slug, where :id is the workflow's numeric id. It keeps working after the workflow is renamed or moved to another team. It is also the url of a workflow or stage entity reference, so you can copy it from the ref that workflows_get returns. See Workflows and stages § Workflow URLs.

  • Links of the form /spaces/<space>/boards/<slug> already written in task bodies, comments and docs were rewritten to the workflow's permalink. This covers both relative links and links that start with http:// or https://. Any further path after the workflow, such as a stage or settings page, was dropped, so the link now opens the workflow itself. A query string or # anchor after it was kept. Three kinds of link were left as written and no longer open:

    • team-scoped links, /spaces/<space>/teams/<team>/boards/<slug>
    • links that name a host without http:// or https://
    • links that could not be matched to a workflow

    Replace those by hand.

  • A stage's form now groups Display order, Direction, Recency window and Card limit under a Board view section. Its settings panel has a Board view section too, showing the direction in brackets after Display order, and Recency window only when one is set. They work as before.

  What to do:

  • Check the instructions your agents run on. A worker that calls an old tool gets an error back, and a worker that passes an old parameter name may get no error at all (see What an old call gets back below). Cadence does not stop the worker for either. What happens next depends on what the worker reports. A worker that reports failure fails its lease. A worker that reports success after doing the wrong thing completes its lease with no hold on the task, and if the workflow has auto-advance turned on, a sentinel rule whose conditions are met can then move the task on with nobody watching. See What moves a task without a person. Look for boards_ tools and board, board_slug or board_id in your agent skill versions and in your worker versions' system_prompt and initial_prompt. A published version cannot be edited. Fork it (agent_skill_versions_fork or worker_versions_fork), change the draft (agent_skill_versions_update_draft or worker_versions_update_draft), and publish it — see Fleet § Agent skills and Fleet § Worker versions, including what publishing refuses. A worker version pins skill versions by id, so after a new skill version, fork the worker version and update its skill_version_ids too. Then repin each pool to the new worker version with pools_repin (see Fleet § Pools). Cadence does not repin a pool for you. A repin changes only the pool, not a lease already created: each lease keeps the worker version its pool had when the lease was created. So a lease of the pool that has not finished when you repin runs the old version, including one still pending, waiting for room or for a paused pool, or deferred by its worker, which goes back to pending on the same lease. After the repin, call GET /api/v1/leases?space=<key> with each of pending, dispatching, dispatched, running and paused as state, and look for leases of the pool whose worker_version id is an old version. Cancel each with leases_cancel (see Leases § Cancel a lease). Cadence does not start a cancelled lease again, so start that work again yourself as described for lost leases below.
  • Then check every lease that ran on an old version since this release. A person has to do this; Cadence does not find them for you. Use the HTTP API, with your own API token (a worker's lease token is refused): call GET /api/v1/leases?space=<key>&state=<state> once for each of completed, failed, killed, lost and cancelled. A lease can be cancelled after its worker has started work, so a cancelled one needs checking too. Each lease in that list carries its worker_version, with its id, and its timing, including created_at. Leases come back newest first, up to 100 per page (limit). Pass next_cursor back as cursor until you reach leases created before this release reached your instance. If you do not know that day, stop at leases created before 10 October 2026: no instance ran this release before then. Going back further is harmless: it only adds leases to check. A lease whose worker_version id is one of the versions you replaced in the previous step ran on an old version. task names the task it worked on, and is null for a workflow- or space-subject lease, which has no task to hold. Check those too: a lost one is started again without you (see the lost case below). MCP leases_list is not enough for this: it carries no timing and no worker version, and comes back as a single page with no cursor to reach further back. See Leases § List leases and HTTP API § Paging.

    • A completed lease placed no hold. Read its logs and the task's timeline for the refusals below, and check that the work it reported was done. See Read what a worker did. If it was not, put the task on a blocking hold with tasks_set_hold first, so that no pool starts work on it and no sentinel rule moves it on again (see Hold a task and clear a hold § 2). Then move it back to the stage it came from with tasks_transition, or move it in the web interface. A blocking hold stays on the task through the move. See Tasks § Move a task between stages.

    • A cancelled lease placed no hold, and Cadence does not start it again. Check it as you would a completed one: read its logs and the task's timeline, and if the work it did was wrong, hold the task and move it back as described there.

    • A failed lease, or a killed one stopped for running past its pool's time limit, put its task on a blocking hold, unless the task already had one. In that case the existing hold and its reason stay as they were. The new hold's reason reads dispatch blocked — manual intervention needed: followed by the pool's name and (lease failed: …) or (lease killed: …).

    • A lease is failed in other ways too, not only when its worker reports failure. One of them is a worker that keeps deferring its work for over six hours. That puts the task on a blocking hold with the reason deferred repeatedly for over 6 hours (last wake …); manual intervention needed. This hold replaces any hold already on the task, including one a person set, and that hold's reason is lost.

    • A lost lease is one whose worker sent no heartbeat for two minutes, for example because its container stopped. It places no hold. Cadence starts the task again on the same pool only when all of these are true:

      1. The lease was lost less than 24 hours ago.
      2. The task has stayed at the stage it was at when that lease was created, and has not left and re-entered it since.
      3. An assignment rule at that stage still names the pool and applies to the task.
      4. The pool is not archived and has no other lease active on the task.
      5. No later lease for the task on that pool ended in a state other than lost.
      6. The task has no blocking hold, no unresolved dependency that blocks at its current stage, and no unpassed required check.

      If any of conditions 1 to 5 is false, Cadence neither starts the task again nor holds it for the lost lease. If only condition 6 is false, Cadence does not start it again yet, but the third lost lease still holds it (see the next bullet). Cadence checks again about once a minute and starts the task once condition 6 is true, as long as conditions 1 to 5 still hold. Before the repin, a run that is started again uses the old version too.

      Cadence retries a lost lease only in that case, but other things can still start a pool on the task without you. Before the repin, each of them runs the old version too. These are some of them, not a complete list:

      • A dependency the task waits on is resolved, either directly or by a move whose resolution rule resolves or completes it. Deleting a dependency does not count. Cadence then dispatches the task again at its stage. That starts a pool only when an assignment rule at the stage names the pool and applies to the task, no other dependency still blocks the task at that stage, the task has no blocking hold or unpassed required check, and the pool has no lease active on the task. A rule with target: parent leases the task's parent, not the task. A required check that passes later does not dispatch the task.
      • An enabled scheduled rule whose subject is the task comes due, in a space that is not archived. It starts its pool even while a dependency or required check is unresolved. A blocking hold on the task stops its worker from starting; a dependency or check does not.
      • An inbound dispatch-worker rule that dispatches at the task acts on an event. It acts on an event only if, when the event arrives, it is enabled and is the first enabled rule on the topic, in position order, whose filter matches. The event then waits in a queue until the pool has no lease active on the task. An event that arrived while the lost lease was active is still waiting. Cadence takes waiting events up one at a time for each task and pool, oldest first, with no new event and no person. The queue is checked every 30 seconds, and an event starts on a check only when no lease of that pool is active on the task. So each later event waits until the worker started for the one before it has ended. If the pool has been started on the task again in the meantime, for example by Cadence retrying the lost lease, the event also waits until that lease ends. Disabling the rule does not stop an event that is already waiting. When Cadence takes the event up, it starts the pool only when the task has no blocking hold, no unresolved dependency that blocks at its current stage, and no unpassed required check. To see the waiting events and remove them before the repin, use inbound_queue_list and inbound_queue_remove; both need admin. See Inbound § The dispatch queue.
      • The task moves to another stage, for example when a sentinel rule moves it on or a worker calls tasks_transition. Cadence dispatches it at the new stage under the same conditions as the first item.
      • A worker whose lease reaches the task calls tasks_nudge or tasks_dispatch_pool while the task has no blocking hold, or replaces a blocking hold with an advisory one and clears it. Cadence dispatches the task at its stage under the same conditions as the first item.

      So do not assume the task is idle. Find out where it stands, and start it yourself if nothing has:

      1. Check whether a pool started on it again. Call GET /api/v1/leases?space=<key> with no state, and look for a lease with the same task and pool created after the lost one. If there is none, nothing restarted it.
      2. Repin the pool first, so that the run you start uses the new version.
      3. If an assignment rule at the task's stage names the pool and applies to the task, click Dispatch next to the pool under Retry pool in the task drawer, or call tasks_dispatch_pool with the task's key and the pool's pool_id. A rule with target: parent leases the task's parent, not the task. This also clears a hold on the task, and starts the pool only when the task has no unresolved dependency that blocks at its current stage and no unpassed required check. It is refused with pool_not_redispatchable when the pool has no finished lease on the task since the task entered its current stage, for example because the task left the stage and came back. When no rule at the stage applies to the task, the call succeeds but starts nothing. See Tasks § Dispatch to a pool.
      4. If no assignment rule at the stage names the pool and applies to the task, the dispatch was refused, or no new lease appeared when you check again as in step 1, assign the task to the pool with tasks_assign and assignee: "pool:<id>", or with the Assignee field. This starts the pool whatever the task's dependencies and checks, but a blocking hold still stops the worker from starting, so clear that first. See Tasks § Assign a task.

    • Cadence counts each task's lost leases on each pool. When a lost lease meets conditions 1 to 5 and is the task's third lost lease on that pool, Cadence stops retrying and puts the task on a blocking hold. Condition 6 does not apply to this step. The hold replaces any hold reason already on the task. The new reason reads dispatch blocked — manual intervention needed: followed by the pool's name and its number of attempts, such as (3 attempts), and names every pool that has reached that point for the task. Clearing the hold with tasks_clear_hold or the task drawer's Clear hold resets the count to zero for every pool, and after that the third lost lease holds the task again. tasks_dispatch_pool and the drawer's Dispatch reset the count only for the pool you dispatch. If the hold names more than one pool, the other pools keep their count. Cadence may then hold the task again for one of them on its next sweep, within about a minute, but only if that pool's last lost lease still meets conditions 1 to 5. That new hold can cancel the lease you just dispatched before it starts. To reset every pool, use Clear hold or tasks_clear_hold. tasks_dispatch_unblock resets the count for each pool it unblocks: the pool you name, or every pool still blocked if you name none. A pool you name that is not blocked is reported in already_clear, and its count is not reset. It does not touch a hold. When it unblocks a pool, it also dispatches the task at its stage, which starts every pool whose assignment rule at the stage applies to the task, is not archived and has no lease active on the task, but only while the task has no blocking hold, no unresolved dependency that blocks at its current stage, and no unpassed required check. So on a task still under its (3 attempts) hold it starts nothing until a person clears the hold. tasks_nudge is different: it clears the hold and resets the count, but it does not let the third lost lease hold the task again. After a nudge while a pool is still blocked, the third lost lease on that pool stops the retries and places no hold, so the task sits idle. A pool stays blocked even when another hold, such as a stage-loop hold, has replaced its (3 attempts) hold, so you cannot tell from the task's current hold. A worker may nudge a task with an advisory hold or no hold, so this can happen with no person involved. To keep that safeguard, clear the hold rather than nudge the task, or call tasks_dispatch_unblock with the task's key and no pool_id after any nudge: it resets every pool that is still blocked and lists them in cleared. To find and restart a task already left idle this way, see Tasks § Nudge.

    • A lost workflow- or space-subject lease is also started again on the same pool, on the old version before the repin. It needs no assignment rule. Only conditions 1, 4 and 5 apply, and it happens whether or not the scheduled rule that started the lease is still enabled or due, so disabling the rule does not stop it. Once the pool has three lost leases on that workflow or space, Cadence stops retrying them but places no hold, because there is no task to hold. This count is never reset, so no later lost lease of that pool on that workflow or space is retried either. Nothing in your task list points you to these leases, so find them in the list yourself.

    • A workflow- or space-subject lease comes from a scheduled rule, or from Cadence starting a lost one again as above. For each one that ran on an old version, completed or not, read its logs (see Read what a worker did) and undo by hand anything it did wrong. There is no task to hold or move back. A scheduled rule runs again at its next due time, shown as next_due_at by scheduled_rules_list, but only while the rule is enabled and its space is not archived. A disabled rule still shows a next_due_at, and nothing runs then. If a lease from the rule's pool is still active on the same workflow or space, the run waits until that lease has ended. Cadence has no tool or button that runs the rule sooner. Repin the pool before that next run, so that it uses the new version.

    • Cadence does not clear any of these holds for you, and repinning does not release them. Clear each one yourself, with tasks_clear_hold or the Clear hold button in the task drawer, and only after the pool is repinned. A blocking hold does not on its own keep the task waiting for you: a worker whose lease reaches the task can replace the hold with an advisory one and clear it, with no person involved. So check that no such worker is running before the repin. See Web interface § Making a task wait for a person.

    • Clearing a hold dispatches the task again at its current stage. That restarts a pool only when an assignment rule at that stage names the pool and applies to the task, the pool is not archived, the task has no unresolved dependency that blocks at its current stage and no unpassed required check, and that pool has no lease still active on the task. Before the repin, that run uses the old version. Work that came from a pool you assigned the task to, a scheduled rule or an inbound rule is not restarted by a clear: assign the task to the pool again, or wait for the rule to run again. An event already waiting in the dispatch queue when you clear the hold starts its pool when its turn comes only if the task then has no blocking hold, no unresolved dependency that blocks at its current stage, and no unpassed required check. If one of those stops it, the event is closed without starting anything and is not tried again, and an event whose turn came while the hold was still on has already been closed this way. Remove a waiting event with inbound_queue_remove first if you do not want that run. A scheduled rule runs at its next due time only while it is enabled, and an inbound rule runs only on an event for which it is enabled and the first enabled rule on the topic, in position order, whose filter matches. See Hold a task and clear a hold § 3.

  • Update any script or MCP client that sends or reads the old names. Your existing inbound upsert-task rules were migrated and need no change.
  • Replace bookmarks to /boards/ pages, and the links listed above that were not rewritten.

  What an old call gets back: over MCP, an old tool name such as boards_list is refused with unknown tool (code -32602). An old parameter name is not refused on its own: Cadence ignores an argument it does not recognise. Where the new name is required, the call is refused (code -32602) naming it, for example workflow_slug is required or workflow or workflow_id required. Look for these messages in your workers' lease logs and activity.

• cadence lease get prints a workflow: row in place of board:. The lease detail block now shows the slug of the lease's board on a row labelled workflow:, in the same position the board: row held. If a script reads board: from the human-readable output, change it to read workflow:, or switch it to --json, which the client passes through from the server unchanged. See Command-line client § Read one lease.

• Agent worker versions now name their LLM vendor; pools no longer do. If you run agent pools, check them. Every agent worker version you publish must now name an llm_vendor — anthropic, openai, google, eurouter or tensorx — and its workers draw on your account with that vendor. The llm_vendor setting on pools, introduced in September, has been removed: pools_create and pools_update no longer take it, and the pool form no longer shows it. A version whose vendor has no token Cadence can serve does not start its workers; Cadence holds the task until you act. Existing versions were given the vendor their pools named, when those pools all named the same one; otherwise a vendor inferred from the model name (claude-… as anthropic, gpt-… or o and a digit as openai, gemini-… as google); any other version was left without one. A version left without a vendor is served no LLM token by Cadence, and a draft forked from it cannot be published until you choose a vendor.

  For each pool, check the version it pins: call pools_get for its worker_version_id, then worker_versions_get on that id, and read llm_vendor. In the browser, the version's page shows (vendor: None) for a version with none. To give a pool a vendor, fork the version with worker_versions_fork, set llm_vendor on the draft with worker_versions_update_draft, publish it, and repin the pool to it with pools_repin. Then make sure the vendor has a token Cadence can serve. If the space has its own registration of that vendor, the token must be in that registration — Cadence uses an instance-wide registration only when the space has none of that vendor. See Fleet § Choosing a vendor, model and effort and LLM providers.

• Choose a model from a defined list, and set how hard it reasons. An agent version's model must now be one defined for its vendor, and a deprecated model can no longer be published. A new optional effort sets how hard the model reasons, and is handed to the worker in its lease. Call the new MCP tool llm_models_list to see every model, its efforts and its default. In the browser, the worker version form now offers LLM vendor, Model and Effort selects in place of a free-text model. See Fleet § Choosing a vendor, model and effort.

• Two new LLM vendors: Eurouter and TensorX. You can register either in a space or for the whole instance. A Eurouter token's limit is a seven-day spend in euros, read from Eurouter's own figures; a TensorX token's limit is a token count over seven days, like OpenAI and Google. Both hold a token back when the vendor reports the account's credits exhausted. See LLM providers § Accepted vendors and their limits.

• Read a task's timeline over the HTTP API. GET /api/v1/tasks/:key/activities returns the same entries as activities_list, and can also filter them by activity kind. Entries now also carry their id and the author's display name. See Tasks § Comments and the activity feed.

• File a task onto a named board over the HTTP API. Task create now takes an optional board slug and puts the task on that board's default stage. See Tasks § Create a task.

• A space export now carries each agent version's vendor and effort. See Spaces, teams, and tags § Export a space.

• Download the command-line client from your instance. On an instance that offers it, you can download the cadence command-line client yourself: choose Download CLI in the user menu, or call the MCP tool cli_releases_get for download links, checksums and the list of published versions. On an instance that does not offer it, nothing changes: get the client from whoever operates your instance. See Downloading the command-line client.

September 2026

• Search finds partial words and task keys. The last word of a search now matches as you type it, so deplo finds deploy before you finish the word. Pasting a task's key, such as OPS-42, puts that task first in the results. Searches need at least 2 characters, and a shorter query returns nothing. Snippets are now one short excerpt of readable text, without Markdown syntax. This applies to task and doc search over MCP, in the browser and over the HTTP API. See Search.

• Combined search results now list tasks first, then docs. If a program reads the combined search endpoint of the HTTP API, it needs to adapt. All task results now come before all doc results, and each group is ordered by its own rank. A task's rank and a doc's rank are no longer comparable, so do not sort the whole list by rank. The result limit now applies to tasks and docs separately, so a response can hold up to twice the limit. See Search § The combined search endpoint.

• A new search window in the browser. Press Cmd+K or Ctrl+K to search tasks and documents in your current space, the one picked in the space switcher. Results appear under separate Tasks and Documents headings, with the matched words highlighted. Use ↑ and ↓ to move through them, Enter to open one, and Escape to close the window. A result opens as a full page, and the search box stays in place while results load. See Web interface § Search.

• A task's own page is now a full page. The page a task link opens now has the top navigation and the search window. You can edit the task's body, assignee, priority, parent, tags and stage in place, as in the board's task drawer. A View on board link takes you to the task's board. The old Active, Blocked and Resolved status list has been removed, and the Stage field shows where the task is. See Web interface § A task's page.

• A classifier worker can set a task's checks and properties. Alongside agents and runners, there is now a third kind of worker: a classifier. A classifier asks a question-answering provider a fixed list of questions about one task — it runs no agent and no command. You author a classifier version with two documents: an input document naming the task attachments and questions to hand it, and an output document mapping the provider's answers to checks and properties on the task, written in Liquid. Pin a classifier pool to a ready classifier version, and when one of its leases finishes successfully, Cadence writes the checks and properties the output names onto the task — all-or-nothing, so a run that cannot apply its whole outcome writes nothing and holds the task instead. This is a way to have a check set or a property filled in without a person, decided in advance by the version you published. A classifier's provider key is supplied the same way as any worker's secret, as a credential-sourced environment variable on the version. See Fleet and What moves a task without a person.

• An abandoned time-log session no longer stays open forever. If a work session you started is never completed — the process running it dies, or you simply forget — Cadence now closes it for you once it has been open more than four hours, capping the recorded time at one hour rather than letting it run up or never settle. The session's auto_closed_at timestamp records when this happened, and a note lands on the task's timeline. Because the capped hour is what bills, completing a session that was already auto-closed is refused — you are told it was closed automatically and billed at one hour, and to start a new session for anything worked since. See Time logs.

• Provision an LLM vendor account to your workers. You can now register an LLM vendor account — Anthropic, OpenAI, or Google — and hold its tokens in Cadence, at space scope for one space or at instance scope as a fallback for every space. You enter a token's value in the browser only; it never crosses the API or MCP. Set a per-token usage limit (a seven-day utilisation percentage for Anthropic, a seven-day token count for OpenAI and Google), and Cadence reads each token's usage against it and holds a token back once it reaches its limit. Point an agent pool at a vendor with its new llm_vendor setting, and each of its workers is served the chosen token as LLM_TOKEN — the one with the most headroom, picked once per lease. If no token of that vendor can be served — none registered, or all at their limit — the pool does not staff its stage until you add or free one, so set your limits knowing that. Registrations and tokens are retired, never deleted. See LLM providers.

• Break usage down by which LLM token served it. Lease usage can now be filtered and grouped by token (the serving LLM-provider token) and registration (its vendor), alongside pool, worker version, task type, image, and day — so you can see how much each token and each vendor has run. Usage from a lease that drew on no token groups under no token. See Lease usage.

• Heroku release webhooks now tell a deploy from a config change. If you take work in from a Heroku app's api:release webhook, a release that only changed a config var, add-on, or dyno formation no longer looks like a deploy. On a succeeded release Cadence compares the slug it left running against the previous release's slug and fires heroku.deployed only when the running code actually changed — a new slug, the app's first release, or a rollback — and heroku.config_changed otherwise. A deploy event carries the deployed commit in data.ref; a config change carries none. Both events now also carry slug_id and previous_slug_id, the two slugs the judgement was made on. And a succeeded release Cadence cannot resolve — no Heroku token stored for the app, or Heroku unreachable — is recorded as a failed delivery with the reason, instead of filing a deploy task with no commit. See the Heroku events.

• A space's capacity ceiling is now measured in vCPU. The space-wide setting that caps how much runs at once — renamed Max vCPU, on Space → Settings → General — now counts processor, in vCPU, rather than a number of leases. A lease is admitted only when its whole size — the agent it runs plus every sidecar alongside it — fits under the vCPU the space has free, which is the same vCPU your capacity tier is sold in (16, 48, 128, 256). Any lease-count cap you had set here before this release has been cleared, not carried across — the new field starts blank, so on any space where you had a cap, set the vCPU figure you want. Blank still means no space limit, and 0 still admits nothing new. See the Max vCPU setting.

• A queued task now tells you why it is waiting. A lease that has not started running yet no longer shows a bare (queued) on its board card. Its chip names the real condition — the pool is full, the space or instance has no free vCPU, the pool is paused, the space is archived, the runtime is refusing a container, the agent has not claimed yet, or it is waiting until a set time. The colour and motion tell the two kinds apart: amber and still means the lease needs you to act (resume the pool, unarchive the space); neutral and spinning means it is working and will move on its own. And the task's timeline now records the wait too: a lease held behind a paused pool or an archived space leaves a one-time entry explaining the quiet, where both used to be silent. See how a queued lease reads on its board card and What moves a task without a person.

• See the instance's background jobs, including the ones that have failed. If you run the Cadence instance itself, there is a new admin-only Jobs screen at Settings → Jobs. It lists the background jobs Cadence runs without you — grouped by whether each is queued, in flight, scheduled, blocked, or failed. Failed jobs used to leave no trace anywhere you could look, so this screen exists to make a failure visible; opening it needs instance admin, and a job's listed arguments never include the prompt handed to a worker. See Jobs.

• Cap how many leases a space runs at once. A space now has a Max active leases setting, on Space → Settings → General: a ceiling on how many leases run at the same time across all of the space's pools. Leave it blank for no limit, or set a number to hold the space to it. When the space is at the cap, a task that would otherwise be worked waits its turn as pending rather than being dropped, and picks up the next slot that frees, oldest first — so nothing is lost, work just queues. A waiting lease records why it is queued, naming the ceiling it is behind. See the space capacity setting and What moves a task without a person.

• Bound how many cards a board column draws. A stage now has a Card limit: the most cards its board column draws at once. Leave it blank and the column uses a default of 200, so no column is ever unbounded and a busy stage no longer loads every card it holds. The column header still shows the stage's true total, so a bounded column never reads as though the extra tasks are gone; when a column is bounded, it shows a Showing … of … footer with a Show all link that loads the column in full. See the card_limit stage field.

• An old lease's detail is reclaimed to save storage. After a retention window, Cadence now clears the bulky detail of a finished lease — the prompt it ran from, any credentials it resolved, the summary it reported, its outcome, and its attachments. The lease itself is kept: it still lists and reads, and its billing and its activity timeline — including how it ended — are untouched. So an old lease's drawer shows a Detail reclaimed notice in place of the cleared fields. Expect this on old leases; it is a retention behaviour, not a fault. See Leases.

• A tag a board's WIP cap depends on is protected from deletion and merge. If a board WIP constraint uses a tag to filter what it counts, you can no longer delete that tag or merge it away while the constraint still points at it. The attempt is refused and names the constraints that use the tag, so you rewire or remove the filter there first — deliberately, rather than having a cap silently widen to count every label. This guards tags the same way the existing guard protects a tag an assignment, check, sentinel, resolution or property rule uses. See the tag registry.

• Run a pool on a schedule. A new kind of rule starts a worker on a cadence you set — with no event and no person. Point a scheduled rule at a task, a board, or the whole space; set its schedule as a cron string, a phrase like every 6 hours, or a plain duration like 6h; and enable it. One worker runs at a time for a given subject and pool, so a rule never stacks a run on top of a worker that is still going. Manage scheduled rules over the Model Context Protocol endpoint, or on the new Automation tab in a space's settings. See Scheduled rules.

• Inbound webhooks that start a worker now queue instead of racing. When an inbound rule dispatches a pool at a task, a burst of events for the same task and pool no longer races or gets dropped — each waits its turn and runs one at a time, in the order it arrived. While one waits, its delivery reads waiting for a free worker. You can review the backlog and remove an action you no longer want started. See the dispatch queue.

• A worker started by an inbound event can read what triggered it. A lease minted by an inbound webhook or email now carries the triggering event in its payload — the topic, when it happened, and the event's data. For an email that is the sender, recipient, subject, body, and attachment list. The email body now falls back to the message's HTML rendered to text when there is no plain-text part, and inline images are listed alongside declared attachments, so a worker answering an email has the whole message to work from.

• Leases report what they answer for. A lease now names its subject — a task, a board, or a whole space — when you list or read it, and a worker reading its own lease gets a description of that subject. A lease that runs against a board or a space carries no task, and reads that way rather than failing. See Leases.

• A worker can move its own task to another board without stopping first. When a worker moves the task it is working to another board, its own running work no longer blocks the move — it need not cancel itself first. Every other active lease on the task still blocks the move, and moving a task yourself is unchanged. See Move a task to another board.

• See a task's dependencies on the board. A task that blocks another task, or is blocked by one, now carries a dependency mark on its board card. Click it to open a full-screen, read-only view of the task's whole dependency chain — every task connected to it by dependency edges — with an arrow from each blocking task to the task it blocks. The task drawer opens the same view through View graph. Creating and clearing dependency edges is unchanged. See Task data.

• Download a doc as Markdown. A doc's reading page now has a Download button that saves the doc as a Markdown file — its title as a heading, then its body. The download reads only: it writes no version and records no activity. See Docs.