模型与价格目录
与 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 没有逐模型的端点登记表,推断 依据是价格:只有视频模型才会配置按秒计价,只有图像模型才会配置出图价格。文本是 兜底,因为网关确实接受任意模型走那四个文本端点。
与 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
——那个接口按 Key 的允许分组过滤。
supported_endpoint_types 是推断值。JuCode 没有逐模型的端点登记表,推断
依据是价格:只有视频模型才会配置按秒计价,只有图像模型才会配置出图价格。文本是
兜底,因为网关确实接受任意模型走那四个文本端点。
Response Body
application/json
application/json
curl -X GET "https://example.com/api/pricing"{ "success": true, "pricing_version": "4f2a9c1e7b3d5a8f0c6e2b4d9a1f3c5e", "auto_groups": [], "group_ratio": { "默认": 1, "国模": 0.8 }, "usable_group": { "默认": "通用分组", "国模": "国产模型,价格更低" }, "supported_endpoint": { "openai": { "path": "/v1/chat/completions", "method": "POST" }, "anthropic": { "path": "/anthropic/v1/messages", "method": "POST" } }, "vendors": [ { "id": "5e6f7a8b-9c0d-4e1f-a2b3-c4d5e6f7a8b9", "name": "OpenAI", "slug": "openai" } ], "data": [ { "model_name": "gpt-5.4", "quota_type": 0, "model_ratio": 2, "model_price": 0, "owner_by": "OpenAI", "completion_ratio": 8, "cache_ratio": 0.1, "enable_groups": [ "默认" ], "supported_endpoint_types": [ "openai", "openai-response", "openai-response-compact", "anthropic" ], "billing_mode": "per_token", "vendor": { "id": "5e6f7a8b-9c0d-4e1f-a2b3-c4d5e6f7a8b9", "name": "OpenAI", "slug": "openai" }, "context_window": 1050000, "max_output_tokens": 128000, "reasoning_efforts": [ "none", "low", "medium", "high", "xhigh" ], "jucode_pricing": { "input_unit_price": "0.004", "output_unit_price": "0.032", "cache_read_input_price": "0.0004" } } ]}查询已消费(new-api 兼容) GET
返回历史累计消费,单位是**分**(百分之一元),对应上游注释里的 `unit: 0.01 dollar`。 同样有 `/v1/dashboard/billing/usage` 别名。 ### start_date 和 end_date 会被忽略 接受但不使用,返回的**始终是历史累计值**。这是上游的行为,而所有会传这两个参数 的客户端本来就预期拿回一个累计数。 口径与 `/dashboard/billing/subscription` 一致:Key 带 `total_cost_limit` 时 报该 Key 的消费,否则报账户的。两个接口共用同一次口径判定,因此不会互相矛盾。
查询令牌用量(new-api 兼容) GET
比上面两个接口更直接:授予、已用、可用三个数分开返回,客户端不必自己做减法。 **路径末尾的斜杠不是笔误**,上游就是这么注册的,客户端也照抄了。不带斜杠的写法 会被 301 重定向过来。 金额单位是积分(= 元),而不是上游的原始配额整数。多出来的 `currency` 字段就是 用来说明这一点的——它让这个接口在 `*_usd` 那一对做不到的地方变得无歧义。 `model_limits` 在上游是逐令牌的模型白名单。JuCode 限制的是模型**分组**,所以 这里放的是该 Key 允许的分组 ID:同一个问题,不同的限制粒度。