星桥 API
模型名明明写对了，Base URL 也能打开，怎么换了一个令牌，结果就开始报“模型不可用”？
先给结论：网关里的 Auto，和客户端里的 Auto，不是一回事。 一个按候选分组选择线路；另一个是客户端自己的选模功能，甚至不一定使用你填写的第三方密钥。都叫 Auto，凑一块儿就容易把人整迷糊。
这篇只解释这两个概念怎么配合。依据是星桥 API 使用文档（核对日期：2026-11-01），没有把本文当作某个具体模型的实测报告；实际可用模型、分组和计费仍以后台当前显示及使用日志为准。
图：两个独立配置，不表示固定执行顺序。底图由星桥 API 生成，文字为后期排版；客户端 Auto 是否使用自带密钥须查对应工具说明。
第一层：令牌分组里的 Auto
创建或编辑令牌时，分组决定这枚令牌可以走哪一组渠道。选择具体分组，相当于把可用范围写得更窄；选择 Auto，则由网关在这枚令牌允许的候选分组里按规则寻找可用路径。
这里有三个边界，得先记住：
- Auto 不等于所有分组都自动开放。
- Auto 不等于一定命中价格最低的分组。
- 真正命中哪一组，和那一组的模型、渠道及计费规则有关。
所以，“我选了 Auto，咋还没有这个模型？”并不奇怪。Auto 是路由策略，不是权限扩张按钮。要是令牌本来就没被授权某个分组，换个写法也不会凭空多出通行证。
第二层：客户端里的 Auto 模型
有些客户端的模型菜单也有 Auto。它按该工具自己的规则选择模型，不等于给请求里的 model 原样填入 auto，也不保证使用你配置的第三方网关。
先拆成两个问题看：
- 客户端：最终使用哪个提供商、哪个模型？请求有没有到星桥？
- 网关：请求到达后，这枚令牌配置了哪些候选组，哪些组能处理这个模型？
星桥文档在 Cursor 配置中明确提醒：不要用 Auto 模式来判断是否走了星桥。先明确选中已配置的服务商和模型，发一句短消息，再到使用日志对照时间、模型和分组。没有消耗记录时，还要区分“走了别家”和“网络或鉴权阶段就失败”，不能直接下结论。
图：排查路线示意，不是网关内部实现图。先确认提供商和模型，再查分组、端点和日志。底图由星桥 API 生成，标签后期排版。
两个常见场景
场景一：客户端选具体模型，令牌分组选 Auto。
客户端请求里明确写了模型 ID，网关再在令牌允许的候选组中寻找能处理它的路径。此时失败，优先核对：模型 ID 是否准确、候选分组是否包含它、该分组是否支持当前接口。
场景二：客户端和令牌都选 Auto。
这时最容易混淆的是：客户端到底有没有把请求交给你配置的网关。不要拿“两边都 Auto”作为首次接入的验收办法。先在客户端明确选择服务商和一个真实模型 ID，令牌也先选支持它的具体组；这条固定路径跑通后，再单独测试网关 Auto。
举个假设例子：模型价格页在甲组能找到某个模型，但你的 Auto 候选只有乙组。两边填着同一个模型名，也不代表乙组就能接。应核对乙组是否支持这个模型和端点；不能因为甲组页面里看见了它，就认为 Auto 一定能找到。
报错时按这个顺序看
先看客户端最终发出的 model 字段和请求路径，再看令牌的分组设置，最后对照服务端使用日志里的命中分组。不要只盯着一句“模型不可用”。
如果是 401，先查令牌是否有效；如果是 404，看路径和协议端点；如果是模型相关错误，再核对模型 ID、分组权限和接口支持。状态码只是线索，错误正文和日志才是定位依据。
还有一个容易踩的坑：客户端 Auto 能选模型，不代表网关 Auto 会替你承担所有兼容性。 Chat Completions、Responses、Messages 这些接口不是同一个端点；模型在某个端点可用，也不代表另一个端点一定可用。
最小验证办法
- 先固定一个明确的模型 ID，不用 Auto。
- 首次接入先选支持该模型与端点的具体分组，别边测边改。
- 发一条不含隐私的短请求，保存时间、模型 ID、状态码和脱敏错误正文。
- 对照使用日志，确认实际命中分组与计费记录。
- 只改一个变量，再重试一次。
固定路径跑通后，再单独开启网关 Auto，核对实际命中组及费用。客户端 Auto 则另查对应版本的说明和实际请求。这样出了问题，至少知道是“选模”变了，还是“路由”变了，不至于在后台来回点，最后连哪一下碰巧好使都说不清。
星桥 API 网关由我们运营。需要统一核对令牌分组、模型 ID 和接口路径时，可从文末「阅读原文」进入星桥接入文档；本文没有承诺某个分组一定有某个模型，也没有把文档说明写成星桥实测结果。
资料：星桥 API《使用文档》“分组与令牌路由”章节。核对日期：2026-11-01。