Codex vs Claude

Interrupting an Agent: Almost Everything Is in the First Minute

David Guzenburg/ / 11 min read

Watch which files it opens. If they are the files you would have opened, stop watching and go do something else.

workflowsession designfeedback loopsdeveloper experience

The capability is trivial; the skill is knowing when

Every interactive agent lets you stop it. Press a key, the work halts, you say something different, it continues from there. As a feature this is unremarkable and takes ten seconds to learn.

As a practice it is one of the highest-leverage things you can get good at, and almost nobody treats it as a skill. The value of an interrupt is entirely a function of when it happens: at thirty seconds it costs nothing and saves an hour, at forty minutes it costs forty minutes and saves twenty. Same keystroke, wildly different economics.

Which means the useful question is not how to interrupt but how to recognise a wrong turn early — and the recognisable signals are almost all in the first minute, before any code has been written.

The opening moves tell you most of it

Before an agent changes anything, it orients: it searches for something, it opens some files, it reads. That sequence is a direct readout of its model of the problem, and it is available while the cost of being wrong is still zero.

If you asked for a change to session handling and the first three files it opens are the ones you would have opened, the model is right and you can stop watching. If it opens the HTTP layer, it has understood the problem differently from you, and thirty seconds of reading has just saved you the argument you would otherwise have at review.

This is the single most useful habit in this article: watch the opening moves, then leave. Not the whole session — the first minute, where the information density is highest and the correction is cheapest.

Four early tells

The wrong files. Covered above, and the strongest signal. It indicates a different mental model of where the behaviour lives, which means everything downstream will be built in the wrong place.

Search terms that are not yours. Searching for retry when your codebase calls it backoff means the agent has not found the existing implementation and is about to write a second one. Vocabulary mismatches are cheap to fix — tell it the word — and expensive to leave, because the outcome is a duplicate abstraction.

Reading too little. An agent that opens one file and starts editing on a task that clearly spans several has not established the context to do it correctly. The edit will be locally plausible and wrong at the boundaries.

Reading far too much. The opposite tell, and it usually means the request was ambiguous. An agent that opens twenty files on a narrow task is searching rather than working, because it does not know what you meant.

Say the file names

Most wrong-file starts are caused by a request that did not name a location. "Fix the retry logic" has to be located; "fix the retry logic in sync/backoff.ts" does not. Ten extra words removes the most common failure entirely.

The middle of a task is where interruption gets expensive

Once implementation is under way the calculation changes. There is now partial work in the tree, the agent's context contains a chain of decisions, and an interruption leaves you in a state that is neither the original nor the intended result.

That state is the real cost. A half-applied refactor across nine files is worse than either endpoint: the code does not compile, the diff is meaningless, and deciding whether to finish it or unwind it requires understanding what it was doing. Interrupting mid-flight is sometimes right and it is never free.

Interrupt between steps, not inside one

Where you have the choice, stop the agent at a boundary rather than during an operation. Between two files is better than halfway through one. After a test run is better than during it. After a commit is much better than before.

Agents that announce what they are about to do give you these boundaries for free, which is a good reason to ask for that narration on longer tasks. The stream is not for reading closely; it is for knowing when the safe stopping points are.

Know what state you are in before you say anything

The first thing to do after stopping something mid-task is to look at git status and the diff, not to type a correction. The agent's description of where it got to is a summary, and summaries are the part most likely to be optimistic about what completed.

Ten seconds of looking tells you whether you are correcting a direction or cleaning up a mess, and those need different next messages. It also stops the common failure where you redirect an agent that is holding a broken tree, and it carries the breakage into the new direction.

The correction that works

"No, stop" produces a stopped agent with no new information. It will try something else, and the something else is drawn from the same wrong model, so it is often wrong in a related way.

What works is naming the divergence: "stop — session state lives in auth/session.ts, not in the middleware; start there." One sentence, and it corrects the model rather than the action. The distinction matters because you will otherwise interrupt three times on variations of the same misunderstanding.

The general principle: an interrupt should transfer the piece of knowledge that was missing. If you cannot articulate what that is, you may be reacting to unfamiliarity rather than to an error, which is worth checking before spending the interruption.

Redirect or restart

After a substantial wrong turn, continuing the session is often worse than starting a new one. The context now contains the failed approach, the files it read for the wrong reason, and the reasoning that led there, all of which continues to influence what comes next.

A fresh session with a better prompt — incorporating what you just learned about how the request was misread — is frequently faster and produces cleaner work. The heuristic I use: if the correction is a fact, redirect; if the correction is the whole approach, restart.

The sunk cost trap is real here

Forty minutes of work exists. It is wrong, and it is also substantial, and there is a strong pull toward salvaging it: keep the parts that look fine, adjust the rest, avoid throwing away something that took time.

That instinct is usually wrong with agent output specifically, because the time was not yours. Forty minutes of agent work took forty minutes of wall clock and perhaps five of your attention. Regenerating it correctly costs another forty minutes of wall clock, which you can spend doing something else. The economics that make salvage rational for human work do not transfer.

