服务商故障，不应该打断员工手头的 AI 编程工作。请求需要自动转向可用服务商；故障恢复后，原服务商也应能重新参与选路。员工无需为此修改客户端配置。
为了保障工作连续性，公司会接入多个服务商。但备用线路带来了新的成本问题：正常情况下先使用哪一家？已购买的订阅账号如何分配？什么时候才使用按量计费的 API Key？公司需要让这些选择遵循统一规则，而不是等故障发生后临时决定。
Zentrola 1.2.0 为此加入了服务商优先级和会话级账号分流。
故障发生时，自动寻找可用线路
管理员可以为同一个逻辑模型配置多个服务商，并设置优先级。请求先使用优先级更高的服务商；如果该线路暂时不可用，Zentrola 会在请求允许安全重试时尝试后续可用线路，并让故障资源进入冷却。
冷却结束后，后续请求可以再次尝试原线路。探测成功，它就能重新参与选路。服务商的故障切换和恢复由 Zentrola 处理，员工继续使用原来的模型代号。
多个账号，按会话分流
选定服务商后，Zentrola 优先使用可用的订阅账号。不同的新会话可以分配到不同账号；同一会话的后续请求则尽量沿用已选账号。
如果绑定的账号不可用，对于允许安全重试的请求，系统可以切换到其他可用账号，并在请求成功后更新绑定。没有可用订阅账号时，再使用 API Key 作为后备资源。
-
这里的负载均衡发生在新会话之间： 让多个账号承接工作，同时保持已有会话的连续性。
把成本选择交给公司的接入策略
有了多条线路，公司可以结合采购和成本安排设置服务商优先级；有了多个账号，可以让已配置的订阅资源承接不同会话，并明确 API Key 的后备位置。
Zentrola 不会自动计算实时价格、选择最便宜的服务商。1.2.0 提供的是一套可配置、可执行的资源选择顺序：正常时按策略使用，故障时寻找可用线路，恢复后重新参与选路。