GovernCode has a Controller, which is the AI tool I pick to lead, and Runners, which are the other AI tools it hands small, written-down jobs to. Those jobs are called Specs. Each one runs on its own copy of the project, and nothing touches my real files until I’ve read the diff and said yes.
Over the last few days I’ve been fixing the three things about that setup that irritated me most. The Controller forgot things, it did one job at a time like a bloke queuing at a post office, and when an AI hit its usage limit, GovernCode’s plan was basically to stand there looking at it.
One thing up front, because I’d rather say it than have you find out the hard way: none of this is released. It sits on a local branch, it hasn’t been pushed, and the version I actually have installed is still the published motion.9 from September 30. The tests pass and the code has been reviewed, but I haven’t lived with it yet. Treat everything below as “built”, not “proven”.
The Controller was cutting my sentences in half
When a Controller starts a turn, GovernCode hands it a record of the recent conversation so it knows what’s going on. The way I’d built that was crude. It kept the first 1,500 characters of what I’d written and the last 2,500 of what the AI had said, and chopped the rest off wherever the scissors landed. Mid-sentence, if that’s where the count ran out. After ten exchanges it also dropped the very first request, which is usually the one that explains what the hell we’re doing. And it labelled every reply “you”, so a Controller reading the record could not tell its own words from another AI’s.
It now works in whole messages. There’s a budget (16,000 characters by default, and gov memory changes it), and the latest message, the latest reply, and the first message since my last reset always go in first. After that it fills up newest to oldest. If a message doesn’t fit, it gets skipped entirely rather than shortened, because a half-quoted instruction is worse than a missing one. Every reply now says who wrote it, something like “you (claude-code · sonnet)” or “another Controller (codex · gpt-5.5)”, and notes when a turn ended early.
There’s also a new tool that lets the Controller read earlier messages, or one long message in pieces, when the record says something was left out. It’s read-only, it never reaches back past my last reset, and it never works for Runners. The Trace, GovernCode’s log of everything, now keeps 20,000 characters per prompt and reply instead of 2,000 and 4,000, because there’s no point offering a way back to history I’d already thrown away.
Review caught a nasty one in this: after a “start fresh”, a Controller’s own turns could become unreachable if a lot of another provider’s turns came after them. That’s fixed.
One job at a time was embarrassing
Handing a Spec to a Runner used to tie up the turn that made it. Now it returns straight away, the Spec carries on in the background, and I can have several going side by side. The defaults are 3 per project and 2 per Runner, adjustable in Settings. Go over a cap and it refuses instead of quietly queuing.
A few other things changed so that this isn’t chaos:
- Approval requests belong to the daemon now. If a Runner needs a yes from me, that request shows up in every client, not just the terminal that happened to start it. It’s denied if I ignore it for an hour, or when the Spec ends.
- The Controller can follow up or cancel. A follow-up reuses the same copy of the project, gets a fresh approval and a fresh Limit check, and the final diff covers every round.
gov canceland a Cancel Spec button do what they say. - The Controller hears when a Spec finishes. There’s a setting for it: wake it automatically with a short read-only turn (only while the Dashboard is open), mention it with my next message, or say nothing.
- Restarts don’t resume anything. If the daemon dies mid-Spec, those Specs are marked failed with their copy kept for me to look at, and nothing starts by itself. Boring on purpose.
Building it also turned up a few real bugs. A Runner stopped while it was still starting just kept running, for Codex and Antigravity. A Controller that failed to start left the project marked as working. A Runner that never started got counted against its Limit. All fixed.
Hitting a usage limit shouldn’t be a dead end
This was the biggest chunk, and the one with the most ways to get it subtly wrong.
First, detection. GovernCode now recognises when Claude Code, Codex or Grok has run out of usage, and when the provider says when it resets, it records that time. If the reset time isn’t known, it says unknown instead of guessing. When several limits are exhausted at once, the reset it shows is the latest of them, and unknown if any of them is unknown. Grok gives no reset time at all, so with Grok it’s always unknown.
Then recovery. Specs that were held back, Specs whose Runner ran dry, and Controller turns that hit a limit are all listed with their reset time (gov limited, or the Dashboard). From there I can resume now, or choose to resume at the reset. That second option is off by default, and gov auto-resume on makes it the default. A resume re-measures usage and checks the Limit again before it does anything. A held Spec gets a fresh copy of the project, a limited one continues in its own, and if the handoff changed in the meantime, it isn’t resumed by itself. A limited Controller turn is continued by me, or at its reset by the daemon with fixed text, only while the Dashboard is open.
The part I care about most is that nothing runs twice. “Resumed” is written down before anything starts, so a crash in the middle can’t cause a duplicate run. A sweep every 15 seconds finds what’s due, so there are no saved timers to go stale. Running Specs have their reserved usage written down before the Runner starts, so a crash can’t hide it, and if that record can’t be read, metered Runners are held instead of starting from zero.
The review rounds were full of small ways this could have gone wrong:
- A recovery choice only applies to the limit it was made on, so a stale choice is refused.
- A Spec the sweep resumes stops if no client that shows unattended work is left, and waits for me.
- A limit crossed while a Runner is working ends the Spec as resumable, instead of as a plain failure.
- Claude Code’s stall timer now waits while an approval is open and counts tool progress as activity.
- Settings saved by an older client keep the fields it doesn’t know about.
Where it actually stands
The first two features are done and reviewed, the limit recovery is done and reviewed, and the last commit today made the review refresh when a Spec gets a new snapshot. The AI crew did most of the typing (Codex implementing, Claude reviewing), and I decided what to build. I read the results, which is the whole point of the project.
What I haven’t done is run any of it live. The Dashboard screens for resuming and continuing haven’t been looked at in the installed app, because the installed app doesn’t have them yet. Next up is making Runners from other coding tools work through a common protocol, then a pass on the sandbox, which blocks and questions me far more than I’d like.
So that’s the report. Better memory, parallel jobs, and recovery from limits, all sitting on a branch I haven’t pushed. The real test is the first time it runs on my own machine, and I’ll tell you how that goes, whether it’s good or not.