AI Tools Manager: a Tauri desktop app for juggling many AI accounts

What the app actually manages, platform by platform

The feature list in the README is more specific than the project name suggests. The account side covers Augment, Antigravity, Windsurf, Cursor, OpenAI for both Codex and the API, and Anthropic across Claude Code and the API, with one-click account switching as the headline behaviour. The name of the app is ATM in the repository, package.json and both package manager taps.

Around that sit three features that are not about AI accounts at all. Subscriptions track expiry dates and remaining time, and can send Telegram notifications before a plan runs out. Bookmarks can be added by hand, imported from Chrome, Firefox, Edge or Safari, or pulled from Raindrop.io, with tags, search filtering, cloud sync and a Raycast-style quick search. Email covers iCloud hidden mail addresses for generation, deactivation and deletion, Outlook mail accounts with manual import or OAuth plus token refresh and bulk status checks, and GPTMail random addresses through its own API with polling and history.

That last cluster is worth flagging honestly, because iCloud hidden mail addresses require an iCloud+ subscription and the README says so. It is the one part of the feature set with a hard external dependency, and it also makes clear what kind of user this is aimed at: someone running many accounts across several subscription plans who wants one place to see what is about to expire.

A Tauri 2 shell over Vue 3, Pinia and Tailwind 4

The stack is stated plainly in the README: Tauri 2 with Rust, Vue 3, Pinia, Tailwind 4 and Vite. The repository tree supports that reading. `src-tauri/` holds the Rust side, `src/` the front end, `docs/` a separate documentation site, and `vite.config.js` sits at the root.

`package.json` names the package ATM at version 2.1.7 and shows what the front end leans on. `@tauri-apps/api` and three Tauri plugins, dialog and fs alongside it, provide the native bridge. `@vueuse/core` handles composables, `pinia` the state, `vue-chartjs` and `chart.js` the usage charts, `vue-i18n` the translations, and `pinyin-pro` appears in dependencies rather than devDependencies, which suggests Chinese input handling is a product feature rather than an afterthought. Build tooling is Vite 6 with `@vitejs/plugin-vue`, Tailwind 4 through its Vite plugin, and the Tauri CLI.

The scripts are small and conventional:

"dev": "vite",
"build": "vite build",
"test": "node --test src",
"tauri": "tauri"

Worth noting that `test` runs Node's built-in test runner against `src`, so the front end has tests but they are not run through Vitest or Jest. There is also a `skills-lock.json` at the root, which suggests some part of the assistant tooling around this project is pinned, and `docs:*` scripts that delegate to `pnpm --prefix docs` for the documentation site.

Installing through Homebrew cask, Scoop, or a release package

The README leads with package managers rather than downloads. On macOS the path is a Homebrew tap and cask:

brew tap cubezhao/atm
brew install --cask atm
brew update
brew upgrade --cask atm
brew uninstall --cask atm

On Windows it is Scoop, with a separate bucket repository:

scoop bucket add atm https://github.com/cubezhao/scoop-atm
scoop install atm
scoop update atm
scoop uninstall atm

Release packages are the documented alternative, and the README calls out one specific friction point: on macOS the installed app can be reported as damaged and unopenable, in which case the quarantine attribute is what needs clearing:

sudo xattr -dr com.apple.quarantine /Applications/ATM.app

That is an unsigned or ad-hoc signed app rather than a notarised one, which is worth knowing before you point an installer at it. The project is MIT licensed, has a documentation site at cubezhao.github.io/ai-tools-mng, and around 1,180 stars with 209 forks and four open issues. The last push was on 2026-09-10.

Three build paths: local scripts, Tauri CLI, and Docker profiles

Building from source needs Rust, Node.js and the Tauri CLI, each installed in the documented order. The CLI install is a cargo install:

cargo install tauri-cli

After that, development and release builds are two commands per platform, from `build.ps1` on Windows or `build.sh` elsewhere:

cd ai-tools-mng
npm install
cargo tauri dev

and the production build swaps `dev` for `build`. The platform scripts exist mainly because the same codebase has to produce Windows, macOS and Linux binaries, which a single host cannot always do.

The more interesting route is Docker, and it is the reason `Dockerfile.build`, `Dockerfile.cross` and `Dockerfile.dev` all exist. `docker-compose.yml` defines four services, each behind a profile so nothing runs by default. The `build` profile compiles for Linux and mounts a host directory at `/artifacts`; `cross` builds arm64 as well with `BUILD_ARM64=true`; `dev` mounts the working tree and the target directory for a live development environment with `RUST_LOG=debug`; and `extract` runs an Alpine container purely to list what was produced. Cargo and npm caches are declared as named volumes so rebuilds do not refetch everything.

chmod +x docker/build.sh
./docker/build.sh linux
./docker/build.sh cross
./docker/build.sh dev

For a project of this size, having reproducible cross builds in version control is a genuine convenience rather than an extravagance.

Recent releases are mostly about the gateway and account switching

The three most recent releases, all within a week of each other in September 2026, show what is actually being worked on. v2.1.5 added the ability to import Antigravity accounts from a JSON file, and changed the gateway to intercept upstream server-sent event heartbeats, pushing explanatory annotations to the client during idle periods. v2.1.6 added workbuddy support, turned reasoning progress display on by default, and added a `requires_openai_auth = true` authentication setting for OpenAI. v2.1.7 fixed a daily usage metric that was not resetting across day boundaries, made account dropdowns searchable when adding accounts through the Codex OAuth channel, and fixed a case where the gateway could not use that channel at all.

Read together, those entries describe an application whose real work happens in the plumbing: the gateway, OAuth flows, usage counters and token handling. The visible feature list in the README is a summary of the outcome, not the source of the effort.

The gateway is also where the README's security note matters most. It supports a local passthrough reverse proxy for Codex, and it explicitly limits that to the Codex CLI and Droid. That restriction is a small but telling detail about how the project is meant to be used: as a credential switcher for tools you drive yourself, not as an invisible middle tier for someone else's traffic.

What the repository documents and where it stops

The Chinese README is thorough on installation and building and thin on architecture. It explains every supported platform, both package managers, the release download path, the macOS quarantine workaround, the manual prerequisites, both platform build scripts, the Docker profiles and the manual cargo tauri commands. There is an English README alongside it, and a separate documentation site in `docs/` with its own dev and build scripts.

What is not there is any description of how credentials are stored. For an application whose entire purpose is holding access tokens for paid services across several vendors, that is the first question a security-minded reader will have, and the repository does not answer it in the README, the repository tree or the recent release notes. Nor does it describe what permissions the Tauri app requests, what the Outlook OAuth scope set is, or how the Telegram notification token is handled.

The other gap is upstream drift. Managing accounts for Cursor, Windsurf and Antigravity means depending on how those tools read their own credentials, and any of them can change its local config format in a release. That is a maintenance reality the project cannot avoid, and the September releases show the author responding to exactly that kind of change as it arrives.

Editorial conclusion

The project is worth understanding as an account vault rather than an AI client. It does not talk to a model on your behalf; it holds credentials for the tools you already use, hands them to those tools, and gets out of the way. That framing explains the design: a Rust side for secrets, a Vue and Pinia front end for the lists, and installers through Homebrew cask and Scoop rather than a store listing. What the repository does not settle is how credentials are encrypted at rest or how the OAuth flows behave against a provider that changes them, and neither the README nor the release notes go into that. Install the cask, point it at one account you can afford to re-authenticate, and read the gateway and workbuddy changes in recent releases before importing a full set.

Frequently asked questions

Official sources

1. cubezhao/ai-tools-mng on GitHub
2. License: MIT
3. Project website
4. README
5. Releases