DeepSeek 用量余额监控方案全解析：接口原理 + Win/Mac开源DeepSeek监控工具推荐

DeepSeek 用量余额监控方案全解析：接口原理 + Win/Mac开源DeepSeek监控工具推荐

---

前言

你是否也遇到过这样的窘境——

正专注地调用 DeepSeek API 开发应用，突然收到一条欠费告警。打开平台控制台一看，原来缓存命中率怎么这么低，根本理不清是哪个工具调用出了问题、或者什么时候开始缓存命中率出现了问题。

更棘手的是：DeepSeek 开放平台只提供了余额查询的公开 API，却没有用量统计的官方接口。想追踪 Token 消耗？想按模型和日期分析消费趋势？想看缓存命中率？——只能反复手动刷新后台页面。
本文正是为这个痛点而生。

我们将从技术原理出发，系统拆解 DeepSeek API 监控的三个核心模块：

• 余额查询：基于官方公开 API，快速获取账户余额与可用状态；
• 用量数据获取：通过分析平台前端内部接口，拿到按模型、按日期拆分的 Token 用量和消费明细；
• 用量 Token 自动同步：利用内嵌浏览器 + JS Hook 的方式，自动获取登录凭证，彻底告别手动复制粘贴。

同时，我们还会讨论凭据安全管理、内部接口的不稳定性应对策略、跨平台可视化方案，并在文末推荐两个已在 Windows 和 macOS 上完成的开源工具，供直接使用或二次开发参考。

前置阅读提示：本文假定你已拥有 DeepSeek 开放平台账号，并了解 API Key 的基本用法。文中涉及的内部接口分析基于浏览器网络请求的公开观察，仅供学习研究。请合理使用，理性看待接口变更与账户安全风险。

---

如果你正在寻找一款趁手的 DeepSeek 用量监控方案，或者好奇如何从零搭建一个跨平台的桌面监控工具，这篇指南应该能给你提供清晰的路线图和可落地的技术方案。

1. 如何获取余额数据

余额查询是整个监控体系中最稳定的环节——DeepSeek 官方提供了标准的 REST API。

接口信息

GET https://api.deepseek.com/user/balance
Authorization: Bearer <API_KEY>

无需额外请求头或参数，直接用 API Key 做 Bearer 鉴权即可。

响应结构

{
  "is_available": true,
  "balance_infos": [
    {
      "currency": "CNY",
      "total_balance": "100.00",
      "granted_balance": "50.00",
      "topped_up_balance": "50.00"
    }
  ]
}

关键字段说明：

字段	含义	备注
is_available	账户是否可用	余额 > 0 时为 true，零或欠费为 false
currency	货币类型	国内用户 CNY，海外用户 USD
total_balance	总余额	赠送余额 + 充值余额的合计
granted_balance	赠送余额	注册赠送、活动赠送等，不可提现
topped_up_balance	充值余额	用户实际充值的金额

实现要点

调用余额接口只需关注三件事：

1. 超时控制：建议设置 10～15 秒超时，避免网络波动时长时间挂起
2. HTTP 状态码分类处理：401 说明 Key 无效或已过期，429 说明请求过频需等待，5xx 为服务端错误
3. 余额展示：将 is_available 映射为状态指示灯（绿/红），将 total_balance 与货币符号拼接后作为主展示数值，再结合用量数据中的当日消耗和本月消费，用户一眼就能掌握资金状况

示例伪代码：

function fetch_balance(api_key):
    response = http_get(
        url = "https://api.deepseek.com/user/balance",
        headers = {"Authorization": "Bearer " + api_key},
        timeout = 15s
    )

    if response.status == 401: raise "API Key 无效或已过期"
    if response.status == 429: raise "请求过于频繁，请稍后重试"
    if response.status >= 500:  raise "DeepSeek 服务器暂时不可用"

    data = parse_json(response.body)
    info = data.balance_infos[0]
    return {
        is_available: data.is_available,
        currency: info.currency,
        total_balance: info.total_balance
    }

---

2. 如何获取用量数据

这是整个监控方案中挑战最大的部分。DeepSeek 官方目前不提供用量统计 API——仅靠余额接口只能知道"还剩多少钱"，无法回答"本月用了多少 Token、各模型分别消耗了多少、缓存命中率如何"等问题。

2.1 内部用量接口的发现

通过浏览器开发者工具的 Network 面板抓包分析 DeepSeek 开放平台网页端（platform.deepseek.com）的请求，可以发现平台前端自身使用的内部接口：

