模型清单与能力

为什么这一页不直接列模型

可用模型完全由站长在后台配置的渠道决定，并且会随上游上下线、渠道调整而变化。 任何写死在文档里的模型清单都会过期，甚至误导你去填一个已经不存在的 ID。

所以本页给出的是实时查询方法 —— 这也是排查「模型不存在」类问题的正确起点。

实时查询可用模型

操练场（最直观）

打开 操练场，左侧模型下拉框列出的就是当前密钥可用的模型。 还能直接对话测试，一次确认「模型存在」与「模型可用」两件事。

curl + jq

curl -s https://api.ziai-demo.com/v1/models \
  -H "Authorization: Bearer sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  | jq -r '.data[].id'

没装 jq 的话看原始 JSON：

curl -s https://api.ziai-demo.com/v1/models \
  -H "Authorization: Bearer sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

PowerShell

(Invoke-RestMethod -Uri "https://api.ziai-demo.com/v1/models" `
  -Headers @{ Authorization = "Bearer $env:ZIAI_API_KEY" }).data.id

客户端内获取

部分客户端能直接拉取模型列表：

• CherryStudio：服务商页点「获取模型列表」，再点模型右侧 + 加入
• CC-Switch：模型输入框旁的「获取模型」（下载图标），调用的正是 /v1/models
• Claude Code：设 CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1，启动时自动把网关模型加入 /model 选择器
• ZCode / WorkBuddy / ChatBox：需手动填写模型 ID

列表里有 ≠ 一定能调用

/v1/models 返回的是密钥可见的模型。实际调用还可能因为下面这些原因失败：

• 密钥设了模型限制，不含该模型 → 403 / model_access_denied
• 密钥所属分组无该渠道权限 → 403
• 该模型只有部分协议通道（例如只支持 Chat，不支持 Responses）→ 特定客户端 404 / 400
• 账户额度不足 → 402 / 额度类错误

先用三步定位法确认到底卡在哪一层。

模型 ID 命名注意事项

1. 逐字复制，不要手打

   大小写、短横线、点号、日期后缀都必须完全一致：

   正确	常见错误写法
   gpt-5.2	GPT-5.2、gpt5.2、gpt-5-2
   claude-sonnet-4-5	claude-sonnet-4.5、claude-sonnet-45
   deepseek-chat	deepseek、DeepSeek-Chat

2. 警惕名称相近的变体

   日期版（-20241022）、供应商前缀版（zai-org/glm-5.2）、能力后缀版（-flash、-vision、[1m]） 是不同的模型，价格与能力都不同。CherryStudio 会在模型名下方显示实际 API 模型 ID，添加前先核对这一行。

3. 不要凭印象填官方名称

   ZiAI 支持模型重定向：站长可以把 gpt-4o 映射到实际上游的另一个模型，也可以自定义站内专有的模型名。 所以你在 ZiAI 上看到的 ID 可能与上游官方名称不同 —— 一律以 ZiAI 控制台展示的为准。

4. 换客户端时重新确认

   同一个模型在不同协议通道下的可用性可能不同。例如某模型走 Chat 通道正常，走 Responses 通道却报「仅支持 v1/responses」或反之。

能力标记含义

各客户端会给模型标能力（CherryStudio 的模型管理、ChatBox 的能力勾选、ZCode 的图片支持判定、WorkBuddy 的能力标记）：

能力	含义	标记错误的后果
工具调用（tools / function calling）	模型能返回结构化的工具调用请求	未标记 → Agent 不触发工具，表现为「只会聊天不会干活」
图片输入（vision）	模型能接收图像内容	未标记 → 图片被客户端提前移除；错误标记 → 上游直接报错
推理 / 思考（thinking / reasoning）	模型支持思考档位或思考开关	档位不被上游接受时会返回 400，降档即可
上下文窗口	单次请求可容纳的 Token 上限	设得过大 → 每轮重发历史更多，费用成倍增加
流式输出	支持 SSE 逐段返回	不支持时客户端可能长时间无输出后一次性返回

能力标记要以 ZiAI 实际情况为准

客户端不会自动知道 ZiAI 上某模型的真实能力：

• 选标准/内置供应商时，CherryStudio、WorkBuddy 会自动写入能力标记
• 走自定义供应商时，需要你手动确认；ZCode 则会综合供应商配置、模型目录与接口协议做判定，结果分「支持 / 不支持 / 能力未知」三类

无法确认时，先不要在该模型下发送图片，避免请求直接失败。

当前站点模型清单

清单待站长补充

本表数据来自 src/site.ts 的 MODELS 数组，当前为空 —— 填入后全站表格自动生效。 在此之前，请用上面的实时查询方法获取准确清单。

按场景选模型（通用建议）

具体可用性以 ZiAI 实际清单为准，这里只给选型思路：

场景	选型思路
日常问答、文案润色、格式转换	轻量 / flash 档模型，响应快、单价低
写文档、分析数据、多文件改动	中档通用模型，效果与成本平衡
跨模块重构、多步推理、复杂调试	旗舰推理模型，配合较高思考档位
长文档处理、大仓库理解	长上下文模型（如 1M 窗口），但注意费用随窗口线性上升
截图理解、UI 还原、视觉问答	必须选带 vision 能力的模型
Agent / 工具密集型任务	必须选工具调用稳定的模型，比选「最聪明」的更重要
向量检索 / RAG	用 https://api.ziai.lol/v1/embeddings 端点与对应的嵌入模型

Agent 场景优先看工具调用稳定性

编程 Agent 每一轮都在做工具调用。一个工具调用格式偶尔出错的旗舰模型， 实际体验往往不如工具调用稳定的中档模型 —— 因为一次格式错误就可能导致整个任务中断或反复重试，反而更贵。

相关页面

• 端点与协议 —— 各协议端点与地址填法
• 计费、配额与限速 —— 上下文窗口与费用的关系
• 常见报错速查 —— 模型不存在的完整排查路径