The closed tab that keeps billing: cancellation propagation is a spend control

The awkward part is that the naive version looks correct. The handler awaits a `fetch` to the model API with `stream: true`, hands `response.body` straight back with a `text/event-stream` content type, and tokens appear in the browser ^[9]. Nothing in that path holds any state about the client, so when the socket dies there is nothing on the server positioned to notice. The upstream call is a separate operation with its own lifecycle, and the vendor has no way of learning that the reader left ^[4].

The cost arithmetic is where this stops being a tidiness argument. The source's example is a generation abandoned after 500 tokens while the backend keeps paying for thousands more ^[2]. Take the low end of "thousands" and assume a 2,000-token remainder: 80 percent of that completion's output tokens are metered, billed, and delivered to nobody ^[1]. The meter runs on the vendor's side of connection two, which is the side your logs are least likely to be watching and the only side that shows up on the invoice.

The remedy in the walkthrough is one property. Hono exposes `c.req.raw.signal`, which aborts when the client connection terminates, and that signal goes directly into the upstream `fetch` ^[7]. `AbortController` is the platform mechanism underneath: the signal is passed into the operation, and any API that accepted it can terminate when `abort()` fires ^[6]. Node supports `AbortSignal` across its asynchronous APIs, streams and HTTP work included ^[5]. So the engineering is not building cancellation. It is remembering that two connections exist, that the browser owns one and you own the other ^[3], and that they stay unrelated until you join them.

There is a judgement call the source declines to make for you, and correctly. Alongside client disconnects it covers server-side timeouts and cases where you should not cancel at all ^[8]. Whether a half-finished answer still has value once the reader is gone depends on what you do with completions after they stream: if the tokens are being written somewhere reusable, finishing may be the cheaper branch, and if they are not, every token after the disconnect is pure loss. That decision belongs in the handler, not in the browser, which is the author's wider point about this being server-side work and a cost problem rather than only a correctness one ^[10].