
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零或欠费为falsecurrency货币类型国内用户CNY海外用户USDtotal_balance总余额赠送余额 充值余额的合计granted_balance赠送余额注册赠送、活动赠送等不可提现topped_up_balance充值余额用户实际充值的金额实现要点调用余额接口只需关注三件事超时控制建议设置 1015 秒超时避免网络波动时长时间挂起HTTP 状态码分类处理401说明 Key 无效或已过期429说明请求过频需等待5xx为服务端错误余额展示将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的示意代码constoriginalFetchwindow.fetch;window.fetchfunction(input,init){try{constheadersinit?.headers||input?.headers;constauthextractAuthHeader(headers);if(auth)deliverToken(auth);}catch(e){}returnoriginalFetch.apply(this,arguments);};拦截XMLHttpRequest的示意代码constoriginalSetHeaderXMLHttpRequest.prototype.setRequestHeader;XMLHttpRequest.prototype.setRequestHeaderfunction(name,value){if(String(name).toLowerCase()authorization){deliverToken(value);}returnoriginalSetHeader.apply(this,arguments);};Token 从 WebView 传回原生层不同框架有不同的 IPC 通道选择框架推荐 IPC 方式Tauri (Rust)invoke/emit或降级到document.title轮询ElectronipcRenderer.send()直接通信WPF/WinForms (WebView2)window.chrome.webview.postMessage()macOS WKWebViewwindow.webkit.messageHandlers.{name}.postMessage()Flutter (webview_flutter)JavaScriptChannel回调稳健的降级策略优先使用框架原生 IPC 通道同时将document.title作为降级通道——写入约定格式的字符串如PREFIX:year:month:tokenhost 侧定时轮询窗口标题。这种双通道策略兼容性最好不依赖特定框架能力。验证环节不可或缺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 内核的 WebViewWebView2 / CEF / Electron为例缓存文件通常为无扩展名的二进制/文本混合文件存储在类似Cache/Cache_Data/的目录下。扫描思路如下遍历缓存目录下的所有文件以共享读模式打开允许 WebView 同时写入读取内容为文本搜索token:长字符串模式用上下文特征如同时包含id_profile和feature_gates过滤出真正的用户 token方式二手动提取 Token兜底方案当自动同步因网络波动或平台更新等原因失效时手动提取是最可靠的兜底路径在任意浏览器中登录 platform.deepseek.com按F12打开开发者工具切换到 Console 面板输入以下命令并回车JSON.parse(localStorage.userToken).value复制控制台输出的字符串粘贴到你的监控工具中保存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 / 双因子校验等响应字段重命名或嵌套结构调整频率限制策略收紧增加反爬机制验证码、浏览器指纹等降低风险的工程策略对接口响应做防御式解析——字段缺失时给默认值避免应用崩溃将手动粘贴 Token 作为永久兜底路径即使自动同步彻底失效用户仍能正常使用错误信息应友好且可操作不要只报请求失败要提示Token 可能已过期请重新登录获取保持关注上游变化接口变更时社区通常会有反馈及时跟进并发布更新4.3 请求频率控制余额接口暂无公开的频率限制数值但建议间隔不少于 1 分钟用量接口为内部接口建议保持克制15 分钟刷新一次即可收到 HTTP429响应时做指数退避而非立即重试前端显示上次刷新时间让用户了解数据的时效性4.4 法律与合规本文涉及的接口分析基于公开可访问的网络请求仅用于学习和研究目的使用监控工具时请遵守 DeepSeek 平台的使用条款不得将监控工具用于任何违反平台规定的自动化、批量或商业用途作为工具开发者应在文档中明确告知用户API Key 和用量 Token 属于敏感个人信息数据本地存储的风险由用户自行评估5. 总结与工具推荐核心挑战回顾实现 DeepSeek 用量余额监控关键在于理清三个认知余额和用量是两个独立的鉴权域——API Key 走官方余额接口用量 Token 走网页端内部接口两套凭证互不通用用量 Token 的自动获取需要内嵌浏览器 JS Hook 有效性验证的完整链路——这是整个方案中最精巧也最容易出问题的环节内部接口不保证长期稳定——好的工程实现必须具备兜底路径如手动粘贴 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 平台可直接使用或参考其实现工具平台技术栈核心能力DeepSeekMonitorWindowsWindows 桌面Tauri 2 React Rust余额查询、用量统计、缓存命中率、7 天趋势图、WebView 自动同步 Token、系统托盘、开机自启deepseek-monitormacOS 桌面Python Web Dashboard余额查询、用量追踪、趋势图、Web Dashboard 风格展示Windows 版github.com/isatrix/DeepSeekMonitorWindowsmacOS 版github.com/JayHome137/deepseek-monitor两个项目均采用 MIT 许可证可放心使用和二次开发。免责声明本文所分析的技术方案和推荐的开源工具均非 DeepSeek 官方产品。文中涉及的内部接口系基于平台前端公开网络请求的逆向分析仅供学习研究。接口可能随时变更请合理使用并自行承担因接口变动、账号安全和数据准确性带来的所有风险。API Key 和用量 Token 是敏感凭据切勿以任何形式公开分享。