主题
报错对照表
报错信息大多在骗人
中转链路上的报错，字面意思经常指向错误的方向。 比如「服务暂时不可用」听着像我们挂了，实际最常见的原因是你请求的模型不在你的套餐里。
按下表的「真正原因」排查，不要按报错字面排查。
模型不存在 / model_not_found（404）
Model "xxx" is not supported by any configured account in this group
最高频的一类，最近 24 小时有 34 个客户撞到。 两种完全不同的原因，报错却一模一样：
| 情况 | 怎么确认 | 怎么修 |
|---|---|---|
| 模型名写错 | 在 模型清单 里搜不到这个名字 | 按清单逐字复制。常见是漏后缀 |
| 模型不在你的套餐里 | 清单里搜得到，但「可用套餐」没有你买的那个 | 换一个你套餐内的模型，或升级套餐 |
模型名带了 [1M] 方括号 | 报错里的模型名末尾有 [1M] 或 [1m] | 去掉方括号。详见下一条 |
Claude Code 用户特别注意
如果报错里的模型名和你「默认兜底模型」框里填的一样，那就是它。 见 Claude Code 配置。
模型名[1M] 在 OpenAI 协议下必 404
[1M] 是 Claude Code 自己的长上下文标记。我们的处理方式按协议不同：
| 你用的协议 | 典型客户端 | deepseek-v4-flash[1M] |
|---|---|---|
| Anthropic Messages | Claude Code、CC Switch、VS Code 插件 | ✅ 我们会去掉结尾的 [1M] 再转发 |
| OpenAI Chat / Responses | ChatBox、WorkBuddy、OpenCode、Trae、Zcode、Codex、SDK | 🔴 原样发给上游 → 404 |
这个坑专门坑「配置抄得很顺手」的人
从 Claude Code 的配置里把带方括号的模型名复制到 ChatBox / WorkBuddy，必 404。 而报错只说「模型不存在」，一个字都不会提那对方括号。
判据：把报错里的模型名和 模型清单 逐字比，多出来的就是它。
无权限 / 403
你的「某套餐」套餐已于 yyyy-mm-dd hh:mm 北京时间 到期
时长卡到期了。机器人不会自己停，会一直重试这条。
| 真正原因 | 怎么修 |
|---|---|
| 套餐到期 | 去 计费说明 续费。续费后 不用换 API Key |
| key 的分组与要用的模型不匹配 | 控制台改 key 的分组，见 先看这三步 |
| 账户余额不足（按量分组） | 充值，或改用时长卡分组 |
| 上游临时不可用 | 稍后重试；持续出现请联系客服 |
模型不存在 / model_not_found（404）补充
买了 Flash 卡去请求 Pro（或反过来）、以及拿单模型卡去跑 Codex 默认的 GPT 模型，都是这条 404。 报错里会写「本卡可用模型」。需要别的模型就买对应的卡，不是服务挂了。
请求过于频繁 / 429
rate_limit_error/请求过于频繁
触发了限流。这是正常的保护机制，不是故障。
正确做法是退避重试而不是立刻重发。详见 限流说明。
参数错误 / 400
invalid_request_error
| 常见原因 | 怎么修 |
|---|---|
请求体字段不对（如缺 max_tokens） | 对照 快速开始 的示例 |
| 用了模型不支持的参数 | 去掉该参数重试 |
| 协议选错（Responses vs Chat Completions） | 见 接口地址与协议 |
认证失败 / 401
key 不对、已吊销，或者写法错了。
- 确认 key 完整复制（
sk-开头，没有多余空格换行） - 确认用的是
Authorization: Bearer sk-xxx或x-api-key: sk-xxx - 控制台确认这个 key 还在、状态正常
空响应 / 解析失败 / empty stream
几乎都是地址填错，而不是服务问题。
地址填成站点根路径时，POST 过去返回的是 HTTP 200 的网页 HTML， 客户端拿 HTML 当数据解析就会报这个。
一条命令确认：
bash
curl -o /dev/null -s -w "%{http_code} %{content_type}\n" \
-X POST https://api.jichuanai.com/v1/chat/completions \
-H "Authorization: Bearer sk-xxx" -H "Content-Type: application/json" \
-d '{"model":"你的模型名","messages":[{"role":"user","content":"hi"}],"max_tokens":8}'text/html → 地址错了；application/json → 地址对。
API Error: Failed to parse JSON
同一类问题的另一种说法：收到的响应不是合法 JSON。
如果上面那条 curl 返回的是 application/json（说明地址和服务都没问题）， 那问题多半在你和我们之间的那一段网络：某个代理 / 网关插了一层自己的错误页。
先关掉系统代理，或换一个网络再试。和 key、模型名都没有关系。
响应很慢 / 首字等很久
先分清是首字慢还是整体慢：
| 现象 | 通常原因 |
|---|---|
| 首字要好几秒，之后很流畅 | 长上下文的 prefill。你发的内容越多，模型读完它就越久。属正常 |
| 首字快，但整体拖很久 | 模型在生成长回答；或客户端设了很大的工具调用轮数 |
| 突然全部变慢 | 可能是上游波动，联系客服 |
发 10 万 token 的上下文时，首字等几秒是正常的。
两个已知情况
思考模式会拖慢甚至超时
部分型号开启「思考模式」时响应会慢很多， 有时等太久被中断。表现是：回答文不对题、重复开场白、或者只回几个字。
建议在软件里关掉「思考模式」/「深度思考」/「reasoning」这类开关 —— 关掉后通常几秒就回。
日常问答和大部分写代码的场景，开不开差别不明显；确实需要它一步步推演的可以留着开， 只是要能接受更慢、偶尔超时。
响应速度会有波动
线路会有波动，少数请求比平时慢、偶尔超时，遇到这种重试一次通常就好。
如果是持续用不了（连续多次、超过十分钟），那多半不是波动 —— 先按上面的报错对照查一遍。
还是没解决
在控制台联系客服，带上这四样能省掉一轮来回：
- 完整报错原文
- 你填的请求地址
- 模型名（原样复制你填的）
- key 的分组名