服务商故障，不应该打断员工手头的 AI 编程工作。请求需要自动转向可用服务商；故障恢复后，原服务商也应能重新参与选路。员工无需为此修改客户端配置。

为了保障工作连续性，公司会接入多个服务商。但备用线路带来了新的成本问题：正常情况下先使用哪一家？已购买的订阅账号如何分配？什么时候才使用按量计费的 API Key？公司需要让这些选择遵循统一规则，而不是等故障发生后临时决定。

Zentrola 1.2.0 为此加入了服务商优先级和会话级账号分流。

故障发生时，自动寻找可用线路

管理员可以为同一个逻辑模型配置多个服务商，并设置优先级。请求先使用优先级更高的服务商；如果该线路暂时不可用，Zentrola 会在请求允许安全重试时尝试后续可用线路，并让故障资源进入冷却。

冷却结束后，后续请求可以再次尝试原线路。探测成功，它就能重新参与选路。服务商的故障切换和恢复由 Zentrola 处理，员工继续使用原来的模型代号。

多个账号，按会话分流

选定服务商后，Zentrola 优先使用可用的订阅账号。不同的新会话可以分配到不同账号；同一会话的后续请求则尽量沿用已选账号。

如果绑定的账号不可用，对于允许安全重试的请求，系统可以切换到其他可用账号，并在请求成功后更新绑定。没有可用订阅账号时，再使用 API Key 作为后备资源。

• 这里的负载均衡发生在新会话之间： 让多个账号承接工作，同时保持已有会话的连续性。

把成本选择交给公司的接入策略

有了多条线路，公司可以结合采购和成本安排设置服务商优先级；有了多个账号，可以让已配置的订阅资源承接不同会话，并明确 API Key 的后备位置。

Zentrola 不会自动计算实时价格、选择最便宜的服务商。1.2.0 提供的是一套可配置、可执行的资源选择顺序：正常时按策略使用，故障时寻找可用线路，恢复后重新参与选路。

升级提示

• 1.2.0 包含数据库迁移 00054： 现有大于 100 的服务商优先级会调整为 100，更新后的取值范围为 1–100。生产环境升级前，建议检查现有优先级配置，并将 PostgreSQL 数据与当前 Master Key 一起备份。
  如果你的团队也在平衡 AI 编程服务的连续性与接入成本，欢迎试用 Zentrola 1.2.0，并分享你的使用场景。
  项目仓库 · 项目网站