Draculabo/AntigravityManager: an account pool wrapped around Antigravity

The problem the README opens with

The README does not start with a feature list, it starts with complaints. It asks whether you have hit these problems when using Antigravity IDE: a single account quota that runs out quickly and needs frequent manual switching, managing multiple Google and Claude accounts being cumbersome, not knowing how much quota is left on the current account, worrying about missing quota reset times, and needing a reliable local API proxy for development tools.

That framing tells you the design brief. This is not an IDE and not an editor extension. It is a companion application that assumes you already work in Antigravity and wants to remove the friction of doing so. The repository description is blunter still, calling it a powerful Electron based application designed to manage accounts and processes for the Antigravity application.

The stack badges name Electron 19, React 20, TypeScript and Tailwind CSS, and the interface is described as built with React, TailwindCSS and Shadcn UI, with a dense horizontal compact layout chosen specifically to maximize how many accounts are visible at once. That is a monitoring tool's aesthetic, not an authoring tool's. The repository has 2,255 stars and 274 forks, only 25 open issues, is not archived, uses main as the default branch, and was last pushed on 2026-09-20. Topics run from account-manager and antigravity-ide through antigravity-tools and antigravity2api to gemini-api, which is a fair map of the project's ambitions.

Quota, thresholds and the five minute loop

The quota monitoring and auto switching features are described together because they are one mechanism.

Monitoring covers multiple models, with gemini-pro and claude-3-5-sonnet named as examples, rendering usage as visual progress bars with color indicators, and supporting both automatic and manual refresh. Status per account is tracked as Active, Rate Limited or Expired, alongside avatar, email, status and last used time. Smart sorting lets you order the pool by recently used, overall quota, or specific model groups.

Switching triggers on two conditions: quota falling below five percent, or the account becoming rate limited. Behind that sits an unlimited pool mode with smart backup selection, and a background monitoring loop that runs every five minutes. Desktop notifications are configurable so you can set a threshold for a model and be told when usage drops below it.

The five minute interval is the number to reason about. It sets how stale the displayed numbers can be, and therefore how long an account can sit above your threshold before the switch happens. If you are running an agent loop against the local proxy rather than a person watching the screen, that interval is your effective rate limiting granularity.

The local proxy turns this into an API server

The feature most likely to change how you use the app is the local API proxy, which is OpenAI and Anthropic compatible with a configurable port and request timeout, and supports model mapping so a request for Claude can be routed to Gemini.

The developer tooling around it is what makes the feature usable. The app generates cURL and Python code from your configuration, shows visual service status monitoring, and offers one-click API key regeneration. The v0.20.0 release extended this area with a dynamic proxy example model catalog and an OpenCode management UI alongside dynamic API examples, and added configurable auto-switch models and priorities under cloud accounts, which is how you decide which model an account should be switched for.

Per-account proxy routing is also supported, letting individual accounts go out through their own HTTP or SOCKS5 proxy. For anyone running several accounts with distinct network histories, that is a requirement rather than a nicety.

Worth being plain about the boundary here. A proxy that fronts pooled accounts and switches between them when one is rate limited is built to work around a provider's per-account limits. Whether that is acceptable under your agreement with Google or Anthropic is a decision you have to make yourself, and it is worth making it before you point a production workload at port 1455.

Credentials, backups and what gets stored

A tool holding OAuth tokens for many accounts at once has to answer the storage question carefully, and this one describes its answer rather than leaving it implied.

The security feature block lists AES-256-GCM encryption for sensitive data, integration with the operating system's native credential manager, and automatic migration of legacy plaintext data. The v0.19.0 release also added tolerance for a missing storage.json when toggling credential store settings, which is the kind of fix that only shows up on machines where the credential store has been partially initialized.

Account backup works on a snapshot model. You capture snapshots of account state, switch between saved accounts quickly, and view, organize and delete them. Batch operations cover refresh and delete across multiple accounts. Export and import uses JSON with schema validation and deduplication, which matters if you are merging pools from two machines.

There is also IDE Sync, which automatically scans and imports accounts from the IDE's state.vscdb file. That is a direct read of the IDE's own state store, and it is the feature most worth understanding before you enable, because it is how accounts move from the IDE into the pool without manual entry.

