One task, six steps, at most one call on your allowance.
Grace is a terminal agent. You give it a task in a repository you are already working in. What follows is fixed, not improvised — and the part that spends your allowance sits at the end of a condition, not in the middle of a loop.
- 01
Grace reads and plans — on your machine
The local model works out what the task touches and what a change would have to satisfy. Nothing leaves the machine for this.
- 02
Can the local model write this one?
Two answers send the step to Claude before anything is written: the plan is too uncertain to write blindly, or this kind of task is one the local model is measurably weak at.
- 03
The change gets written
Locally in the ordinary case. For the one step that needed it, by Claude — with the plan and the named places, not the whole repository.
- 04
Verification runs the project’s own checks
typecheck, lint, test, build — whatever the project actually has, executed against the change. A model’s opinion is not admitted as evidence here.
Then one of three, and only one of them means done:
- VERIFIED_PASS A check ran and passed. Only this state may be reported as done.
- VERIFIED_FAIL A check ran and did not pass. The change is not accepted — the work continues, and a failed local attempt is one of the reasons a step goes to Claude.
- NOT_VERIFIED Nothing executable could prove this change. Grace says so instead of claiming success.
- Plan
The task is turned into a plan the tooling can hold
The plan names the objective, the files to read, the files to modify, the expected effects and the checks that will run. The check names come from a fixed list — typecheck, lint, test, build — so a plan can never ask for a command the policy layer would refuse afterwards.
- Isolate
Work happens in an isolated copy
Before anything is written, Grace picks an isolation mode and with it a rollback path: a git branch, a git worktree, or a file backup. That promise exists before the first edit, not after a failure.
- Edit
The local model writes the change
The reading, the planning and the writing run on your machine. Nothing about this step needs a frontier model, and in the common case none is called.
- Verify
The project's own checks run against the change
Grace does not invent a test suite. It runs what the project already declares — and it distinguishes between a target that was not found, a change with no effect, a condition already satisfied, and a change that is actually verified. Those are four different outcomes, and only the last one counts.
- Escalate
Claude is called for a step — for one of four reasons
Two of the four reasons happen after a local attempt: it did not hold, or the repair loop is going in circles. The other two happen before anything is written: the plan was too uncertain to write blindly, or this kind of task is one the local model is measurably weak at. Claude gets the plan and the named places — not the repository — and verification runs again on its result. The call is billed to the Claude Code subscription you already have.
- Report
The state decides what Grace is allowed to say
Only VERIFIED_PASS may be reported as done. VERIFIED_FAIL and NOT_VERIFIED cannot become a success, no matter what the model claims about its own work.
The same run, in the terminal
One failed check, one escalation, one verified result.
State names, check names and the effect ladder are taken from Grace's source.
What runs where
| Step | Local machine | Frontier model |
|---|---|---|
| Reading the repository | yes | no |
| Planning the task | yes | no |
| Writing the change | yes | only after escalation |
| Running checks | yes | no |
| Deciding the outcome | yes | no |
The outcome is decided by the checks, not by a model — including when the frontier model wrote the change.