查询已消费(new-api 兼容)
返回历史累计消费,单位是**分**(百分之一元),对应上游注释里的 `unit: 0.01 dollar`。 同样有 `/v1/dashboard/billing/usage` 别名。 ### start_date 和 end_date 会被忽略 接受但不使用,返回的**始终是历史累计值**。这是上游的行为,而所有会传这两个参数 的客户端本来就预期拿回一个累计数。 口径与 `/dashboard/billing/subscription` 一致:Key 带 `total_cost_limit` 时 报该 Key 的消费,否则报账户的。两个接口共用同一次口径判定,因此不会互相矛盾。
返回历史累计消费,单位是分(百分之一元),对应上游注释里的
unit: 0.01 dollar。
同样有 /v1/dashboard/billing/usage 别名。
start_date 和 end_date 会被忽略
接受但不使用,返回的始终是历史累计值。这是上游的行为,而所有会传这两个参数 的客户端本来就预期拿回一个累计数。
口径与 /dashboard/billing/subscription 一致:Key 带 total_cost_limit 时
报该 Key 的消费,否则报账户的。两个接口共用同一次口径判定,因此不会互相矛盾。
Authorization: Bearer sk-juc-...
前缀必须是恰好 Bearer (首字母大写 + 单个空格)。bearer、BEARER
或用制表符分隔都会被判为无效。
除 API Key 外,也接受 OAuth 设备访问令牌(仅限 oauth_access 类型的 JWT;
普通网页会话令牌会被拒绝)。
In: header
Query Parameters
接受但忽略。
接受但忽略。
Response Body
application/json
application/json
application/json
curl -X GET "https://example.com/dashboard/billing/usage"{ "object": "list", "total_usage": 7155}查询额度(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 声称自己拥有全部余额。 查询参数一律忽略。
模型与价格目录 GET
与 new-api 的同名接口字段对齐的模型目录。**无需凭证**。 ### 倍率是怎么换算出来的 new-api 用**倍率**而非金额描述价格:`model_ratio` 为 `1` 表示「每 100 万输入 token 2 美元」,`completion_ratio` 再乘上去得到输出价。JuCode 存的是每 1000 token 的绝对价格,单位是积分(1 积分 = 1 元)。两者可以互相换算: ``` model_ratio = 元每1K × 1000 ÷ 2 = 元每1K × 500 ``` 所以按 new-api 惯例渲染 `model_ratio × 2` 得到的是**每 100 万 token 多少元**, 不是多少美元。数字是对的,硬编码客户端印在旁边的货币符号不对。这一点无法在 格式内修正——它没有货币字段。 因此每个条目都额外带一份 `jucode_pricing`,里面是绝对价格(积分 / 1K token, 按次计费的模型则是每次价格)。**做 JuCode 集成请读它,不要读倍率。** ### 与 new-api 的三处有意差异 | 差异 | 原因 | |---|---| | 没有 `vendor_id`,改为 `vendor` 对象 | new-api 的厂商 ID 是小整数,JuCode 的是 UUID。把 UUID 塞进按整数解析的字段比省略它更糟 | | `owner_by` 填厂商名 | new-api 声明了这个字段却从不赋值,上游恒为空串。填上只会更有信息量 | | 多出 `context_window`、`max_output_tokens`、`reasoning_efforts` | new-api 没有任何逐模型的能力元数据 | ### 这不是权限列表 本接口返回的是**目录**:所有已启用的模型,以及每个模型所属的分组 (`enable_groups`)。它与调用方无关,因此可以整体缓存。 你的 Key 实际能调用哪些模型,看 [`GET /v1/models`](/docs/api/models/listModels) ——那个接口按 Key 的允许分组过滤。 `supported_endpoint_types` 是**推断值**。JuCode 没有逐模型的端点登记表,推断 依据是价格:只有视频模型才会配置按秒计价,只有图像模型才会配置出图价格。文本是 兜底,因为网关确实接受任意模型走那四个文本端点。