# Token 用量明细 — 按天 + 按模型拆分
GET https://platform.deepseek.com/api/v0/usage/amount?month={月}&year={年}

# 消费金额明细 — 按天 + 按模型拆分
GET https://platform.deepseek.com/api/v0/usage/cost?month={月}&year={年}

这两个接口的共性：

• 鉴权方式：Authorization: Bearer <网页登录Token>，这与第 1 节的 API Key 是两套完全不同的凭证
• 请求头要求：需携带 User-Agent（模拟浏览器）和 x-app-version（固定版本号）来伪装成网页端请求
• 响应结构：按日期和模型两个维度返回数据，字段包含 PROMPT_CACHE_HIT_TOKEN（输入命中缓存）、PROMPT_CACHE_MISS_TOKEN（输入未命中缓存）、RESPONSE_TOKEN（输出 Token）、REQUEST（请求次数）等

2.2 两套凭证的本质区别

API Key 和用量 Token 在鉴权体系中互不通用，这是最容易混淆的地方：

对比维度	API Key	用量 Token
用途	调用 DeepSeek API（对话、余额查询等）	查看平台后台的用量统计
来源	在开放平台控制台手动创建	网页登录后由平台下发
有效期	长期有效（除非手动删除/轮换）	短期有效（过期需重新登录获取）
支持接口	/user/balance 及所有公开 API	/api/v0/usage/amount + /api/v0/usage/cost
官方文档	有完整文档	无（平台前端内部使用，未对外承诺）
典型长度	sk- 开头的字符串	较长随机字符串（通常 > 20 字符）
存储位置	由用户自行保管	存储在 localStorage.userToken

核心结论：查余额用 API Key，查用量用量 Token。两者缺一不可，分别获取、分别存储。

2.3 解析用量数据的通用思路

两个内部接口返回的 JSON 结构类似，按模型和日期两层嵌套。以 amount 接口为例，核心结构大致如下：

biz_data
  ├── total[]            # 按模型汇总的当月总量
  │     ├── model: "deepseek-v4-flash" | "deepseek-v4-pro"
  │     └── usage[]      # 各指标项
  │           ├── type: "PROMPT_CACHE_HIT_TOKEN" | "PROMPT_CACHE_MISS_TOKEN"
  │           │         | "RESPONSE_TOKEN" | "REQUEST" | "PROMPT_TOKEN"
  │           └── amount: "数字字符串"
  └── days[]             # 按天明细
        ├── date: "2026-06-15"
        └── data[]       # 当天各模型的 usage[]

cost 接口结构类似，但 biz_data 是数组，第一项包含总消费和每日消费明细。

关键指标的计算方式如下：

指标	计算方式
模型月度总 Token	各指标项的 amount 之和（REQUEST 除外）
模型月度消费	cost 接口中对应模型的各条目 amount 之和
缓存命中率	cache_hit / (cache_hit + cache_miss) × 100%（仅在输入 Token > 0 时有意义）
当天总 Token	当天各模型各指标项 amount 之和

---

3. 如何获取用量 Token

用量 Token 是查看用量数据的前提。由于它不是通过 API 后台生成的，获取方式需要另辟蹊径。以下是两种通用方案。

方式一：内嵌浏览器登录，拦截 Authorization 头（推荐）

核心思路：在应用中内嵌一个浏览器 WebView，打开 DeepSeek 登录页，让用户在 WebView 中正常完成登录。登录后，平台前端会自动向内部接口发起请求，这些请求的 Authorization 头中即携带了用量 Token。

实现链路

用户触发"登录同步"
  → 应用打开 WebView，导航至 platform.deepseek.com
  → 页面加载时注入一段 JS Hook 脚本
  → Hook 拦截全局的 fetch() 和 XMLHttpRequest.setRequestHeader()
  → 用户在 WebView 中完成登录流程
  → 登录后平台前端自动调用 /api/v0/usage/amount 等接口
  → Hook 从请求头的 Authorization 字段提取 Bearer token
  → 通过 IPC 通道将 token 传递给原生层（host 端）
  → 原生层收到 token 后，立刻用它调用一次 amount 接口验证有效性
  → 验证通过后持久化存储 token，触发 UI 刷新

JS Hook 的通用设计

Hook 需要做两件事：拦截出站 HTTP 请求的 Authorization 头 + 将捕获到的 token 传递给原生层。

拦截 fetch 的示意代码：

