Codex instant_interrupt mid jobs_wait: Sume jobs keep running

Codex's opt-in instant_interrupt lets new input steer a running turn. A Sume job submitted earlier keeps running and billing; re-read it with jobs_wait.

4 min readSume
All posts

Interrupting Codex does not cancel a Sume job. A job is a server-side record with its own id, and Sume's docs say remaining jobs continue and still bill. After you steer Codex, have it call jobs_wait again with the same ids; never resubmit the paid create.

The Codex line is from its release notes; job behavior is from Sume's Jobs and results, read 2026-09-30.

What is instant_interrupt?

The Codex release notes (rust-v0.159.0) describe it as opt-in: it "lets new input steer Codex during model responses or long-running code-mode calls". The notes do not say how an MCP tool call in flight is handled, so this post makes no claim about that part.

What does a Sume wait actually hold?

A jobs_wait call is one HTTP request, held at most 55 seconds (default 50). When the slice ends with wait_slice_expired, the docs say to retry jobs_wait with the same ids. That retry pattern is also the safe response to any interruption.

Wait and job behavior from the Sume docs, read 2026-09-30
SituationWhat the docs say
Slice endsRetry jobs_wait with the same ids
Resubmitting the createNever; it is a paid call
wait_for: "any" returnsRemaining jobs continue and still bill
Stop a job you no longer wantjobs_cancel, a write tool needing idempotency_key

What should I tell Codex after an interrupt?

Keep the job ids in the conversation and say so in your steering message: "wait on these ids; do not submit again". For a fan-out, one batch jobs_wait with job_ids (1 to 20) beats several single waits. See MCP jobs_wait for long video jobs.

How do I stop spend instead?

Cancel with jobs_cancel. It is a write tool, so an OAuth session needs mcp:write, or use an API key. Read-only sessions get insufficient_scope.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume