费用怎么看，调用失败怎么排查？
费用核对先查模型广场费率，实际结算以控制台记录为准；接口排错首看 HTTP 状态码与响应 JSON，结合密钥与模型配置快速定位根因。（2026年9月最新排查手册）
调用前要确认哪些费用信息？
| 项目 | 需要确认 | 原因 |
|---|---|---|
| 模型与分组 | 实际使用的模型 ID、账户适用分组 | 不同配置可能使用不同费率 |
| 计费单位 | 按 Token 还是按次，页面采用何种币种或额度 | 不同单位不能直接比较 |
| 输入与输出 | 是否有分别计价、缓存或其他项目 | 输入价格不一定代表总费用 |
| 实际消耗 | 控制台中对应请求的扣费记录 | 最终核对以实际记录为依据 |
若当前模型明确按输入、输出 Token 分别计费，可先按“输入用量 × 输入单价 + 输出用量 × 输出单价”估算，并确认单价分母和币种；若有缓存、分组倍率或按次项目，应按当前规则单独核对。不要用这一简化公式替代站点的实际账单。
高频异常状态码与生产自愈方案
在实际生产调用或第三方客户端接入中，以下四类状态码最为常见，建议依据下表标准流程自愈：
| 错误码 | 典型返回信息 | 根本触发原因 | 生产推荐一键修复措施 |
|---|---|---|---|
| 401 Unauthorized | invalid_api_key | Authorization 请求头缺少 Bearer 前缀，或密钥失效 | 检查请求头格式为 Bearer <KEY>，在控制台重新生成有效令牌 |
| 404 Not Found | Cannot POST /v1/v1/chat/... | 客户端 Base URL 与内部请求路径出现双重 /v1 拼接 | 若客户端自动追加 /v1，将接口地址改为 https://migofastapi.xyz |
| 429 Too Many Requests | insufficient_quota / rate_limit | 账户额度不足，或短时间内请求并发超出 RPM/TPM 阈值 | 登录控制台查看余额并补充；代码中增加 1s~4s 指数退避重试机制 |
| 500 / 503 Service Error | no_available_channel / upstream | 上游官方接口突发网络抖动或正在例行维护 | 在网关或客户端配置自动备选降级策略（如从 Claude 降级至 Gemini） |
常见状态码应从哪里查起？
| 现象 | 常见检查方向 | 下一步 |
|---|---|---|
| 401 | 密钥、Authorization 格式 | 确认使用 MIGO 密钥，前缀为 Bearer |
| 403 | 账户、令牌或访问权限 | 查看响应正文，核对控制台状态 |
| 404 / 路径错误 | Base URL、重复 /v1、端点不兼容 | 比较客户端地址与 curl 地址 |
| 429 | 请求频率、配额或上游限制 | 减少并发，按响应提示等待后有限重试 |
| 5xx / 无可用渠道 | 网关或上游服务状态、模型路由 | 保存时间与错误信息，联系运营方 |
| 连接超时 | 网络、客户端超时设置、上游耗时 | 用短文本请求对照，避免无上限重试 |
状态码只能帮助缩小范围，不能单独确定根因；不同客户端与上游可能包装错误。不要通过重复充值或高频重试猜测解决办法，应结合返回消息与账户记录判断。
如何提交便于排查的问题？
- 发生时间与时区、客户端名称和版本。
- 所用模型 ID、接口路径、HTTP 状态和错误正文。
- 脱敏后的最小请求，以及是否能在 curl 中复现。
- 如响应提供请求 ID，可一并记录；不要发送 API 密钥或完整私人对话。
可通过本站公开的 QQ 交流群 952562473反馈。交易、退款或服务等级条款应向运营方核实，本指南不增加任何相关承诺。
调用成功为什么还要查看控制台？
成功返回只说明该次请求完成。控制台记录可帮助确认费用归属与消耗是否符合预期，也是之后比较模型成本的依据。先用小样本观察，再逐步增加请求量。