const originalFetch = window.fetch;
window.fetch = function(input, init) {
  try {
    const headers = init?.headers || input?.headers;
    const auth = extractAuthHeader(headers);
    if (auth) deliverToken(auth);
  } catch(e) {}
  return originalFetch.apply(this, arguments);
};

拦截 XMLHttpRequest 的示意代码：

const originalSetHeader = XMLHttpRequest.prototype.setRequestHeader;
XMLHttpRequest.prototype.setRequestHeader = function(name, value) {
  if (String(name).toLowerCase() === 'authorization') {
    deliverToken(value);
  }
  return originalSetHeader.apply(this, arguments);
};

Token 从 WebView 传回原生层

不同框架有不同的 IPC 通道选择：

框架	推荐 IPC 方式
Tauri (Rust)	invoke/emit，或降级到 document.title 轮询
Electron	ipcRenderer.send() 直接通信
WPF/WinForms (WebView2)	window.chrome.webview.postMessage()
macOS WKWebView	window.webkit.messageHandlers.{name}.postMessage()
Flutter (webview_flutter)	JavaScriptChannel 回调

稳健的降级策略：优先使用框架原生 IPC 通道；同时将 document.title 作为降级通道——写入约定格式的字符串（如 PREFIX:year:month:token），host 侧定时轮询窗口标题。这种双通道策略兼容性最好，不依赖特定框架能力。

验证环节不可或缺

WebView 登录过程中会经历多次重定向和中间 API 调用，并非每个 Bearer token 都是最终有效的用量 token。因此，Hook 拦截到任何 token 后，host 侧都应立刻用该 token 调用一次 /api/v0/usage/amount 接口，只有返回 200 才视为有效并持久化。

验证伪代码：

function verify_token(token, month, year):
    url = "https://platform.deepseek.com/api/v0/usage/amount?month=" + month + "&year=" + year
    response = http_get(
        url = url,
        headers = {
            "Authorization": "Bearer " + token,
            "User-Agent": "Mozilla/5.0 ... Chrome/148 ...",
            "x-app-version": "1.0.0"
        },
        timeout = 15s
    )
    return response.status == 200

缓存扫描兜底

如果 JS Hook 因页面加载时序问题未捕获到 token，可以设计第二道防线：在 WebView 关闭后扫描其磁盘缓存。

以 Chromium 内核的 WebView（WebView2 / CEF / Electron）为例，缓存文件通常为无扩展名的二进制/文本混合文件，存储在类似 Cache/Cache_Data/ 的目录下。扫描思路如下：

1. 遍历缓存目录下的所有文件
2. 以共享读模式打开（允许 WebView 同时写入），读取内容为文本
3. 搜索 "token":"<长字符串>" 模式
4. 用上下文特征（如同时包含 "id_profile" 和 "feature_gates"）过滤出真正的用户 token

方式二：手动提取 Token（兜底方案）

当自动同步因网络波动或平台更新等原因失效时，手动提取是最可靠的兜底路径：

1. 在任意浏览器中登录 platform.deepseek.com
2. 按 F12 打开开发者工具，切换到 Console 面板
3. 输入以下命令并回车：

   JSON.parse(localStorage.userToken).value
   

4. 复制控制台输出的字符串，粘贴到你的监控工具中保存

Token 会过期。当用量查询突然失败并提示 401 时，重复上述流程重新获取即可。务必在工具中提供一个"手动粘贴 Token"的入口，作为自动同步的永久兜底。

---

4. 注意事项与安全管理

4.1 凭据安全管理

你的应用需要管理两类敏感凭据，安全管理是底线：

凭据	风险等级	泄露后果
API Key	高	攻击者可消费你的余额、调用 API 产生费用
用量 Token	中	攻击者可查看你的用量数据、消费明细和调用历史

存储方案安全等级（从低到高）：

方案	安全等级	说明
本地明文 JSON	★☆☆☆☆	仅适用于个人单机、无敏感环境场景
环境变量	★★☆☆☆	避免提交到 Git，但无法阻止本机其他进程读取
配置文件 + 应用层加密	★★★☆☆	比明文好，但密钥若硬编码在应用内则形同虚设
系统凭据管理器	★★★★☆	Windows Credential Manager、macOS Keychain、Linux Secret Service API

推荐做法：

• 桌面应用优先使用操作系统提供的凭据管理服务
• 务必在 .gitignore 中排除配置文件、日志、缓存目录和任何可能包含密钥的文件
• 切勿在截图、日志、错误报告中暴露密钥内容
• 提供"一键清除凭据"功能，方便用户在更换设备或账号时安全注销
• API Key 建议定期在 DeepSeek 开放平台后台轮换

