DeepSeek Monitor Windows buys its usage numbers with a token scraped from the WebView2 cache

The API key buys the balance, the usage token buys the numbers

Two credentials sit behind this app, they come from different places, and they are not interchangeable.

The API key comes from the API Keys page of the DeepSeek open platform, and it is what the balance query uses, going through DeepSeek's official balance interface. The usage token is a different animal. DeepSeek does not currently publish an API for account level usage statistics, so the usage figures are obtained by signing into the web page and taking a session credential that reaches the platform's usage interface instead, and the README asks for it to be handled as a sensitive session credential.

That split dictates the shape of the settings page. You can end up with a working balance and no charts at all, because the balance path and the usage path fail independently. Both credentials can be saved, cleared and, for the key, checked against the balance endpoint. Everything else on screen comes through the second one: current month spend, per model token totals, request counts, cache hits, cache misses and output tokens, for the V4 Flash and V4 Pro model families, with a seven day spend trend and a model detail page on top.

Usage arrives by logging in and scraping the WebView2 cache

The automatic path is a login window. The settings page offers a button labelled 方式一：网页登录自动同步, which means web login with automatic sync. Pressing it opens a DeepSeek login window, and once the sign in succeeds the app tries to extract the usage token from the WebView2 cache, a directory that normally lives at `%LOCALAPPDATA%\com.deepseek.monitor.windows\EBWebView`. When that works, the month spend and token figures refresh without further action.

The second button, 方式二：手动粘贴 token, exists because the first one can fail. It asks for the token to be pasted in, and the page instructions tell you where to read it from: `JSON.parse(localStorage.userToken).value` in the browser console, saved as the fallback when automatic sync does not produce a token.

The token can expire, and the documented recovery is to repeat the web login sync or paste a fresh one. The project is direct about why this fragility exists, in its own disclaimer: DeepSeek's page structure, login state, WebView2 cache and internal usage interface can all change, and long term availability is not promised. The extraction reads from a browser cache directory rather than from any documented endpoint, which is exactly the kind of dependency that disappears without notice.

config.json holds both credentials without encryption

The configuration file is `%APPDATA%\DeepSeekMonitorWindows\config.json`, and it stores the API key and the usage token unencrypted.

The README spends more words on what not to do with that file than on anything else in its data section: do not commit, share or back it up, do not publish key contents taken from screenshots, logs or configuration files, and clear both credentials from the settings page when the machine is shared. The WebView2 cache directory next to it is named as local runtime data that should not be committed either.

The ignore list matches that advice. `.gitignore` covers `node_modules/`, `dist/`, `src-tauri/target/`, `.env`, `.env.local`, `.env.*.local`, `.npmrc`, `*.log`, `*.err.log`, `*.out.log`, `test-output/`, three root level screenshots named `dashboard-mvp.png`, `settings-mvp.png` and `detail-mvp.png`, the WebView2 cache and local run configuration, plus IDE settings and system temp files.

So the security posture is candid and thin at once. A desktop app with a credential store would keep the key out of a plain JSON file, and nothing here suggests one is planned. What you get instead is a readable path, a readable file, and a warning label.

Build Tools are located automatically, the MSVC toolchain is not

Building from source needs three toolchains: Node.js 18 or newer with npm, Rust 1.77.2 or newer with the MSVC toolchain advised, and Visual Studio Build Tools 2022 with the Desktop development with C++ component selected.

The detection is uneven, which is the part that trips people up. `npm run tauri:dev` and `npm run tauri:check` are said to probe the local VS Build Tools installation themselves, with no fixed path to configure by hand. `npx tauri build` is different: the terminal running it has to be able to use the Rust MSVC toolchain already. When the C++ component is missing, the failure names itself, `Visual Studio Build Tools not found`, and the answer is the same in every case: install Build Tools 2022 and tick Desktop development with C++.

The development loop itself is four lines:

git clone https://github.com/Joyi-code/DeepSeekMonitorWindows.git
cd DeepSeekMonitorWindows
npm install
npm run tauri:dev

After that, `npm run tauri:check` is the check pass and `npx tauri build` produces the installer. The Tauri packaging target is configured as NSIS, and the artifact lands in `src-tauri/target/release/bundle/nsis/`.

Both Tauri npm scripts are PowerShell wrappers

package.json shows how little of the build is plain JavaScript tooling. `dev` is `vite --host 127.0.0.1`, `build` is `tsc && vite build`, and `preview` is `vite preview --host 127.0.0.1`. The two Tauri entries are not npm builtins at all: `tauri:check` runs `powershell -ExecutionPolicy Bypass -File scripts/tauri-check.ps1` and `tauri:dev` runs `powershell -ExecutionPolicy Bypass -File scripts/tauri-dev.ps1`.

