Cerevisor 2.4.0: waves as wide as your machine allows, honest tool results, and searchable model pickers
· v2.4.0
Cerevisor 2.4 removes the four-agent ceiling with a scheduler that adapts to your machine and your providers, makes every tool result say plainly whether it succeeded or was refused, keeps agents inside the folder you pointed them at, and adds search to every model picker.
Cerevisor 2.4 is about knowing what your agents actually did — and letting them run as wide as your machine and your provider allow. The fixed ceiling of four agents at a time is gone; agents take a seat from a shared scheduler and back off when a provider says “slow down”. Tool results now say plainly whether they succeeded, were refused, or failed. Agents stay inside the folder you pointed them at, and ask first when a command reaches somewhere else. Picking a model is now a matter of typing its name.
Every model list is searchable
- A search box now sits on top of every model picker: the chat model badge, Chat Builder, the planner field, the per-agent picker, Settings, and the Provider Hub.
- Typing narrows by model id or name, and Escape clears the query before the menu closes.
- The two remaining plain dropdowns — the smart-routing orchestrator model and the Claude model field in the API-key lane — became searchable lists too, so no model selector is left without search.
- Switching provider or reopening a menu always starts from a clean query instead of a stale one.
The agent log reads as one conversation
- Steering messages you send mid-run now appear where you sent them, interleaved with the agent’s activity by time, instead of being pinned in a separate block underneath.
- The expanded log panel is taller, and a pending permission or approval card scrolls on its own — a long command with a warning and Approve/Deny buttons is always fully reachable instead of being clipped.
- The collapsed on-card log counts activity and steering together, so the “+ N earlier” hint matches what is actually hidden.
A calmer canvas
- The workflow input box was retired from the canvas. It spent permanent space on something a popup does better.
- Workflow input is now configured from Manual Controls → “Workflow input…”, which opens the same panel with the same settings.
Runs report what actually happened
- Tool results carry a real outcome. A command that exits nonzero, times out, or is refused is reported as such, with its exit code, rather than being handed back to the agent as ordinary prose.
- A denied tool call now reads as “not allowed” in the log instead of looking like an error, and stays visible under every log view mode.
- When an agent tries to read or write outside the folder it is allowed to touch, the run log shows an amber “Not allowed: …” line instead of a red error, it no longer counts toward the “too many failures in a row” stop, and the agent is told which path was refused. This reads the same way everywhere, including chat and organization conversations.
- Analytics separates tool calls that ran and reported a failure from tool calls that never got to run at all, so the failure numbers say which of the two happened.
- A run that ran out of budget or turns finishes as budget-exhausted, never as a success. Pipelines, schedules and history all consume that same honest outcome.
- A reported tool failure informs the agent without tripping the loop-breaker, so an agent can recover from a failed command instead of stalling.
- Agents preserved from an earlier wave are no longer stranded, and a write outside the workspace reads as a notice rather than a denial.
Tools stay where you pointed them
- File search, listing and pattern matching honor the declared-path boundary on every path they touch, not just the first one.
- A junction or symlink inside the workspace can no longer be used to step outside it.
- A shell command that names a path outside the workflow folder asks for confirmation first, and the prompt says which path it is. Escalated prompts never quietly grant permission for the rest of the session.
- Cerevisor is explicit that a shell can reach beyond its declared paths, and reports writes made outside the workflow folder after a shell-capable agent runs.
- Detection of writes outside the workspace now also watches your home folder, Desktop, Documents, the temp folder, and one level above the workflow folder.
Reaching the web is judged more carefully
- A shell command that fetches from the network now marks the agent as having taken in untrusted content, the same way a web fetch does — including background fetches, which taint when polled, and
powershell -EncodedCommand, which is decoded before it is judged. - A web request that is not a plain read asks for confirmation in Auto mode.
- A custom header can no longer disguise or downgrade the risk of a web request.
- A colleague consulted inside an organization can read from the web but not act on it.
- Model Context Protocol server tool schemas are passed through intact, so Gemini receives the full schema a server declares.
- An agent that has both read untrusted content and holds secrets loses its outbound access for the rest of the run the moment it tries to send something out — even when that attempt was already refused for another reason, such as web access being switched off. Previously, a request refused early could leave the door open for a later one.
Grok Build agents follow the house rules
- The “ask before a shell command reaches outside the folder” rule now also applies to Grok Build agents. It previously only covered agents running on Cerevisor’s own loop.
- Grok Build tools that call themselves read-only no longer get an easier ride. Cerevisor used to trust a tool’s self-declared “read-only” flag and lower the scrutiny on it. It no longer does, so an unattended run that previously auto-approved such a call may now stop and ask — or, with nobody there to ask, refuse it.
- Grok Build tools Cerevisor doesn’t recognize are treated with care by default: a Grok-native tool with no Cerevisor equivalent is treated as potentially destructive unless it is genuinely read-only, rather than being waved through.
Schedules, stops and the Operator tell the truth
- Scheduled runs now check their folder and their model settings for real before starting. A schedule validates its working folder and builds its provider assignments the same way a manual run does — so per-agent model choices are honored, and a schedule pointing at a deleted folder or a signed-out account fails immediately with a clear reason instead of quietly falling back.
- Stopping a run now says “stopped”, not “failed”. Agents you stop are shown as stopped, with no error row, and the run log says so — including the other agents in a wave when you stop the whole run. On the phone this needs the companion app updated; older phone builds keep showing the previous wording.
- A stopped run keeps its cost and token numbers. Stopping no longer zeroes what the run had already spent — the spend shows in the run totals, the session, and Analytics, including work launched from inside another agent.
- If Cerevisor is closed mid-action, the Operator says so next time you open it. An action interrupted by a crash or a quit is marked “interrupted before completion” in its history on the next start, instead of vanishing. This works if you reopen within about two days.
Antigravity agents show their work
- An Antigravity agent’s tool calls and results now stream into its log as they happen. Antigravity’s own terminal shows almost nothing while it works, so these runs used to read as a long silence followed by a wall of text.
- Its reasoning streams too, step by step, instead of arriving all at once at the end.
- Because tool activity now counts as a sign of life, a busy Antigravity agent is no longer cut short for “no output”.
- Tool call counts for Antigravity agents are real numbers rather than always zero.
- Three Antigravity quirks that made runs fail their output contract are now headed off up front: files written with attached metadata were silently discarded, long commands were pushed to the background and then waited on forever, and relative paths landed in a scratch folder instead of the working folder. Agents are told the working folder, asked to keep commands in the foreground, and asked to confirm each declared file exists before finishing.
Cerevisor’s own files stay out of your agents’ way
OUTPUTS.md,folder.mdandrun-report.htmlare Cerevisor’s bookkeeping, and are no longer treated as part of your folder’s contents. They had been feeding the folder summary, which then taught every agent to “keep run-report.html updated” as if it were a project convention.- The run report Cerevisor asks the final agent to write is now recognised as an expected output of that agent, so writing it no longer shows up as an unexpected file change on the last agent of every run.
Waves run as wide as there is room
- A wave of twelve agents on one API key now starts twelve, not four at a time. Parallelism is decided per agent by a process-wide scheduler with separate budgets for cloud APIs (64 in flight, 16 per credential) and for work that lands on your own machine (local models, Codex/Antigravity/Grok processes, browser agents), each weighted by how heavy it is.
- Nothing gets slower: every kind of agent keeps at least the old four-wide, and local models pointed at
localhost(Ollama, vLLM) keep exactly four. - A seat is always given back — when the agent finishes, fails, or is cancelled — and an agent still waiting for a seat when you cancel simply never starts.
- Power runs launched from inside a running agent ride on that agent’s seat instead of competing with it, so a busy wave can never deadlock itself.
Providers that push back get a lighter touch
- A rate-limit answer (429) trims that credential’s concurrency by 30 %; a second one within a minute halves it; a server error steps it down by one. After ten healthy calls and half a minute of calm it climbs back one step at a time, never above the credential’s ceiling and never below one.
- Retries of the same rate-limited call count once, so a single “please wait” cannot collapse a whole credential.
You can see it
- The run view header shows “Running N agents · M waiting for a free slot” while a run is active and disappears when it is done. Nothing is sampled while the app is idle.
- A hidden setting,
orchestrator.maxParallelAgents, caps parallelism to an exact number when you want one (leave it unset to let the scheduler decide).
Under the hood
Every run — from the Run button, a schedule, a pipeline, a loop, Progressive, a Power, an organization chat, or the Operator — now enters through a single gateway that resolves permissions, records the run, and can refuse it before anything starts. Agents are dispatched through a provider registry that fails to compile if a provider is added without one, and background spend is recorded against the run that caused it.
Every tool call an agent makes is now decided by a single ten-step check that can only get stricter as it goes — a later step can tighten a decision but never loosen one — and each decision is recorded in the run’s ledger. Grok Build calls go through the same check live; the other external harnesses get an honest record of what they were handed. The Operator, too, now writes down what it is about to do before it spends anything, so every Operator action and the run it caused can be traced to each other — and to a real outcome and a real cost, on success and failure alike.
- Wave scheduling now reads a prebuilt index of the workflow instead of rescanning every connection per agent, which makes large workflows start faster.
- The audit trail and run ledger record lease, budget-adjustment and occupancy events.
- Test infrastructure: the suite no longer leaks temp directories, so a full local run takes minutes instead of an hour.
Known limits
- Single-agent replay, subagents and nested runs are bounded by their parent’s seat and the provider feedback, not by seats of their own.
- Gemini server errors are not yet visible to the back-off logic (rate limits are).
- The real-app checklist for this release is recorded as unverified in
docs/plans/2026-08-30-stream-c-gate-checklist.md.
Updating
Existing installations receive 2.4.0 through Cerevisor’s built-in updater. New installers are available from cerevisor.com/download and the private GitHub release.