Someone on V2EX posted a tool this week that a lot of us recognized instantly. They'd subscribed to more than one AI coding plan — 智谱, DeepSeek, Kimi, 小米, 火山 among them — and the remaining quota for each was scattered across separate dashboards. Every check meant logging into each vendor in turn. So they built MyToken Dashboard, a macOS menu-bar app that shows a combined balance up top and per-vendor detail underneath. Same source, multiple accounts. Custom endpoints too: a built-in login window grabs the cookie and the JSON response, and you click the fields you want to map.
The stack is Tauri 2 plus Rust, and the author was explicit about why they didn't ship a packaged binary — the credentials stay on the machine, so they open-sourced it instead and told people to build it themselves. That's the honest part, and it's worth pausing on. A second commenter in the same thread mentioned they'd solved the identical itch with a GNOME Shell extension. The need is real and it's cross-platform. The question for anyone wanting to rebuild or extend this idea is: what part of it actually has to live on your laptop, and what part is just plumbing that you're re-implementing per machine?
The signal underneath the tool
The broader pattern across the board this week is fragmentation. People are stringing together WorkBuddy plans into Claude Code, comparing video-generation memberships, juggling registration workarounds for one service after another. The common thread is that a working developer now holds credentials and quota across a handful of vendors, and nobody's dashboard covers all of them. MyToken Dashboard is one honest attempt at that consolidation problem.
But consolidation has two halves that get glued together in a desktop app and shouldn't be. One half is genuinely local: the act of logging in through a vendor's own flow, capturing the session cookie, and holding that secret. The other half is durable and boring in a good way: the configuration that says "this vendor's balance lives at this endpoint, in this JSON field," the record of what the number was yesterday, and the view that renders it. That second half doesn't care where it runs. It's the part you keep rewriting every time you switch machines or want a teammate to see the same numbers.
What stays on the device — and stays there for a reason
Be blunt about the boundary, because a hosted platform can't own it. The cookie-grabbing native shell — the embedded login window that captures a live session against each vendor — belongs on-device. That's not a limitation to route around; it's the correct design. Session cookies and tokens are the crown jewels here, and the original author's decision to keep them local and skip a packaged binary was the right call. VicroCode's confirmed capabilities don't include running a native browser context to harvest a vendor login, and you wouldn't want your provider credentials leaving your machine to a third party anyway. So that piece stays where it is. Flag it clearly to anyone you share the rebuild with.
What you can lift out is everything downstream of "I already have a valid token."
Rebuilding the durable half
Start with the fetcher. A config-driven Python script that takes an endpoint, a set of headers or a token you supply at call time, and a field path, then pulls the current balance — that's a clean fit for a place to run Python online. No native shell, no cookie capture; just "given a credential, hit this URL and read this field." You feed it the token; it never has to store one long-term. Keep the fetch logic generic so adding a new vendor is a config entry, not a code change.
The endpoint-and-field map is the part MyToken Dashboard handles with click-to-select mapping, and it's exactly what a small relational store is for. An editable SQLite editor lets you keep one table of vendors, endpoints, and field paths, and a second table of balance snapshots over time — the history layer the menu-bar app doesn't really keep. That history is the quiet upgrade: instead of a single "remaining" number, you get a trend, so you can see burn rate across plans and notice when one's about to run dry. Editing the map by hand when a vendor changes its API beats rebuilding a binary every time.
Then the view. The menu-bar total becomes a plain hosted dashboard: total across all plans up top, per-vendor detail below, plus the history you've been accumulating. Being able to run HTML online means the same dashboard is reachable from any machine and shareable with a teammate, without asking each of them to compile a Rust app. It reads from the SQLite snapshots the fetcher writes.
The trade-offs worth naming
This split trades a bit of convenience for honesty and portability. The original tool's single killer move — capture the cookie for you inside the app — is precisely the move you can't host, so a rebuild asks you to bring the token yourself (paste it, or run a small local step that produces it). That's more friction per refresh. In exchange you get a persistent history layer, an endpoint map you can edit without recompiling, and a dashboard that isn't tied to one OS or one laptop.
I have not built and measured this rebuild, so treat any claim about refresh speed, reliability, or how gracefully it handles a vendor changing its auth scheme as unverified. Vendors change JSON shapes and tighten session handling without notice; the editable map softens that, but nothing makes it disappear. And whatever you do, keep the credential-handling on your own machine. The moment a balance aggregator starts holding other people's provider tokens on a shared host, you've built a very different, much riskier thing than the tidy little menu-bar helper this started as.