4.2 内部接口的不稳定性与应对策略

用量接口（/api/v0/usage/*）目前属于 DeepSeek 平台前端自用的内部接口，没有对外公开文档或 SLA 承诺。潜在变更风险包括：

• 接口路径版本升级（如 /api/v0/ → /api/v1/）
• 认证方式调整（增加额外 Cookie / CSRF Token / 双因子校验等）
• 响应字段重命名或嵌套结构调整
• 频率限制策略收紧
• 增加反爬机制（验证码、浏览器指纹等）

降低风险的工程策略：

1. 对接口响应做防御式解析——字段缺失时给默认值，避免应用崩溃
2. 将手动粘贴 Token 作为永久兜底路径，即使自动同步彻底失效，用户仍能正常使用
3. 错误信息应友好且可操作，不要只报"请求失败"，要提示"Token 可能已过期，请重新登录获取"
4. 保持关注上游变化，接口变更时社区通常会有反馈，及时跟进并发布更新

4.3 请求频率控制

• 余额接口暂无公开的频率限制数值，但建议间隔不少于 1 分钟
• 用量接口为内部接口，建议保持克制，1～5 分钟刷新一次即可
• 收到 HTTP 429 响应时，做指数退避而非立即重试
• 前端显示"上次刷新时间"，让用户了解数据的时效性

4.4 法律与合规

• 本文涉及的接口分析基于公开可访问的网络请求，仅用于学习和研究目的
• 使用监控工具时请遵守 DeepSeek 平台的使用条款
• 不得将监控工具用于任何违反平台规定的自动化、批量或商业用途
• 作为工具开发者，应在文档中明确告知用户：API Key 和用量 Token 属于敏感个人信息，数据本地存储的风险由用户自行评估

---

5. 总结与工具推荐

核心挑战回顾

实现 DeepSeek 用量余额监控，关键在于理清三个认知：

1. 余额和用量是两个独立的鉴权域——API Key 走官方余额接口，用量 Token 走网页端内部接口，两套凭证互不通用
2. 用量 Token 的自动获取需要"内嵌浏览器 + JS Hook + 有效性验证"的完整链路——这是整个方案中最精巧也最容易出问题的环节
3. 内部接口不保证长期稳定——好的工程实现必须具备兜底路径（如手动粘贴 Token），并在接口变更时有合理的错误处理

自己动手的实现路线图

按以下步骤逐步推进即可：

1. 余额模块：封装 GET /user/balance → 处理好 401/429/5xx → 展示总余额 + 状态指示
2. Token 获取：WebView 登录 + JS Hook 拦截 Authorization → 验证有效性 → 持久化存储
3. 用量模块：调用 /api/v0/usage/amount + cost → 聚合模型和按日维度 → 计算月消费和缓存命中率
4. 可视化：堆叠柱状图展示 7 天趋势 + 模型对比卡片 + 月度概览
5. 体验优化：定时自动刷新 + 系统托盘 + 开机自启 + 单实例保护
6. 安全加固：敏感凭据托管至系统凭据管理器 + 一键清除 + 错误信息不泄露密钥

开源工具推荐

如果不想从零造轮子，以下两个开源项目分别覆盖了 Windows 和 macOS 平台，可直接使用或参考其实现：

工具	平台	技术栈	核心能力
DeepSeekMonitorWindows	Windows 桌面	Tauri 2 + React + Rust	余额查询、用量统计、缓存命中率、7 天趋势图、WebView 自动同步 Token、系统托盘、开机自启
deepseek-monitor	macOS 桌面	Python + Web Dashboard	余额查询、用量追踪、趋势图、Web Dashboard 风格展示

• Windows 版：github.com/isatrix/DeepSeekMonitorWindows
  

• macOS 版：github.com/JayHome137/deepseek-monitor

两个项目均采用 MIT 许可证，可放心使用和二次开发。

---

免责声明：本文所分析的技术方案和推荐的开源工具均非 DeepSeek 官方产品。文中涉及的内部接口系基于平台前端公开网络请求的逆向分析，仅供学习研究。接口可能随时变更，请合理使用，并自行承担因接口变动、账号安全和数据准确性带来的所有风险。API Key 和用量 Token 是敏感凭据，切勿以任何形式公开分享。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/weixin_38514703/article/details/162459471