Sometimes let it fail

Not every wrong turn should be interrupted. If the agent is heading toward something you believe will not work but are not certain about, letting it arrive at the failure produces information — both for you and in the session's context, where the failed attempt becomes a reason not to try it again.

This is especially true when your objection is intuitive rather than articulable. An interrupt based on a feeling transfers no knowledge, and you may be wrong. Letting it run to a concrete failure converts your intuition into evidence, at the cost of a few minutes of compute.

Every interruption is feedback about your prompt

The most valuable thing to do after stopping an agent is to ask why it went that way, because the answer is nearly always in your request rather than in the model.

An ambiguous noun. A location left unstated. A constraint you knew and did not write. A term your codebase uses differently from the rest of the world. Each interruption points at one of these, and fixing the pattern removes a whole class of future interruptions rather than one instance.

Teams that track this informally end up with much better prompts within a few weeks, and the improvement shows up as fewer interruptions, which is the outcome you actually wanted.

Interrupting is not the same as course-correcting a person

Worth saying because the social instinct interferes. Stopping a colleague mid-sentence is rude, and that reluctance transfers: people let an agent finish out of a vestigial politeness, then correct the finished work.

There is nothing to be tactful about. An interrupt at second thirty is strictly better for everyone than a rewrite at minute forty, and the only cost of a wrong interrupt is a few seconds. If you notice yourself waiting for a natural pause, that is a habit worth discarding deliberately.

What to do when you cannot watch

The whole practice assumes you are present for the opening. When you are not — because the task is running unattended — the equivalent control is the plan: ask for the approach and the file list before any work happens, and read that instead of the opening moves.

It is the same information in a different form, delivered at the same cheap moment, and it is why the two practices pair well. Watching the first minute and reading a plan are both ways of buying a veto before the expensive part, which is the argument in plan mode as a cheap veto.

Interruption is a design affordance, not a safety net

A closing distinction. Being able to stop an agent is not a substitute for constraining what it can do — an interrupt requires you to be watching, and anything that depends on human attention is not a control, for the reasons set out in approval fatigue.

Its actual role is to make cheap correction possible during work you have chosen to supervise. That is a productivity mechanism rather than a safety one, and treating it as safety leads to supervising work that should have been constrained instead.

The habit, in one line

Watch the first minute. Check the files it opens against the files you would have opened. If they match, stop watching and do something else. If they do not, interrupt immediately and say what it missed.

That is thirty seconds of attention per task, it catches the majority of wrong turns at the point where correction is free, and it is compatible with not supervising the rest. The alternative — watching everything, or watching nothing — is either expensive or blind, and the first minute is where nearly all of the recoverable information is.

A note on the pause you cannot take back

One asymmetry worth keeping in mind: some actions cannot be interrupted usefully because they complete faster than you can react. A command that pushes, deploys, migrates or deletes is finished before the keystroke lands.

For that class, the interrupt is not the control and never was — the control is the denial rule that stops it being attempted. Interruption governs the slow, visible, multi-step work where you have seconds to react, which is most of what an agent does and is emphatically not all of it.

Finally, notice that this whole practice only pays off if you actually leave. Watching the first minute and then continuing to watch is just supervision with extra steps, and it is the easy thing to do because the stream is right there and mildly interesting. The discipline is the second half: having checked the opening moves, close the window and go and do something that needs you.

Takeaway

An interrupt at thirty seconds costs nothing and saves an hour; at forty minutes it costs the forty minutes. The recognisable signals are almost all in the opening moves — which files it opens, what terms it searches for, whether it reads too little or far too much — so watch the first minute and then leave. Correct by naming what it missed rather than saying stop, check git status before redirecting mid-task, restart rather than salvage when the whole approach was wrong, and treat every interruption as information about your prompt.

Keep reading
Codex vs Claude

Pairing With an Agent: Granularity Is the Whole Game

A check-in is valuable before a commitment and a tax during implementation. Where the real decision points are, the sentence that fixes ambiguous cases, and why the most useful conversation usually happens at the end.

Codex vs Claude

Long-Horizon Runs: The Loop Cannot Tell Progress From Motion

A multi-hour agent run does not stop when it stops making progress. Why activity metrics rise fastest during a failing search, the degenerate solution to make the tests pass, checkpointing, budgets with defined exits, and compaction as a source of drift.

Codex vs Claude

Local Machine or Managed Container: The Difference That Actually Survives

Claude Code runs locally and Codex runs in the cloud is the first thing every comparison says, and it stopped being true. What each product treats as home, and what home costs you.

Codex vs Claude

Plan Mode Is a Cheap Veto, Not a Design Document

The mechanical value of planning before implementation is moving the moment you can say no. What a plan should contain, why the assumptions list matters most, and why an unread plan is worse than no plan at all.

← The Favicon Set Is Four Files: Cutting the Package an Agent Gives You  ·  What the Agent Inherits: Sessions You Are Already Logged Into →

All codex vs claude articles  ·  Every article