企业官网建设流程全解析

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"}]}

关键字段说明：

实现要点

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

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。两者缺一不可，分别获取、分别存储。

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是数组，第一项包含总消费和每日消费明细。

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

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的示意代码：

constoriginalFetch=window.fetch;window.fetch=function(input,init){try{constheaders=init?.headers||input?.headers;constauth=extractAuthHeader(headers);if(auth)deliverToken(auth);}catch(e){}returnoriginalFetch.apply(this,arguments);};

拦截XMLHttpRequest的示意代码：

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

Token 从 WebView 传回原生层

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

稳健的降级策略：优先使用框架原生 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 凭据安全管理

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

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

推荐做法：

• 桌面应用优先使用操作系统提供的凭据管理服务
• 务必在.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 分钟刷新一次即可
• 收到 HTTP429响应时，做指数退避而非立即重试
• 前端显示"上次刷新时间"，让用户了解数据的时效性

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 平台，可直接使用或参考其实现：

• Windows 版：github.com/isatrix/DeepSeekMonitorWindows
  

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

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

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