Gumloop v10.29.0 发布 Model Router，把"模型选择"这个专业负担从用户转移给平台。这是继 v10.15 AI Model Governance / BYOK（模型治理的"准入面"）之后，模型治理的"运营面"补全——模型从"用户要自己管理的配置"变成"平台可运营的资源"。
| 层 | 机制 | 说明 |
|---|---|---|
| 复杂度评估 | 每条消息评估任务复杂度与所需推理量 | 据此选模型和推理 effort |
| 双档路由 | 简单任务跑 open-weight，复杂任务调 frontier | 推理 effort 匹配任务 |
| mid-run 升级 | 任务实际更难时中途换更强模型 | 不被首次选择锁死 |
内部支持 agent 从 $67K/月 降至 $7K/月（89% 降幅），同等工作量、输出质量无差异。
| 竞品 | 功能/行为 | 优势 | 劣势 | 洞察/机会 |
|---|---|---|---|---|
| OpenRouter Auto | API 层自动路由到 open-weight/frontier | 模型选择空间大 | 仅启动时定档，无 mid-run 升级；面向开发者 | 静态路由，抄起来容易 |
| OpenAI GPT-6 Astra | 单模型 + 内部 reasoning effort | 模型能力最强 | 无跨厂商路由，成本无优化空间 | 单模型谈不上"路由" |
| Anthropic Claude | 模型族 + reasoning effort 手动档 | 质量天花板高 | 用户仍需手动选模型/effort | 手动档仍是"专家税" |
| 通用 agent 平台 | 默认单一默认模型 | 简单 | 无一刀切最优解 | Model Router 是差异化 |
多数路由方案是"启动时定档"，Gumloop 的增量是 mid-run 升级——这要求路由器和 agent 运行时深度耦合，不是 API 层静态路由能做的。这是 OpenRouter 等 API 层路由做不到、而 agent 平台层能做好的壁垒。
| 档位 | 模型示例 | 适用 |
|---|---|---|
| Open-weight | DeepSeek V4 Flash、GLM-5.3-Flash | 简单重复任务（日报/分诊/摘要） |
| Frontier | Grok 4.6、Claude Opus 5、GPT-6 Astra | 复杂任务（深度分析、多步推理） |
v10.30.0 把 Auto 背后的路由器开放为公开端点 POST /models/route，让平台外的自有代码也能复用 Gumloop 的路由判断。
关键发现：路由器内部代号是 Chew。 官方描述为 "Gumloop Chew — the model router behind Auto"；响应里 router 恒为 gumloop-chew，真正选中的模型在 route.model。Chew 是路由器而非模型——这一点在 API 契约里被明确固定下来。
这个端点只返回决策，不执行模型。 它不运行选中模型、也不跑 fallback；路由判断本身消耗 credits，且受调用方模型权限约束。
| 参数 | 必填 | 说明 |
|---|---|---|
input | ✅ | 要路由的消息。别名 message。字符串，或 {type: text, text: ...} 的 parts 数组 |
models | — | 候选模型 ID，1–50 个、去重、须已注册。省略则用 Chew 的 lane-chain 并集（而非调用方可用的全部模型） |
history | — | 最多 20 轮历史，由旧到新，含 role（user/assistant）/ content / model |
agent | — | 可选上下文：name / description / system_prompt（≤ 20000 字符）。上下文越锐利，路由越准 |
team_id | — | 把模型可用性与 credits 归属限定到调用方所属团队。须为真实团队成员（即便同组织）；个人 API key 与 OAuth 均支持，非 team-key-only |
| 字段 | 含义 |
|---|---|
router | 恒为 gumloop-chew |
route.model | Chew 选中的模型 |
route.lane | 选中模型的能力档位：micro / light / standard / plus / max |
route.verdict_lane | 判断出的需求档位（未经调整前） |
route.adjustment | escalated / downgraded / null —— 这就是"mid-run 升级"的数据表达 |
route.reasoning_effort | 匹配任务的推理 effort |
route.fallback_models | 按序可试的备选模型，排除受限候选 |
route.fail_closed | 路由未能完成时是否使用了安全兜底 |
candidates | 全部被考虑的候选（含 status: "restricted" 者；受限者只上报、不被选中、不进 fallback） |
v1.0 基于博客把机制概括为"双档路由"（open-weight vs frontier）。API 文档揭示了更细的真实结构：
micro / light / standard / plus / max。博客的"双档"是面向用户的简化叙事，工程实现是五档能力 lane。verdict_lane（判断需求的档位），再决定是否 adjustment（escalated / downgraded），最后得 lane（实际执行档）。"mid-run 升级"在数据模型上就是 adjustment: escalated。fail_closed 字段表明路由未能完成时平台选择降级到安全默认，而不是崩溃或越权选模型。这与 v10.22 治理 fail-closed 化、v10.23 Salesforce 记录级权限属同一套哲学：不确定时选择可预测的保守行为。为什么这套三段式（判定档 → 调整 → 定档）值得借鉴：它比"直接选模型"更容易解释（可以告诉用户"我判断你需要 standard，但发现实际更难所以升到 plus"）、更容易调参（判定与调整是两个独立可调的策略）、也更容易向用户交代理由。
用户画像： 张伟，35 岁，某 SaaS 公司运营负责人，管着一个每天跑大量例行任务（日报、分诊、摘要）的客服 agent。
用户故事： 作为 agent 所有者，我希望把 agent 设为 Auto 模式后，例行任务自动降档到 open-weight 模型省 89% 成本，而遇到复杂问题（如投诉分析）时又不会牺牲质量。
验收标准：
用户画像： 李娜，28 岁，市场专员，用 agent 做内容生成和数据整理，对模型型号一无所知。
用户故事： 作为非技术用户，我希望不研究模型型号，agent 也能自动选对的模型，我只需要专注业务。
用户画像： 王强，40 岁，分析师，跑一个先易后难的长任务（先抓数据、后做复杂归因）。
用户故事： 作为分析师，我希望长任务开始时用便宜模型，中途发现需要更强推理时自动升级，而不是全程用最贵模型。
┌─────────────────────────────────────────────────────────────┐ │ Agent Settings → Model Picker │ ├─────────────────────────────────────────────────────────────┤ │ │ │ ┌─ 模型选择 ──────────────────────────────────────────┐ │ │ │ [Auto] ← 选 Auto 并设为默认 │ │ │ │ ────────────────────────────────────────────── │ │ │ │ 其他模型（手动覆盖时用）： │ │ │ │ · Claude Opus 5 / GPT-6 Astra / Grok 4.6 │ │ │ │ · DeepSeek V4 Flash / GLM-5.3-Flash │ │ │ │ ────────────────────────────────────────────── │ │ │ │ 推理开关 + effort/speed 控制（沉到底部） │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ 💡 Auto 可用作默认模型 │ │ 💡 模型选择器退化为"偶尔覆盖"的次要入口 │ └─────────────────────────────────────────────────────────────┘
| 漏斗阶段 | 事件名称 | 触发条件 | 指标/KPI | 优先级 |
|---|---|---|---|---|
| 采用 | `auto_mode_enabled` | 用户选 Auto 并设为默认 | Auto 采用率 | P0 |
| 使用 | `router_complexity_assessed` | 每条消息完成复杂度评估 | 评估覆盖率 | P0 |
| 使用 | `router_open_weight_routed` | 任务路由到 open-weight 模型 | 降档占比 | P0 |
| 使用 | `router_frontier_routed` | 任务路由到 frontier 模型 | 升档占比 | P0 |
| 质量 | `router_mid_run_upgrade` | 运行中换更强模型 | 升级触发率 | P1 |
| 成本 | `router_cost_delta` | 单任务成本对比手动选模型 | 成本降幅 | P0 |
| 质量 | `router_quality_regression` | Auto 输出质量回归检测 | 质量回归率 | P1 |
| 阶段 | 时间线 | 里程碑 | 状态 |
|---|---|---|---|
| Phase 1 — Auto 路由 | v10.29.0 | 复杂度评估 + 双档路由 + mid-run 升级 | ✅ 已发布 |
| Phase 2 — 路由器即 API | v10.30.0 | POST /models/route 开放给 API / SDK / CLI，暴露 lane / adjustment / fail_closed |
✅ 已发布 |
| Phase 3 — 成本透明化 | v11.x | Auto 路由决策可解释（为何选这个模型）+ 节省可视化 | 🔶 部分（API 已返回 reasoning 与 lane，产品内可视化未跟进） |
| Phase 4 — 动态模型编排 | v11.x+ | 按子任务/上下文窗口段切换模型，向 proactive 场景（Gumball Daily Chew/Meeting Prep）扩展 | ⬜ 探索中 |
POST /models/route 让它变成可被第三方验证和依赖的接口。第三方一旦在自己的代码里依赖 Chew 的 lane 判断，迁移成本产生粘性——这是把内部能力转化为生态壁垒的典型路径fail_closed 是可审计决策的最小成本做法：任何"平台替用户做决策"的能力都应在响应里显式告诉调用方这次决策是否为降级兜底的结果。把"黑盒智能"变成"可审计决策"，只需一个布尔字段由 Claude spec-generate 系统生成 · 来源：Gumloop Model Router 官方博客 · 博客全文存档：gumloop-docs_model-router.md（2026-09-17 抓取） · API 文档存档：gumloop-docs_route-model-api.md（2026-09-20 抓取，v10.30.0）