Community feedback is key to building a great open-source product

The acceptance gate was always running real checks; it just collapsed them to pass or fail at the last step. "Four checks failing" and "forty checks failing" were the same answer, so nothing watching could tell steady progress from going in circles.

It now reports how many checks pass out of how many. Same checks, same output. We just stopped throwing away the part with direction in it.

The detail we would have got wrong unaided: the gate runs against a throwaway checkout of one specific commit, not the live folder. Score the folder your agent is actively saving into and the number drifts for reasons that have nothing to do with progress.

Small distinction. It is the difference between a measurement and a rumour.

The old behaviour nudged every agent every five minutes. That is wrong twice over: it breaks the concentration of one that is making progress, and it leaves one that has been stuck since the first minute alone for four more.

Now the score is tracked over time, and an agent is only interrupted when it stops improving. When it is, the message quotes the exact checks that are failing. The gate already knows, so there is no reason to make the agent go looking.

Three agents working in parallel used to be completely blind to one another, so each could independently discover the same broken assumption and each pay for it. They now share a notes directory.

Here we deliberately did not copy what we found. The original scopes those notes to a single run and deletes them afterwards, which suits a research tool. Ours are scoped to the project and kept, because the second person to read them is you, weeks later, and they belong in your vault where you can search them on your phone.

Today our planner is told to split a build only into pieces that are genuinely independent, because there was no way to express "the API needs the database schema first". That caps how much can run in parallel, and it forces genuinely sequential work into one long slice.

A piece can now declare what it depends on. Independent work still runs at full width; dependent work waits instead of guessing; and if a foundation fails, everything built on it is marked unreachable and never starts, instead of producing an hour of confidently wrong code.

A waiting slice holds no worktree at all, so a slice that turns out unreachable leaves nothing behind to clean up.

We had designed this to detect an impossible plan while the build was running. Then we read someone else's, which checks the plan the moment it is written: every dependency must exist, loops are refused, depth is capped.

Strictly better, and it changed our design before we shipped it. A plan is already wrong the second it is written; that is when you should be told, not forty minutes later.

A failed agent used to be restarted forever, which meant a broken build was indistinguishable from a slow one and never finished; it sat there looking healthy. It now gives up after two attempts and says which slice died and why. Consolidation refuses to merge a build with a dead slice in it, rather than shipping whatever the survivors managed on top of a foundation that never landed.

We already read how much of your Codex plan you have consumed, but not what an individual session cost, which is the question once you can pick your provider per session. Codex writes its own transcripts, so now we read them: tokens in, cached, out, and an estimate per session.

One detail worth stating: cached input is billed at a fraction of fresh input, and on long sessions it dominates. One real transcript here was 179M cached of 189M input. Ignoring that distinction would overstate a session roughly tenfold. And the figure is a list-price estimate, not a bill: on a subscription the marginal cost is zero, so it means “what this would have cost on the API”.