仕組み

MasterOSは、control plane(認証、組織、billing/ledger、モデルカタログ、管理)とexecution plane(チャット、モデルゲートウェイ、retrieval、そして今後はagent/workflowランタイム)を分離しています。この分離は、今日は両方のプレーンが単一のAPIサービス内で動作しているとしても、セキュリティとスケーリングの境界を明確に保つために存在します。

チャットメッセージの送信

1. サーバーは組織の有効なプランを解決し、リクエストされたモデル階層がその許可リストに含まれているかを確認します——これはUIで隠されているだけでなく、サーバー側で強制されます。
2. メッセージが既存の会話を継続するものである場合、他の何よりも先に所有権が確認されます——無効な、または他のユーザーの会話IDは、quotaに触れる前に拒否されます。
3. idempotency key(すべてのチャットリクエストと共に送信される)が予約されます。同じキーで再試行されたリクエストが、二重に課金されたり、モデルプロバイダーを再度呼び出したりすることは決してありません。処理中の重複リクエストは即座に拒否されます。
4. 見積もりコストは、モデルが呼び出される前に、1日のquotaバケットに対して予約されます。
5. ユーザーのメッセージが保存され、モデルはその返信をトークンごとにストリーミングし、返信は実際のトークン数とコストと共に——単一のアトミックなデータベーストランザクションとして——保存されます。これにより、クラッシュが発生しても、課金されたメッセージに対応するledgerエントリがない(あるいはその逆の)状態になることは決してありません。
6. quotaの予約は実際のコストに決済され(実際には何も課金されなかった場合は全額解放されます)、ledgerは同額だけ引き落とされます。

Billingはledger——貸方/借方エントリの連続——であり、直接減算される単一の残高数値では決してありません。これにより、途中で失敗したリクエスト、返金、あるいはユーザーが正確に何に対して課金されたかの照合について、正しく推論することが可能になります。

ファイルのアップロード

Upload → validate type/size → malware scan → store → extract text → available for citation in chat

マルウェアスキャンまたはテキスト抽出に失敗したファイルは、失敗としてマークされ、チャットで使用できません。権限フィルタリング(どのファイルを見ることが許可されているか)は、コンテンツがモデルに到達する前に行われます——これは単なる検索フィルタではなく、セキュリティ境界です。