Cerevisor 3.7.1: an autonomous coding agent that works a queue

By the founder of Cerevisor. Checked on 3 October 2026 against the source code of Cerevisor 3.7.1.

On 2 October, one row in a test queue of mine ended the way I had hoped it would. The item was a small submarine game that runs in a browser. The project’s tests ran clean: 48 passed, none failed. The agent that checked the work still wrote FAIL at the top of its verdict, because it could not confirm the sound and the zoom by using the game. Its own note said the fail “denotes incomplete acceptance, not a reproduced game defect.”

That refusal is what Cerevisor 3.7.1 is built around. Cerevisor is a desktop app where AI agents are laid out on a canvas as a workflow, each handing files to the next. An agent here is an AI model given a task, some tools, and room to take several steps on its own. An autonomous coding agent is one that writes and changes code with nobody steering each step. Version 3.7.1 lets a workflow act as one across a whole list of work, under one rule: done means checked.

Every change is listed in the 3.7.1 release notes. This is the version I would want to read before trusting it with a real project.

Setting up Factory mode on one project

Factory mode turns one workflow into a worker for one project folder. A button beside Schedule opens its settings, and one press lays out a ready-made team of seven agents in five stages. Three research the request and the code. One agrees an approach with the person at the desk. One plans. One builds. One, which had no part in the building, checks.

Next comes the project folder. Cerevisor reads the file names at its top level and at most three small files, then prints one line saying what it can verify the work with: the project’s own test, build and lint commands. A button runs the test and build commands once each, with no model involved and nothing billed. A broken test setup shows up there, before any agent has spent anything. Each command gets 10 minutes before it is stopped.

Then comes the choice that shapes everything after it. Attended means the factory stops for questions and approvals and waits with no timer. Unattended means nobody is there: the model decides the questions, approvals pass at once, and every one of those choices is written to a decisions file in the item’s own folder. Unattended has to be confirmed twice, once on the workflow and once on the computer. What a person sees at an approval, and how asking for changes works, is in yesterday’s reference on agent governance patterns.

What one queued item goes through, from request to commit

An item is a few sentences typed into a box, with up to 10 pictures when a screenshot says it better. Press Start and the factory takes the first waiting item from the top.

Each try gets its own folder inside the project. It holds the request as written, the commands to verify with, every report the agents write, and the record of decisions. The agents themselves work in the project. Before anything is built, the planner writes down what done means, as a numbered list of things that must be observably true. After the build, the checker uses the result the way a person would, runs the project’s commands, and writes a verdict: pass or fail, then one result per item on that list.

A fail does not end the item. The factory tries again straight away, and the new try starts from the last one’s work with a note listing what the checker found, what the builder reported and what was decided. In a git project (git is the version history tool most software teams use), each try is saved as its own commit on a branch kept for the factory. Undoing one item later is ordinary git:

git log --grep=<item id> cerevisor-factory
git revert <commit>

Nothing is pushed, merged or rebased. That is a position, and not the only one on offer this week. GitHub’s changelog of 1 October describes a preview feature for Copilot that goes further: “Enable agent merge in an active session to let the agent handle review feedback, failed checks, merge conflicts, and workflow reruns.” Both are reasonable designs. I want the last step toward a shared branch to stay with a person, so the factory stops at a local commit.

Two things pause the whole queue instead of one item: three items in a row that do not finish, and a project with uncommitted changes when an item is about to start.

A queue of work is only as trustworthy as the check at the end of each item. Most of Factory mode exists to keep that check honest.

Two failures from release week, and the fixes that shipped

Both came out of testing in release week. Both changed the product before it went out.

The game that passed and would not open. On 1 October an item came back validated, and the game did not start when opened the way a person opens it. Every check behind that pass had been a unit test or a reading of the code. The fix is in the instructions the ready-made team ships with. The planner now lists first the things a person checks by using the result. The builder must follow its own “how to use it” steps before it finishes. The checker must use the result before it reads any code, and whatever it cannot use is marked as could not check, which makes the verdict a fail. The submarine row at the top of this post shows the same rule holding the next day.

The agent told to ask, with nobody there. The approach agent’s whole job is to interview the person. In an unattended item there is no person. One row in my test queue, stamped 1 October, ends with the workflow halting on exactly that agent: it had been judged against instructions it could not follow. The fix shipped on 2 October. An unattended item now leaves that agent out, the planner chooses the approach and writes that the model chose it, and every remaining agent is told in its own instructions that nobody is there to answer.

What a queue costs, and where the spending limit stops

Each try runs the workflow again, so tries are the unit of cost. These are the limits as the product states them.

The spending limit needs one careful sentence. It counts what all the tries of one item have cost together, and it is looked at only when the factory is about to start another try. A try in progress is never cut off, so one try can carry an item past the limit. The next try is then not started. It is a brake on trying again. A ceiling on a single run is the workflow’s own cost limit, a separate setting, and a run that reaches it is not tried again.

