团队维护了多个 Codex、Claude Code 订阅账号，新同事来了，要分配权限和 Key；模型突然调用失败，要查是哪一个账号出了问题；任务做到一半，还想知道订阅额度够不够用。

这些事情并不复杂，却常常需要离开客户端，切回后台逐项处理。

Zentrola 1.3.0 把其中一部分日常操作带进了 AI Coding 客户端：通过明确授权的 Access Key，用户可以借助 MCP 查询订阅额度、创建普通成员和签发 Virtual Key。后台首页也新增服务健康度，帮助管理员定位异常凭据。

先认识一下 Zentrola

Zentrola 是面向研发团队的开源 AI Coding 能力治理平台，部署在客户端与上游模型服务之间。研发人员继续使用 Codex、Claude Code 等熟悉的工具，团队统一管理模型接入、访问权限、密钥、Token 配额、用量和成本。

如果你已经在使用 Zentrola，本次升级最值得关注的是下面三项变化。

1. 在客户端里询问订阅额度

• 管理多份订阅时，知道“某个服务商还能用”往往不够。更实用的信息是：具体哪个账号接近限额，什么时候重置，当前数据是否可靠。

  在 1.3.0 中，具有后台管理权限的成员 Key 可以查询该成员能够路由到的全部订阅账号额度。无需预先指定模型，结果按账号分别返回。

  安装并配置好 Zentrola 插件后，可以在客户端中这样提问：

查看我能使用的所有订阅账号额度，列出额度状态、重置时间和最近检查时间。

这是自然语言请求示例，具体展示方式由客户端组织。

额度数据采用 5 分钟快照，超过该时间后按需刷新。Codex 订阅读取额度信息，不消耗推理额度；Claude 订阅通过一次输出 1 Token 的最小请求读取限额。

如果刷新失败、处于冷却中或等待超时，系统会保留旧快照并标记为 STALE；从未取得额度的账号返回 UNKNOWN。旧数据仍可参考，但不能当成最新结果。同一账号的并发查询共享一次刷新，避免反复访问上游。

• 这里需要区分两种“额度”： 上面查询的是上游订阅账号的限额；Zentrola 为成员、Group 设置的月度 Token 配额属于团队内部管控。普通成员也可以查询自身当月用量与个人额度，查询上游订阅额度则需要后台管理授权。

2. 新同事入组，直接通过 MCP 创建成员和 Key

新成员接入模型，通常需要创建成员、分配 Group、签发 Key，再启用账号。1.3.0 支持通过 MCP 完成这套流程。

管理员先为指定成员的 Access Key 开启“后台管理”权限。这个开关可以在签发时勾选，也可以之后在 Key 列表中调整。

配置好后，团队负责人可以提出这样的请求：

先查询可用分组，再创建普通成员“张三”，加入“研发组”，并签发首把 Key。

示例中的分组需已存在且处于启用状态。成员创建、分组分配、首把 Key 签发和启用会在同一个事务中提交，任一步失败都不会留下未配置完整的成员。

已有普通成员也可以通过 MCP 签发新 Key、停用或重新启用。停用会立即阻止该成员全部 Key 的认证，但不会注销 Key；重新启用后，仍有效的 Key 可恢复使用。为停用成员签发 Key 会被拒绝，不能借此绕过停用状态。

• 管理权限有明确范围： 获授权的 Key 不能创建管理员、为管理员签发 Key，也不能操作自身或其他持有管理授权的成员；新签发的 Key 不继承管理权限。这适合将日常成员管理交给团队负责人，同时保留管理员账号的权限边界。

3. 首页就能看到哪个凭据出了问题

服务商已启用，并不代表它下面的每份订阅、每把 API Key 都在正常工作。
1.3.0 将后台首页的“当前模型服务商”区域升级为“服务健康度”，按服务商和具体凭据展示可用、不可用、待验证状态。悬停状态点，可以查看原因和最近检查时间；支持主动检测的凭据，还可以按需重新检查。

• 图： 管理后台首页按凭据展示服务健康度，左上角显示当前后端版本。
  管理后台

  侧边栏现在也会显示实际运行的后端版本，方便升级后确认是否已经切换到 1.3.0。

这次升级适合谁

• 如果团队维护多份订阅、经常查询额度，或者需要频繁为成员分配 Virtual Key，1.3.0 的收益会比较直接：常用操作可以在客户端发起，异常排查也能细化到具体凭据。

  如果目前仅使用单个 API Key，服务健康度、运行版本展示，以及新用量记录关联 Access Key 的能力，也能为日常运维提供帮助。

老用户升级前，检查这三项

1. 成员是否重名。 新版本要求未删除成员名称全局唯一，比较时忽略首尾空白。若已有重名，相关迁移会失败且不修改数据，错误信息会提供定位 SQL；需先处理重名再重启。

2. 插件是否更新。 Codex、Claude Code 的 Zentrola 插件需升级到 0.4.2 或更高版本，否则无法识别新增的 STALE 状态。更新后重新打开客户端会话，让 MCP 服务重新加载。

3. Key 是否需要重新授权。 如果使用过此前的分离授权版本：原有成员管理授权会保留；仅有额度查看授权的 Key 会变为普通 Key，需要重新开启后台管理权限。

本次升级无需新增环境变量。数据库迁移及完整兼容性说明见变更记录。

Docker Compose 升级

先备份 PostgreSQL 数据库与配置，尤其要妥善保存 MASTER_KEY；丢失该密钥后，已有上游凭据将无法解密恢复。

使用仓库提供的 Compose 文件时，将 backend 和 web 两处应用镜像都固定为：

image: longjianghu/zentrola:1.3.0

• 随后执行：

docker compose pull backend web
docker compose up -d backend web

官方 Compose 配置会自动执行数据库迁移；自定义部署请确认迁移配置。启动后，检查日志、侧边栏版本号和服务健康度，再用获授权的 Key 验证 MCP 查询。

Zentrola 1.3.0 让“查额度、分配 Key、排查异常”更贴近团队实际使用 AI Coding 工具的流程。欢迎试用，也欢迎反馈你希望在客户端中完成的下一项日常管理操作。

• GitHub 项目

• 中文文档

• 问题反馈