Stopping a Coding Agent’s Token Stream: Billing Verdicts

§1 The stop button is not a billing receipt

You spot a coding agent rewriting the wrong module and interrupt its live reply. The terminal goes quiet, but did the bill stop growing? Stopping visible output and stopping upstream generation are different events. A client can stop displaying tokens while a server continues producing them.

This field-test protocol separates those events and gives clear verdicts for interpreting the results. It is reproducible, not a claim that specific providers were tested here. Exact charges depend on the provider, model, relay, and cancellation path.

§2 A three-run test for interrupted token streams

Use a disposable repository and one fixed prompt requesting a long code review without file changes or shell commands. Disable automatic retries and follow-up agent turns where possible. Keep the model, output limit, repository context, and other settings identical.

A streaming-capable model such as Claude Haiku 4.5 can serve as the example, provided your chosen endpoint supports it. Run each scenario several times: generation speed and cancellation timing vary, so one unusually fast response proves little.

• – Baseline run: Let the response finish and record the request identifier, elapsed time, final usage, and settled charge.
• – Display-stop run: Stop rendering after a fixed interval while deliberately leaving the network stream open and draining it in the background.
• – Abort run: At the same interval, invoke the SDK’s abort mechanism or close the response connection, then check whether the upstream request was actually canceled.

Record timestamps for the stop action and last received event. Compare your client log with provider or relay usage records after accounting settles. If interruption removes the final usage event, an empty local counter is missing evidence, not evidence of zero cost.

§3 Verdict: delivered context is not refunded

Interrupting output does not undo input processing already performed. A coding agent may submit your instructions, conversation history, repository excerpts, and tool definitions before the first visible answer token arrives. Billable input processing can therefore occur even when you stop almost immediately.

Cached input may have different pricing, and some services expose additional usage categories. Inspect the actual accounting rather than assuming every submitted token has the same rate. The useful comparison is settled usage for each run, not merely the number of characters printed.

§4 Verdict: hiding live replies does not stop generation

The display-stop run should not be treated as cancellation. If your application keeps consuming the SSE response, upstream generation can continue normally. Tokens discarded by the interface can still be billable.

This is a common architectural trap: the interface’s stop button changes local state but never reaches the request controller. A frozen terminal, closed panel, or detached subscriber likewise does not establish that the underlying request ended.

§5 Verdict: an abort can reduce output charges, not erase them

A propagated cancellation can prevent further generation, but it cannot retract work already done. Expect cancellation latency: tokens may already be generated, buffered, or in transit when you press stop. Client-visible token counts can therefore differ from billable output counts.

A disconnected SSE stream is a transport event, not universal proof of upstream cancellation. Check documented cancellation behavior and request-level accounting. Where applicable, separately billed reasoning or other processing may also make visible text an incomplete measure of cost.

§6 Verdict: agent tools need a separate stop path

Stopping one model response does not necessarily terminate a shell command, background test runner, or delegated task. Nor does it reverse completed file edits. Tool execution costs and later model requests are separate concerns.

For a meaningful agent-level stop, cancel the active request, prevent queued turns, and explicitly manage running tools. After interruption, verify that no automatic retry or resumed loop starts another billable request.

§7 Fluxio fits a streaming-first cancellation workflow

Fluxio is worth considering when you want a streaming-first, pay-per-token AI API relay with one key across multiple model families. It works with Claude Code, Codex, Gemini CLI, and OpenAI-style SDK clients. Those clients use https://api.fluxioapi.com/v1 as the API base.

Keep the same discipline through a relay: verify cancellation propagation, retain request identifiers, and reconcile settled usage. Streaming makes wasted work visible sooner; reliable cancellation is what can limit additional work.

Sign up for Fluxio.