路由 | JoyToken | Documentation

每个请求都由 JoyToken 选择最终模型和 provider。请求必须使用 model: "auto"，并可通过 tier 和 API Key 策略控制候选路由范围。

常用写法

当请求使用 model: "auto"，且当前 tier 余额不足时，JoyToken 可在策略允许范围内尝试其他 tier。

请求不接受具体模型 ID。若策略、余额或预算过滤后没有可用候选模型，请求会返回错误。

对于复杂请求，JoyToken 可能以编排模式处理单个 model: "auto" 请求：先生成任务计划（plan），用选定的子模型逐个执行任务，最后汇总出最终答案。你无需显式开启，由网关根据请求自动决定。

信号	说明
`plan`（顶层）	有序任务列表，仅编排模式返回
`choices[].message.content`	变为各任务输出的 JSON 数组（含 `content` 和 `title`），而非单一字符串
`metadata`（数组）	每个任务一条，含保留任务 `__planner__` 和 `__final__`
流式 planning 事件	首先发出一个 `orchestration.phase` 为 `planning` 的 chunk，携带有序的 `plan`，其后紧跟 `__planner__` 的 metadata 事件
流式任务 chunk	每个任务的正文 chunk 都携带 `orchestration` 字段（`task_id`、`task_seq`、`task_status`、`title`）
流式 `metadata` 事件	每个任务在其正文之后各发出一个独立 metadata 事件（值为单个对象，而非数组）

字段	说明
`task_id`	任务标识；`__planner__` 和 `__final__` 为保留值
`task_seq`	执行顺序；`0` 为规划器
`task_status`	任务状态，如 `DONE`
`tag`	任务角色，如 `orchestration`、`search`、`reasoning`、`writing`、`aggregation`
`title`	可读的任务标题

编排模式下每个任务单独计费（每个任务一条 metadata/billing），且可能使用不同子模型。渲染前请先将 choices[].message.content 按 JSON 解析，并对所有任务 metadata 的 billing.credits_used 求和。