Does moving status polling into a local runner eliminate every model turn during waiting? The actual workflow still had an outer layer: how the tool waited for that process. This follows my earlier local-wait article by separating internal polling from resumptions of model reasoning around the tool.
The runner already owned its internal repetition
Mcp-plugin-runner starts existing work or resumes its recorded ID, reads running/queued status, and returns when a terminal result arrives. It does not ask a model to decide the next read each time. Its timer and status calls are local program repetition.
However, an outer code tool can wait briefly, return control to the model, and require another model turn to request the next wait. Zero model calls inside the plugin therefore leaves possible outer model requests. Counting local status reads separately from outer resumptions exposes that second layer; treating both as a single polling count would hide the remaining cost.
Continue bounded waits inside the same tool execution
The historical final run waited for process termination within one code-tool execution, using individual process waits no longer than twenty seconds. The whole run lasted about 117 seconds. That environment let tool code perform another bounded wait without asking the model to reason about each unchanged status.
The tool lifetime recorded there belongs to that historical environment, not a universal numeric setting for every current execution tool. The host's actual limits and delivery of user cancellation still apply. Progress notifications can remain visible without making each notification a mandatory new model decision. The design separates responsiveness from repeated reasoning over an unchanged task. Dependent publication or input changes must still wait for confirmed process termination.
A process handle differs from a business run ID
The outer process session handle identifies the runner being awaited; the plugin runId identifies the business result being read. Starting a replacement runner merely because output is temporarily quiet can duplicate both layers. First inspect the same live process and the already-recorded business ID.
The original runner stops uncertain intent-without-ID state rather than dispatching again, and reused completion receipts are not described as fresh server verification. Combining outer waits must preserve those protections. Process termination alone also cannot replace the service-specific result checks performed inside the workflow. Waiting efficiently still requires knowing which completed object each layer reports.
Fifty-eight status responses can coexist with one model request
The final historical record distinguishes fifty-eight status responses processed by the program from fifty-nine local status requests including context rechecks. The outer model request count was one. Polling did not disappear; its owner changed. Without that explanation, a compact output could misleadingly appear to mean less verification.
The final plugin verified a new private result, while earlier manually recovered attempts remained separate. I disclose no account, manuscript or video identifiers here. These are relationships in a historical execution record, not a fresh publication or upload performed to reproduce this article. The distinction makes the reduced conversation compatible with preserved service checks.
The final summary points to execution and usage separately
A compact summary needs status, verification, internal model-call count and replay protection, while detailed evidence remains available in result files. Keeping a full log out of model context differs from discarding it. A failure requiring more detail can open its relevant receipt narrowly rather than replaying the whole history.
The linked usage ledger demonstrates how to record these outer-execution units; it runs no process and performs no wait. I retain separate observations for local polling, the tool's wait, model usage and service completion. Optimizing one layer should not imply that every surrounding layer becomes free or that the business result needs fewer checks.