[Feature] /api/pricing 返回模型能力标签与上下文长度元数据

name: 功能请求 about: 使用简练详细的语言描述希望加入的新功能 title: '[Feature] /api/pricing 返回模型能力标签与上下文长度元数据' labels: enhancement assignees: ''

提交前必读（请勿删除本节）

• 文档：https://docs.newapi.ai/
• 使用问题先看或先问：https://deepwiki.com/QuantumNous/new-api
• 开启透传后的转发相关反馈不接受 issue；透传模式会直接转发请求，请自行确认上游行为。
• 不接受 coding plan、逆向渠道等技术支持类 issue。
• 警告：删除本模板、删除小节标题或随意清空内容的 issue，可能会被直接关闭；重复恶意提交者可能会被 block。

您当前的 newapi 版本

v1.0.0-rc.16

提交确认

• 非重复 issue: 我已搜索现有 Issues，确认目前没有类似 issue。
• 提交前必读: 我已完整阅读上方“提交前必读”，并已查看文档 https://docs.newapi.ai/、项目 README 且向 AI 提问，确认这不是使用、配置或接入类问题，且现有版本无法满足需求。
• 模板完整: 我未删除此模板中的任何引导内容或小节标题，并会按要求完整填写。
• 维护成本: 我理解项目维护者精力有限，不遵循模板要求的 issue 可能会被无视或直接关闭。

功能描述

希望在网关侧为模型（而非单次请求）提供可维护、可对外暴露的目录级元数据：后端通过 GET /api/pricing 等接口返回；前端在模型管理或渠道管理界面提供配置入口，便于调用方在接入前了解模型能力与上下文限制。

当前 /api/pricing 主要返回模型名称、描述、计费信息、tags、supported_endpoint_types 等。tags 为自由文本（例如 Tools,128K,Vision），无法结构化区分 Function Calling、JSON mode、Structured Output、Tools 等能力类型。前端定价页虽已预留 capabilities、context_length、max_output_tokens 等字段类型，但后端未填充，Capabilities 相关展示通常为空。

期望在模型元数据中支持定义，并在 /api/pricing 的每条模型记录中返回如下字段（示例）：

{
  "model_name": "example-model",
  "function_tags": "Function Calling,Reasoning,Content Cache,Multimodal Input",
  "max_prompt_tokens": 1000000,
  "max_completion_tokens": 128000
}

字段含义期望如下：

后端（接口返回）

1. 对外可读：登录用户访问 GET /api/pricing 时，在 data[] 每条模型记录中稳定返回 function_tags、max_prompt_tokens、max_completion_tokens；未配置时的返回行为需明确、一致（例如省略空值或与现有 JSON 字段风格保持一致）。
2. 管理端可读写：管理员通过现有模型/渠道相关 API 创建、更新、查询上述字段（与控制台配置能力对应），而不仅依赖手工改库或外部脚本。
3. 与运行时能力区分：本需求描述的是目录/展示用元数据，用于模型选型与文档化；不要求网关据此自动拦截或改写 relay 请求中的 tools、response_format、max_tokens 等参数（运行时仍由客户端按请求传入、由上游决定是否支持）。

前端（管理端配置）

管理员应能在控制台模型或渠道相关界面中维护上述字段，无需直接操作数据库：

配置保存后，应能在 /api/pricing 及相应管理端列表/详情中看到一致的数据。

应用场景

1. API 接入方模型选型
   集成方在调用前拉取 /api/pricing，根据 function_tags 筛选支持 Function Calling、Reasoning 等的模型，根据 max_prompt_tokens / max_completion_tokens 做上下文与输出预算规划，无需维护一份与网关脱节的模型能力表。

2. 控制台配置与展示
   运维在模型管理或渠道管理界面填写能力与上下文字段；用户在定价页 / 模型目录看到与 /api/pricing 一致的能力标签与上下文上限，避免 capabilities 区块常为空、参数说明与真实目录数据脱节。

3. 多模型网关 / 聚合场景
   同一 model_name 可能对应不同上游渠道；可在渠道界面按渠道维护差异化规格，在模型界面维护通用目录信息；调用方通过 /api/pricing 获取统一的、可查询的能力与时序边界说明，而不是仅从渠道侧 /v1/models 或静态文档推断。

4. 运维与文档自动化
   基于 /api/pricing 导出模型能力矩阵（CSV、OpenAPI、内部文档等），减少人工维护模型规格表的成本。