Other tools tightened the same screw this week. The Claude Code changelog for version 2.1.288, dated 2 October, fixed unattended sessions that had been:

A loop with nobody watching needs a count that ends it. In Factory mode that count is tries per item.

Three more things move the bill. Agents set to Auto get a model picked for each try, always on the account that agent already uses, and a try after a failed one prefers a stronger model. Picking usually costs one small extra model request each time the workflow runs. Second, the check that asks a model whether each agent did what it was asked costs a model call per agent, so in 3.7.1 it is off until switched on. Third, a model with no known price still runs, but a red line warns that the spending limit cannot see its cost.

I would like to print a real dollar figure from my own queues here. I cannot: the cost column is empty on every row of my test files, and an empty cell is how the queue file writes zero. So there is no figure, and I will not invent one. Check that the models in use have a known price before leaning on any limit.

Adding work to the queue from a script or a build server

The local API is a door on the computer that other programs on the same machine can use to run saved workflows. It is off until switched on under Settings, Automation. It listens only on the computer itself, and every program needs a secret token that can be replaced at any time. Tools that speak MCP (Model Context Protocol, a common way for AI tools to call other software), such as Claude Code or Cursor, connect by pasting a copied block of settings.

For scripts there is a command. This one adds an item to a project’s queue:

cerevisor factory add "D:\Projects\shop\shop.cerevisor-world" --request "The checkout page shows the total twice" --title "Checkout total" --source-ref ci-1234

It prints the word queued and the new item’s id. The last option is a key for whatever caused the item, such as a build number. The same key is not queued twice while its item is waiting, running, failed or needing a person. Adding never starts the factory. A person presses Start.

Running a whole workflow and waiting for the result looks like this:

cerevisor run "D:\Projects\Reports\reports.cerevisor-world" --wait --out result.json

A run started this way asks its questions as any run does, in the app window, on a paired phone, or answered from a second terminal. Nothing is approved on the script’s behalf.

One trap on Windows is worth knowing before it costs an afternoon. Cerevisor is a windowed program, so PowerShell and the Command Prompt do not wait for it, and a script never sees how the run ended. The fix is to ask Windows to wait:

$p = Start-Process -FilePath "C:\Program Files\Cerevisor\Cerevisor.exe" `
  -ArgumentList 'run', '"D:\Projects\Reports\reports.cerevisor-world"', '--wait', '--out', '"D:\Projects\Reports\result.json"' `
  -Wait -PassThru
$p.ExitCode

An exit code of 0 means the run completed, 1 means it failed or was stopped, and 4 means Cerevisor is open with the local API switched off. The rest are in the guide to running workflows from scripts.

Smaller changes that alter an ordinary day

New models without an app update. Each saved provider (the company whose service an agent calls) has a Refresh models button. Cerevisor asks the provider which models the account can use today and they appear in the pickers. A refresh that fails or comes back empty leaves the list that worked in place.

Model picking outside the factory. The same Auto routing can be switched on for ordinary runs, and the run window says which model each agent got and who decided.

Web access on for new workflows. A new workflow can reach any site, so search works on the first run. Saved workflows keep their own setting.

A help chat that cannot change anything. It answers from the help pages and can look at workflows and recent runs. Asked for a change, it explains how to make it.

The notes also list an agent being skipped when every one of its sources was skipped or failed, and Operator building workflows in the background, marked experimental. I have not checked those two in the code for this post.

Known limits in Cerevisor 3.7.1

• One item at a time, one factory per project folder, and only while Cerevisor is open. It never starts by itself.
• No phone view of the queue, and no link from an item to its recorded run.
• Outside a git project items change files directly: no commits, no undo per item, and nothing checks whether the checker edited the work. My test folders were not git projects, which is why this post shows no commit ids.
• Build output must be on git’s ignore list. If the checker’s own test run rewrites build files that git is watching, a good item is refused.
• Pinning a note on the team board while the factory works pauses it.
• Pictures cannot be added from a script, only in the app.
• Copying the MCP settings can issue a new token, so programs connected earlier need the new block.
• Auto routing skips agents on Antigravity, OpenRouter and Ollama. My test rows show it: each agent’s entry reads that it kept its usual model.
• Windows installers are not yet code-signed and macOS builds are not notarized. A SHA-256 hash, a fingerprint for checking a download, is published beside each installer.

What I would run first after updating

I would not start with a real backlog. I would take a small project that is already in git and has tests that pass, press the button that checks the commands, and queue three small items in attended mode. Then I would open one item’s folder and read it end to end: the request, the criteria, the verdict, the decisions.

If that folder would make sense to a stranger, I would switch to unattended with a spending limit typed in, and go and do something else.

Factory mode and the local API are part of Founding membership and are included in the 7-day trial. The Factory mode guide has every status and message, and the installers are on the download page.