penta2himajin/qwisp は、Apple Silicon で Qwen3.6-35B-A3B をローカル推論するサーバと CLI です。MoE（混合専門家：条件に合う一部のモジュールだけを有効化して計算量を減らす構造）を、MLX 上で動く Metal デコーディングエンジン Seedless で実行し、リクエスト形式は OpenAI API と互換性があります。2026年10月6日にリポジトリに入ったコミット 05e745b はこの互換性の穴を埋めました。ストリーミングリクエストで stream_options の include_usage を true にすると、今や [DONE] を送る直前の最後のチャンクに usage オブジェクトが載って送られます。
これまで usage 情報は非ストリーミング応答にのみ含まれており、ストリーミングで受け取るクライアントは completion_tokens=0 をそのまま受け取る必要がありました。ストリーミング応答は SSE（Server-Sent Events、サーバーがテキストイベントを順を追って送る形式）で届くためです。サーバーは [DONE] を送る直前に choices が空のチャンクをもうひとつ流しきり送り、そこに prompt_tokens、completion_tokens、total_tokens だけを含めます。値はエンジンが数えているプロンプトと生成トークンIDの個数から得られます。同じコミットでリクエスト構造体に StreamOptions が追加され、それまで JSON デコード段階で未知のキーとして捨てられていた stream_options が保持されるようになりました。セルフテストにもその往復を確認する1行が追加されました。
ただし根拠はこのコミットひとつに限られます。変更は swift/Sources/qwisp 配下の3ファイルにまたがる24行の追加のみで、削除はありません。使用量の数値はサーバ自身のトークンカウントをそのまま出力する構造なので、別のカウンターと突き合わせた数値ではありません。リリースタグ、デプロイ形態、性能測定値は今回の記録には示されていないため、他のクライアントとの互換性の幅や速度への影響は判断が早い段階です。目立つ改善点がひとつあります。OpenAI 仕様のストリーミングクライアントを接続して使う側なら、使用量の集計が0から実際の値に変わることは確かです。