The review process I wrote about last time answers a “what happens” question: when Claude hands work to DeepSeek, the review that follows is blind, evidence based, and enforced by a gate rather than good manners. What it doesn’t answer is “when.” A handoff that fires too early wastes a perfectly good working session. One that fires too late means Claude runs out of usage mid change, with nothing clean for DeepSeek to actually pick up. Getting the timing right turned out to be its own small project, and a more interesting one than I expected.

Why a fixed percentage, and not something cleverer

My first instinct was to make the trigger smart: estimate how much a task would cost before starting, size the checkpoint dynamically, that sort of thing. I talked myself out of it. A task’s real cost is genuinely hard to predict up front, and building a clever predictor is its own source of bugs. The simpler answer works better in practice: watch the actual usage percentage as it climbs, and hand off at a fixed point, eighty percent, while there’s still enough room left to write a clean, honest checkpoint rather than getting cut off mid thought.

Eighty leaves a real margin. Not so early that sessions end prematurely, not so late that there’s nothing left to describe what’s actually in progress. It’s a round number chosen on purpose, not tuned from data I don’t have yet. If it turns out to be wrong in either direction, it’s one number to change, not a model to retrain.

The part that almost became a much bigger build

Here’s where I nearly overcomplicated things. The obvious way to enforce an eighty percent rule is to build a program that runs its own coding session, watches its own spend, and hands off entirely on its own. I actually built that. It worked. It was also the wrong thing, and it took a fairly direct conversation with myself to see why.

The problem isn’t technical, it’s what the automation is actually for. Handing off code to another model is a real decision with real consequences if it goes wrong, and a script making that decision unsupervised is a meaningfully bigger thing to hand over than a script that just tells someone a number. So I scrapped the version that decided things, and kept only the version that watches.

What actually runs now

The final shape is small enough that I probably could have started here. A scheduled job checks in on the live build session every twenty minutes. Critically, it doesn’t ask the model anything new, it just reads whatever’s already rendered on screen, the same usage figure I’d see if I looked myself, so the check itself is close enough to free that I never have to think about its own cost. It writes that number to a small file.

During an actual build, checking in is now a single cheap read of that file rather than wrestling with a live terminal session, which used to be the fragile part. When the number crosses eighty percent, that’s the signal, not an automatic action: I say so, out loud, in the same conversation where the building has been happening. A checkpoint gets written to the pre agreed folder from the previous post, DeepSeek is told to continue, and depending on how much the task matters, a second independent model reviews DeepSeek’s changes purely for extra accountability. When usage resets and I’m back, I review the diff myself before anything counts as finished.

What I’d actually recommend

If you’re building something similar, resist the version that decides for you, even though it’s more satisfying to build and looks more impressive when it’s running. The genuinely useful part of automation here wasn’t removing the decision, it was making the information the decision depends on cheap and reliable to check. Once that part was solid, the actual decision took about one sentence to make each time it mattered.