平台总览

ttttt.ai 围绕四个核心对象组织一切：

组织 (Org)  ──┬──  成员 (Member)        — 谁能用
              ├──  API 密钥 (Key)       — 用什么身份发请求
              ├──  余额 (Wallet)        — 谁来付钱
              └──  用量 (Usage)         — 花了多少
                          │
                          ▼
                 网关 api.ttttt.ai
                          │
                          ▼
                 渠道 (Channel) ── 上游模型供应商

理解这张图，再去看 API、控制台、计费就都顺理成章。

组织 (Organization)

组织是计费、配额、用量的最小边界。 一个用户可以同时属于多个组织（个人玩具项目、公司账号、外包客户各开一个），切换组织就切换了：

• 谁来付钱（余额、发票抬头）
• 能调用哪些模型（密钥级 modelScope 限定的范围）
• 用量看板里看到的数据

新注册用户会自动创建一个默认组织，名为「《用户名》 的组织」，可以随时改名或转移所有权。

详见 组织与成员。

成员 (Member) 与角色

每个组织有三种角色：

权限模型是严格按角色 + 数据范围双重隔离：member 调用任何分析接口都会被强制 scope 到 self，看不到组织全局或其他成员的数据。

API 密钥 (Key)

密钥是访问网关的唯一身份凭证：

• 前缀固定为 owo-
• 长度 47 字符（前缀 + 43 字符密文）
• 创建后只完整展示一次，之后只能看到 owo-xxxx****xxxx 的脱敏形式
• 密钥归属到单个成员——不是组织共享，是该成员在该组织下的私钥
• 支持 RPM / TPM 限速、模型 scope 限制、过期时间、cost-center 标签
• 支持「轮换」（同名重发）与「停用」（软删除，立即对网关生效）

详见 API 密钥概念 与 密钥管理操作。

渠道 (Channel) 与路由

一个 model（如 gpt-5.5）在后端会路由到一个或多个渠道——也就是真正去执行请求的上游供应商。这意味着：

• 对外接口稳定：你只关心 model 字段，不关心背后是 OpenAI 官方、Azure 还是其他来源。
• 自动降级：上游 5xx / 超时会触发重试 + 切换到同型号的备用渠道。
• 审计可追：用量记录里保存了实际命中的渠道 ID，运营侧可以统计每条线路的成功率。

普通用户不感知渠道；运营会通过控制台调度优先级、暂停可疑渠道。

用量 (Usage) 与计费

每一次请求都会产生一条 usage 记录，包含：

请求 ID · 时间 · 模型 · 成员 · 密钥 · 客户端 ·
input_tokens / output_tokens / cache_read / cache_write ·
input_cost / output_cost / cache_cost · 上游耗时 · HTTP 状态码

记录写完后立即扣费——按 model_pricing 表里的单价乘以实际 token 数。 扣费按 Credit 桶优先级进行（赠金 → 奖励 → 充值），详见 计费模型。

控制面 vs 数据面

ttttt.ai 部署两条独立链路：

• 控制面（app.ttttt.ai）— Next.js Web 应用，处理认证、密钥管理、充值、用量查询、工单。
• 数据面（api.ttttt.ai）— Hono 网关，唯一的高频热路径，负责鉴权、限速、路由、扣费、记账。

这种分离让我们可以独立扩缩容数据面，控制面的发布不会影响在线推理流量。对你来说意味着：控制台偶尔抖动不会影响 API 调用。

接下来

• 准备发第一条请求？→ 快速开始
• 想理解密钥的细节？→ API 密钥
• 团队规模化部署？→ 组织与成员
• 评估单价与预算？→ 计费模型