模型与能力

别在客户端硬编码模型列表

可用模型由后台配置决定,会随时增减。请在运行时调 /v1/models 获取,不要把列表 写死在代码里。

curl https://api.jucode.cn/v1/models \
  -H "Authorization: Bearer $JUCODE_API_KEY"

{
  "object": "list",
  "data": [
    {
      "id": "gpt-5.4",
      "object": "model",
      "created": 1753440000,
      "owned_by": "jucode",
      "context_window": 1050000,
      "max_output_tokens": 128000,
      "reasoning_efforts": ["none", "low", "medium", "high", "xhigh"]
    }
  ]
}

返回的是当前账号已启用且有权访问的模型,按名称字母序排列。不同 API Key 看到的 列表可能不同——Key 上可以配置模型组白名单。

三个 JuCode 扩展字段

除 OpenAI 标准字段外,每个模型还带三个扩展字段。它们不在 OpenAI 规范里,但对写健壮 的客户端很有用:

用 context_window 来决定截断多少历史消息,比按模型名做 if-else 可靠得多:

models = {m["id"]: m for m in client.models.list().model_dump()["data"]}
budget = models["gpt-5.4"]["context_window"] - models["gpt-5.4"]["max_output_tokens"]

reasoning_efforts

档位从低到高是 none / low / medium / high / xhigh。

none 的存在与否是关键信息:列表里没有 none,说明该模型无法关闭推理。比如 codex 系模型就只能在 low 及以上运行。如果你的场景对延迟敏感又不需要推理,得先确认 这一点。

owned_by 不反映真实厂商

owned_by 恒为 "jucode",不暴露背后实际路由到哪家。同一个模型名在不同时刻可能落 到不同上游——这正是网关做故障转移的方式。

所以别拿 owned_by 做任何判断逻辑。

端点能力不体现在模型列表里

/v1/models 只告诉你有哪些模型,不告诉你每个模型支持哪些端点。拿一个纯对话模型 去调 /v1/embeddings,会返回:

{
  "error": {
    "type": "service_unavailable",
    "code": "endpoint_unsupported_by_providers",
    "message": "no provider for model gpt-5.4 serves the embeddings endpoint"
  }
}

这是 503,不是 400。看到 endpoint_unsupported_by_providers 时,通常不是你的 请求写错了,而是模型选错了,或者管理员还没给这个模型配置对应能力的上游。重试没有 意义。

Anthropic 格式的模型列表

curl https://api.jucode.cn/anthropic/v1/models \
  -H "x-api-key: $JUCODE_API_KEY"

返回同一批模型,但字段不同:created_at 是 RFC3339 字符串(而非 /v1/models 的 Unix 整数),display_name 恒等于 id,且没有上面那三个扩展字段。

分页参数(limit、after_id、before_id)会被忽略,has_more 恒为 false, 一次返回全部。

限流

两个模型列表端点都受 240 次 / 60 秒的用户级限流,响应头带 X-RateLimit-Limit 和 X-RateLimit-Remaining。

这个额度足够启动时拉一次并缓存,但不适合每次请求前都查。建议进程启动时拉一次,或者 按分钟级缓存。

{"error": "rate limit exceeded", "scope": "user"}