A closed tab is not a cancellation receipt
A visitor sees the answer stop at eight seconds, but that observation covers only the browser. The WordPress handler, reverse proxy, outbound HTTP client, and model provider each have their own connection state. Until their timestamps are joined, the additional 33 seconds of generation cannot be assigned to a layer.
Select one request that can carry the investigation
Select one request with a browser-side abort and a provider usage record. Preserve its client trace ID, WordPress attempt ID, upstream request ID, model, final usage, and server logs. Avoid averaging many requests: cancellation defects are easiest to prove as a single causal chain.
Build the four-clock timeline
Normalize every timestamp to UTC and include millisecond precision where available. Mark request start, first streamed byte, browser abort signal, server disconnect detection, upstream cancellation attempt, upstream final byte, WordPress handler completion, and provider usage finalization.
Clock skew can reverse apparent causality. Record each host's clock source or estimate skew with a shared request event, then annotate corrected times rather than silently editing raw logs. If provider logs expose only second precision, retain that uncertainty in the conclusion.
| Clock | Observed event | Example | Evidence to retain |
|---|---|---|---|
| Browser | Abort or tab close | 00:00:08 | client trace and abort event |
| WordPress | Disconnect detected | 00:00:10 | attempt ID and connection status |
| Transport | Upstream socket closed | not observed | proxy/client cancellation log |
| Provider | Generation finalized | 00:00:41 | request ID and billed tokens |
Test whether cancellation propagates
Run a controlled long response and abort it at a known point. Verify separately whether JavaScript sends an abort, whether WordPress learns that the client disconnected, and whether the outbound provider request is cancelled. AbortController can stop a browser fetch, but it does not by itself prove that a remote computation has stopped.
Repeat the test without aborting to establish normal duration and tokens. Then repeat at three abort times. If provider usage remains near the control across all aborts, propagation is absent or ineffective; if usage falls with earlier aborts, quantify the savings and residual delay.
Choose a control the stack can actually enforce
Prefer upstream cancellation only when the provider and client library document it and the test proves it. Otherwise cap maximum output, shorten server timeouts carefully, or explicitly treat disconnected work as billable. A timeout that merely stops waiting can make customer latency look better while leaving cost unchanged.
Set the cost circuit breaker independently of cancellation. The product can govern supported WordPress attempts and configured limits, but it cannot retroactively stop provider work that has already escaped through an unsupported direct call. Document that boundary in the incident record.
Acceptance is a provider-side result
Close the defect only when an early browser abort produces a recorded upstream cancellation or a verified reduction in final provider usage. Also test the normal streaming path, server errors, and a second abort to ensure the repair does not leak workers or truncate ordinary answers.
Keep the completed timeline as the operating artifact: raw and corrected timestamps, request IDs, cancellation result, billed tokens, chosen control, and retest date. Link the Pro control page only after the reader can see which limit addresses the proven residual exposure.
Use the stream-abort timeline from “The visitor closed the tab, but streaming charges continued” on a real first installation. Download AI Cost Circuit Breaker for free, begin in Monitoring, and move to enforcement only after the expected signals and rollback are verified.