工作原理

MasterOS 将控制平面（control plane：auth、组织、billing/ledger、模型目录、admin）与执行平面（execution plane：chat、模型网关、检索，以及——之后的——agent/workflow 运行时）分离开来。这种拆分的存在是为了让安全和扩展边界保持清晰，尽管目前两个平面都运行在同一个 API 服务中。

发送一条 chat 消息

1. 服务器解析你所在组织当前生效的 plan，并检查所请求的模型档位是否在其允许列表中——这一点在服务端强制执行，而不仅仅是在 UI 中隐藏起来。
2. 如果该消息是延续一个已有对话，所有权会在其他任何事情发生之前被检查——一个无效的、或属于另一个用户的 conversation id 会在触及任何 quota 之前被拒绝。
3. 一个 idempotency key（随每个 chat 请求一起发送）会被预留。使用相同 key 重试的请求永远不会重复计费或重复调用模型供应商；一个正在处理中的重复请求会被直接拒绝。
4. 在模型被调用之前，预估成本会先针对你的每日 quota 桶被预留（reserved）。
5. 用户的消息会被保存，模型逐个 token 流式返回其回复，而该回复会与其真实的 token 数量和成本一起被保存——作为一个原子数据库事务，因此一次崩溃永远不会导致一条已计费的消息缺少对应的 ledger 条目（反之亦然）。
6. quota 预留会被**结算（settled）**为真实成本（如果实际上没有产生任何计费，则会被全额释放），且 ledger 会被扣除相同的金额。

计费是一个 ledger——一系列贷记/借记条目——而绝不是一个被直接扣减的单一余额数字。正是这一点使得对一个中途失败的请求、一笔退款、或精确对账用户被收取了什么费用进行正确推理成为可能。

上传文件

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

一个在恶意软件扫描或文本提取阶段失败的文件会被标记为失败，且无法在 chat 中使用。权限过滤（你被允许看到哪些文件）发生在任何内容到达模型之前——这是一个安全边界，而不仅仅是一个搜索过滤器。