That is what the `scripts/` directory in the tree is for, and it is also why ExecutionPolicy Bypass appears in both commands, since a locked down Windows policy otherwise stops the script before it starts.

The runtime dependencies are React 18, React DOM 18, the Tauri JavaScript API 2 and lucide-react. The Rust side pins tauri 2.11 with the tray-icon feature enabled, alongside tauri-plugin-log, tauri-plugin-single-instance, reqwest 0.12 with json, serde, serde_json and log. Development dependencies are exact versions rather than ranges for the parts that break builds: typescript 5.6.3, vite 5.4.11, @vitejs/plugin-react 4.3.4, @types/react 18.3.12 and @types/react-dom 18.3.1, while the Tauri packages use caret ranges.

A menu bar widget rebuilt as a tray entry

This is a port, and the README says so in a comparison table rather than hiding it. The original project it takes its ideas from is a macOS application written in Swift, SwiftUI, AppKit and WidgetKit, living in the menu bar with a desktop widget, monitoring DeepSeek V4 Flash and Pro balances, token usage and spend. This repository reimplements that for the Windows desktop on Tauri 2, React 18, TypeScript and Rust, and the table walks through the target platform, core stack, main purpose, launch method and implementation approach, all of which change.

What survives the crossing is visible in the interface. The UI reuses the original visual direction and adapts it to a Tauri window on Windows. The menu bar presence becomes a Windows tray entry, and the main window is kept out of the taskbar by default, which is the closest equivalent a Windows port can offer. Model coverage stays on V4 Flash and V4 Pro, and the license is MIT, the same license the original project declares.

Two smaller details say how the port was made. The README exists in Chinese and English as two files, and the author states plainly that the project is not an official DeepSeek product, which is the correct thing to state when a third party app asks for platform credentials.

v1.0.1 fixed a bug that was a missing plugin

The changelog reads like a support log, and the two June releases are one day apart.

v1.0.0 was the first formal release, covering DeepSeek API balance queries, platform usage statistics, spend trends, the Windows tray entry, and API key and usage token management. v1.0.1, dated 7 June 2026, fixed duplicate launching. With the app already running, clicking the icon or the exe again kept starting new processes, a report credited to a member of a Douyin fan group, and the repair routes through tauri-plugin-single-instance, a single instance guard, so a second launch raises the existing main panel instead of opening another window.

v1.1.0, dated 8 June 2026, added the cache hit, cache miss and output token breakdown, a light skin toggle on the main panel that remembers the choice, and the version number on the settings page. The historic v1.0.1 and the older installers are deliberately kept so that a user can roll back and trace versions.

That decision shapes the install instructions as well: overwriting a new version needs no uninstall of the old one. The file to download is `DeepSeekMonitorWindows_1.1.0_x64-setup.exe` from GitHub Releases, x64 only, and a SHA256 checksum is published next to it for verification.

The branch moved two months after the last tag

The release history stops in June while the branch keeps going. v1.0.1 landed on 7 June 2026, v1.1.0 on 8 June, and the last push to the default branch, master, is dated 11 August 2026, so the tree has moved well past the newest tag without a numbered release following it.

The top level is small and describes the shape of the project: `src/` for the React and TypeScript frontend, `src-tauri/` for the Rust backend, `public/` for DeepSeek icons and static assets, `screenshots/`, `scripts/` for the Windows development scripts, `index.html`, `vite.config.ts`, `tsconfig.json`, `package.json` with its `package-lock.json`, the two README files and the MIT LICENSE. Inside `src-tauri/` the division is `src/lib.rs` for API calls, config storage, tray and web login sync, `tauri.conf.json` for window, bundling and security settings, `Cargo.toml` for Rust dependencies, and a `capabilities/` directory for Tauri permissions. The layout block in the README stops partway through the list, right after package.json, so whatever follows it is not shown there.

Running the app needs Windows 10 or Windows 11 and the Microsoft Edge WebView2 Runtime. Windows 11 usually has it already, and on Windows 10 it is a separate install when missing, which makes it the one prerequisite an x64 installer cannot satisfy on its own.

Editorial conclusion

This app suits a Windows user who wants DeepSeek spend and token counts on the taskbar without writing a script, and who is willing to log into the DeepSeek web page once a week. It does not suit a machine where a plain text file holding both credentials is unacceptable, and it does not suit anyone who needs a guaranteed data source, since the project itself says DeepSeek's pages, login state and internal usage interface can change at any time. Before trusting it, verify the installer against the published SHA256, clear both credentials after use on a shared computer, and keep the release history in mind, because the newest tag is from June 2026 while the branch has moved on since.

Frequently asked questions

Official sources

1. Issues
2. Joyi-code/DeepSeekMonitorWindows on GitHub
3. License: MIT
4. README
5. Releases