A build pipeline with architectural guardrails

The package.json scripts section is where this project stops looking like a typical Electron wrapper.

+  "scripts": {
+    "start": "electron-forge start",
+    "start:performance": "node scripts/start-performance-recorder.mjs",
+    "start:otel:console": "node scripts/run-with-otel.mjs console -- npm start",
+    "start:otel:otlp": "node scripts/run-with-otel.mjs otlp -- npm start",
+    "start:otel:off": "node scripts/run-with-otel.mjs off -- npm start",
+    "package": "electron-forge package",
+    "make": "electron-forge make",
+

+Standard Electron Forge entry points, plus three tracing modes that run the app under OpenTelemetry to a console, to an OTLP endpoint, or off, and a separate performance recorder entry point. That is observability added by someone who has profiled this app.

The rest of the script list is more unusual still. There are scripts to check agent contracts, to enforce and report runtime boundaries, to enforce a root IPC boundary specifically, to analyze the import graph, to check change scope, to serve a local update feed, and to audit the Windows x64 build size. Those roll up into a check:governance script that runs the contract tests, change scope tests, import graph tests, runtime boundary tests and type boundary tests together, and a check:ci that layers static checks and the test suite on top.

The repository tree explains where that culture comes from. Alongside src/ and types/ there are AGENTS.md, CLAUDE.md, .agent/, .agents/, .claude/ and .codex/ directories, an openspec/ directory, and doctor.config.json. This is a codebase that has written its conventions down and then built scripts that fail the build when the conventions are violated, which is a reasonable answer to the class of bugs Electron apps usually accumulate around IPC boundaries.

Windows has been the sore spot

Three of the three most recent releases touch Windows, and reading them in order tells you what kind of project this is.

v0.18.1 on 21 June 2026 was a single fix, aligning the renderer isolation model for Windows compatibility. Two days later v0.19.0 added a start in tray option with localization, then fixed an opt-in set of GPU-safe Chromium switches to stop a Windows startup crash that manifested as a white screen followed by the process closing, and added tolerance for the missing storage.json file mentioned earlier.

v0.20.0 on 10 August 2026 moved to features: an Arch Linux PKGBUILD for AUR deployment, cache and binary tools in an antigravity-runtime package, configurable auto-switch models and priorities, import of verified local accounts, the proxy gateway model catalog and OpenCode management UI already mentioned.

The pattern is a project whose Linux and macOS support is settled and whose Windows support is an ongoing negotiation with Chromium and the credential store. If you are on Windows, the honest advice is to read the release notes before upgrading rather than after, because the fixes land in narrow patches. If you are on Linux, v0.20.0 added an AUR package, which is the more interesting release for you. The repository also carries flake.nix and flake.lock for Nix users.

Editorial conclusion

This repository is best understood as an operations console for one specific pain point. Antigravity IDE binds you to a single account, a single quota bar and a single reset time, and the moment that quota runs out the workflow stops. Antigravity Manager holds many accounts instead, shows what each one has left, and switches to the next one when the current account drops below five percent or gets rate limited. The features list is long, but that is the core, and the rest either serves it, such as the snapshot system for fast switching and the batch refresh, or extends it into a developer tool, such as the local OpenAI and Anthropic compatible proxy with model mapping and generated cURL and Python snippets. Three implementation details deserve a closer look before you install it. Credentials are held with AES-256-GCM encryption backed by the operating system credential manager, with automatic migration of older plaintext data, which is the right default for a tool that stores OAuth tokens for many accounts at once. Per-account HTTP and SOCKS5 proxy routing is supported, which matters if your accounts have different network histories. And the build pipeline is unusual for an Electron app, with explicit scripts for verifying runtime boundaries, enforcing a root IPC boundary, checking agent contracts and gating changes on scope, which suggests a codebase that has had architectural arguments and wrote them down. The license field reads NOASSERTION in the repository metadata while a LICENSE file sits in the tree, so check that file before you build on this. The current tag is v0.20.0, and Windows startup stability has been an ongoing theme across the last three releases.

Frequently asked questions

Official sources

1. Draculabo/AntigravityManager on GitHub
2. Issues
3. README
4. Releases