What updating to Cerevisor 3.0 unlocks, on top of 2.4

When the four-agent ceiling came off in 2.4, the natural question was whether wider parallelism was actually safe to use at scale. Twelve agents starting at once is useful only if you can tell what they are about to do, catch what went wrong mid-run, and review the record afterward. That accountability layer is what 3.0 adds on top of 2.4’s ceiling removal – one connected upgrade to the same product, not two separate feature drops to weigh against each other.

Why wider parallelism needed an audit trail first

Before 2.4, Cerevisor ran at most four agents in a wave simultaneously – a fixed ceiling set in the original scheduler (the part of the software that decides how many agents start at once and how quickly). Before 3.0, a run’s record was kept in two separate stores that could disagree with each other, runs whose live view was never saved could not be reopened after a restart, and there was no summary of what a run intended to do before it actually did it.

Those two limitations compounded each other. Running four agents you could not fully audit was already a trust question. Running twelve under the same conditions would have made it worse. The releases addressed them in order: first, the ceiling; then, the accountability.

What 2.4 introduced on the parallelism side: a process-wide scheduler (the single component that manages all agent seats across a run) with separate budgets for cloud-API work and for local work that lands on your own machine. Cloud credentials start at sixteen concurrent requests each, up to sixty-four across all credentials combined. Local models at a loopback address – Ollama or vLLM running on localhost – keep exactly four, matching their GPU memory constraints. When a provider pushes back with a rate-limit response (an HTTP 429, meaning “you are sending too fast”), the affected credential’s concurrency drops by thirty percent. A second rate-limit within sixty seconds halves it. After ten clean requests with at least thirty seconds of calm, it recovers by one. This adaptive back-off means the scheduler is not guessing at a safe ceiling: it is reading one in real time from the provider.

The three moments the last two releases now cover

Across 2.4 and the 3.0 update that follows it, Cerevisor now closes the gap at every point in a run’s lifecycle: before it starts, while it runs, and after it ends.

Before a run starts. Every run in 3.0 shows a plain summary first: which agent runs on which model, which connected servers it can reach, what the run should cost, and anything that will limit it. Cancel or run – nothing is started, spent, or reserved while you read it. For a twelve-agent wave across three providers, that summary shows you all twelve agents and their assignments before you commit. If the workflow has gained new capabilities since you last approved it – new tools, new connected servers, broader file or shell access – the summary grows an approval step that lists what changed in plain language. An automatic run (from a schedule, the Operator, or a loop) that finds itself in the same situation is skipped rather than auto-approved, and you are told why.

While it runs. The run window in 3.0 lists every file a run creates, changes, or reads as it happens. It calls out anything changed that the workflow never declared. Alongside this, 2.4 changed what tool results say: a command that exits with a nonzero code, times out, or is refused is reported as such, not handed back to the agent as ordinary prose. A denied file access reads “not allowed” rather than appearing as an error. The combination means that a wider wave is also a more legible one: you can see which files changed and whether the tools that did it actually reported success.

After it ends. A run’s status, cost, files, and timeline are read from the run’s own saved record in 3.0, which means a run window opens correctly long after the run finished, including after a restart, and including runs whose live view was never saved at the time. Run history no longer drops older runs when a history limit is hit. Any run can be exported to a JSON file with secrets removed before it is written. The Operator’s history is now written from what actually happened during each action, and a run the Operator started is labelled as such in the run window, with a link that opens the specific run directly.

Autonomous runs now prepare the same way you do

The change that matters most for unattended workflows is the one that received the least attention in the release notes: in 3.0, every run that Cerevisor starts on its own – a schedule, a loop, a pipeline stage, a Power invoked by a workflow, a run the Operator starts – now checks its working folder and its model availability before it begins, exactly as a manual run does. Before 3.0, those runs could silently fall back to a different model or start in a folder that no longer existed.

Those autonomous runs also follow your approval settings. In 2.4, stopped runs reported “stopped” rather than “failed” and kept their spend. In 3.0, if a run cannot write its own history record, it stops before its next action rather than continuing unrecorded, and the entry in run history is marked “stopped – history could not be saved.” There is a setting to change this behavior if you want the run to continue with a notice instead.

Stacked in order, a scheduled twelve-agent wave now validates its folder and providers before it starts (2.4), shows a summary of what is about to run (3.0), backs off if a provider rate-limits mid-wave (2.4), tracks every file change as it goes (3.0), and leaves a durable record you can open or export the next morning (3.0). That is a different category of autonomous operation than what was available before this pair of updates.

Sixty-four is the real number to plan around, not a round estimate: it's the global concurrency budget in the scheduler's own configuration, split across whichever cloud credentials you've connected. Individual credentials start at sixteen concurrent requests each and the scheduler raises or lowers that per credential based on how each provider responds, but the combined total across every credential is capped at sixty-four. Local models on loopback (Ollama or vLLM on your own machine) are governed separately and net out to about four concurrent agents, sized to typical GPU memory rather than to the cloud budget. There is no single higher ceiling that unifies the two pools -- the cloud and local budgets are deliberately kept apart so that congestion in one never bleeds into the other.

What this changes in practice

The practical boundary that moved is not raw parallelism – it is what you can confidently hand to an unattended workflow without needing to watch it. Before these two releases, the answer was roughly: a single, small, short run you could monitor in real time. After updating through both, the answer is closer to: a multi-stage workflow across several providers, running on a schedule, with a record you can review in the morning.

Three specific things that are now straightforward that were not:

Audit a run from the previous night. Open the run window for any run in history. The record is read from the run’s own saved file, so status, cost, files touched, and per-agent outcomes are all there whether or not you were watching when it ran.

Approve before a wider wave commits. The pre-run summary covers every agent in the wave, not just the first. If the workflow gained new tools or server access since you last approved it, you see that before anything starts. Autonomous runs in the same position are held for your review rather than proceeding.

Hand a pipeline to the Operator with a recoverable failure mode. If history cannot be written at any point, the run stops before its next action. The Operator action that started it and the run it caused are linked in both directions. The run can be exported to a file with secrets removed before any sharing.

Wider parallelism was the change you could measure. Legible runs are the change that makes wider parallelism something you can operate.

A single pass through Cerevisor’s built-in updater brings a 2.4 installation current to 3.0, since 3.0 is built directly on top of 2.4 rather than a separate track. The 3.0.0 release notes include a known-limits section that names four failure scenarios the automated testing identified but did not yet fix, and lists several features verified only by the test suite and not yet by hand in the running app – the kind of honesty that belongs in release notes and in the work you do when deciding which capabilities to lean on first.

The full documentation for connecting providers and configuring the scheduler is at cerevisor.com/docs.

By the Cerevisor team