JuCode 文档
ApiModels

列出模型

返回当前账号可用的所有已启用模型,按名称字母序排列。 除 OpenAI 标准字段外,还额外返回三个 JuCode 扩展字段:`context_window`、 `max_output_tokens`、`reasoning_efforts`。用它们来动态适配上下文预算和推理 档位,比在客户端硬编码模型能力可靠。 `owned_by` 恒为 `"jucode"`,不会暴露真实上游厂商。 本端点受 240 次 / 60 秒的用户级限流,并返回 `X-RateLimit-*` 响应头。

GET
/v1/models

返回当前账号可用的所有已启用模型,按名称字母序排列。

除 OpenAI 标准字段外,还额外返回三个 JuCode 扩展字段:context_windowmax_output_tokensreasoning_efforts。用它们来动态适配上下文预算和推理 档位,比在客户端硬编码模型能力可靠。

owned_by 恒为 "jucode",不会暴露真实上游厂商。

本端点受 240 次 / 60 秒的用户级限流,并返回 X-RateLimit-* 响应头。

Authorization

AuthorizationBearer <token>

Authorization: Bearer sk-juc-...

前缀必须是恰好 Bearer (首字母大写 + 单个空格)。bearerBEARER 或用制表符分隔都会被判为无效。

除 API Key 外,也接受 OAuth 设备访问令牌(仅限 oauth_access 类型的 JWT; 普通网页会话令牌会被拒绝)。

In: header

Response Body

application/json

application/json

application/json

application/json

curl -X GET "https://example.com/v1/models"
{  "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"      ]    },    {      "id": "claude-sonnet-5",      "object": "model",      "created": 1753440000,      "owned_by": "jucode",      "context_window": 200000,      "max_output_tokens": 8192,      "reasoning_efforts": [        "none"      ]    }  ]}

生成图像变体 POST

`multipart/form-data` 上传。行为与 `/v1/images/edits` 一致,只是不需要遮罩。 请求体上限 32 MiB。

查询额度(new-api 兼容) GET

OpenAI 早已下线的旧版计费接口,被 one-api 采纳、new-api 继承,如今几乎所有 「查余额」工具都在探测这个路径。实现它,是为了让 JuCode 的 Key 在那些工具里 直接可用,不需要专门的插件。 同一个处理逻辑挂在两个路径上:`/dashboard/billing/subscription` 和 `/v1/dashboard/billing/subscription`。上游两个都提供,客户端也分成了两拨。 ### 字段名写着 usd,单位却是元 JuCode 的记账单位是积分(1 积分 = 1 元)。这个格式里没有货币字段可以说明这件事, 而按某个汇率折成美元只会让数字和控制台对不上。所以三个 `*_usd` 字段里装的是 **元**,在前面印 `$` 的客户端印错了符号,数字本身是对的。new-api 的运营者把 `quota_display_type` 设成 CNY 时行为完全一样。 需要明确单位的场景请用 [`GET /v1/open/balance`](/docs/api/account/getBalance)。 ### 这个数字是「累计授予」,不是「剩余」 三个 `*_usd` 字段都等于**余额 + 历史总消费**。因为所有查余额工具都做同一个减法: ``` 剩余 = soft_limit_usd - total_usage / 100 ``` 配合 `/dashboard/billing/usage` 返回的已消费额,这个减法正好落在真实余额上。 ### Key 带总额上限时口径会变 如果调用所用的 Key 设置了 `total_cost_limit`,返回的是**该 Key 的**上限与消费, 而不是账户的。带上限的 Key 是一份子预算,持有者关心的是那个天花板;报账户余额 会让一个受限的 Key 声称自己拥有全部余额。 查询参数一律忽略。