Antigravity Tools: A Local Proxy That Turns Web Sessions Into OpenAI, Anthropic and Gemini Endpoints
Professional Antigravity Account Manager & Switcher. One-click seamless account switching for Antigravity Tools. Built with Tauri v2 + React (Rust).专业的 Antigravity 账号管理与切换工具。为 Antigravity 提供一键无缝账号切换功能。
At a glance
- What is it?
- Antigravity Tools is a Tauri v2 desktop application that manages multiple Google and Anthropic web sessions and exposes them through a local Axum server speaking three API dialects. It is useful if you already hold session credentials and want them reachable from coding tools; it is the wrong choice if you need a hosted, multi-tenant gateway.
- Who is it for?
- Adopt Antigravity Tools if you personally hold several Google or Anthropic web sessions and want them reachable from Claude Code, Cherry Studio or Kilo Code through one local port, and you accept the CC-BY-NC-SA-4.0 non-commercial restriction. Do not adopt it if you need a shared team gateway, a hosted service, or a licence that permits commercial redistribution.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: session credentials that no client can speak to
Web sessions for Google and Anthropic products are not API keys. They expire, they carry per-account quota, and they are not reachable through the OpenAI or Anthropic HTTP contracts that most coding assistants expect. Antigravity Tools exists to close that gap on a single machine. The README describes the project as a local AI relay station that converts common web sessions into standardized API interfaces, and the stated audience is developers and AI enthusiasts rather than platform teams. The practical shape of the problem is quota: an account with a depleted Gemini Pro allowance is useless to Claude Code until you switch to another one, and doing that by hand across several browser profiles is the workflow this tool replaces. The dashboard is built around that: it shows average remaining quota for Gemini Pro, Gemini Flash, Claude and Gemini image generation, and recommends the account with the most headroom for a one-click switch.
Architecture: one Axum server in front of a dispatcher and two mappers
The architecture diagram in the README is compact and worth reading literally. External clients such as Claude Code or NextChat connect over OpenAI or Anthropic formats to an Axum server running inside the Tauri application. Middleware handles authentication, rate limiting and logging. A model router maps incoming model IDs. A dispatcher then selects an account, using polling or weighting, before a request mapper converts the payload to the upstream protocol. The response mapper converts back on the return path. Two details in that chain matter for anyone evaluating the design. First, the account selection happens after model mapping, so routing decisions and account decisions are separate concerns and can be reasoned about independently. Second, the proxy is a local process, not a service you deploy. The whole thing ships as a desktop binary, which is why installation is a script rather than a container image. There is no mention of a server-only build, so treating this as infrastructure you can run headless on a shared host is not supported by the material.
Three API dialects and the self-healing retry loop
The proxy exposes /v1/chat/completions for OpenAI-format clients, /v1/messages for Anthropic-format clients including Claude Code CLI, and a Gemini-format path that Google's official SDK can call directly. The README claims compatibility with 99 percent of existing AI applications on the OpenAI path, a figure with no methodology behind it and one you should treat as marketing rather than measurement. The more concrete mechanism is the retry behaviour: when an upstream request returns 429 or 401, the backend is described as triggering automatic retry and silent rotation at millisecond latency. That is the feature that makes multi-account pooling meaningful, because quota exhaustion on one account becomes a routing event instead of a user-visible error. Two related features sit on top of it. Tiered routing orders accounts by type (Ultra, Pro, Free) and quota reset frequency, preferring accounts that reset quickly. Background task downgrade detects requests generated by tools like Claude CLI, such as title generation, and redirects them to a Flash model so that premium quota is not spent on them.
Getting it running: two install commands and the OAuth step
Installation is a single script per platform. On Linux or macOS the README gives curl -fsSL https://raw.githubusercontent.com/lbjlaq/Antigravity-Manager/main/install.sh | bash, and on Windows irm https://raw.githubusercontent.com/lbjlaq/Antigravity-Manager/main/install.ps1 | iex. The script detects operating system, architecture and package manager, then downloads the matching artifact: .deb, .rpm or .AppImage on Linux, .dmg on macOS, NSIS .exe on Windows. The README also notes an advanced form for pinning a specific version through the same script. Piping a remote script into a shell is a normal pattern for desktop tools and also the point where you should read the script before running it, since the install path is outside your package manager's normal review. Account setup uses OAuth 2.0 with both automatic and manual flows: the app generates a copyable authorization link, you complete it in any browser, and the callback is saved automatically, with a manual continue button as a fallback. Bulk import accepts single tokens, JSON backups from other tools, and hot migration from the V1 database. The README does not document the local port number, the API key format the proxy expects from clients, or the config file location, so those are things to check in the app's settings screen rather than in the documentation.
The 100MB payload setting and the Imagen 3 mapping
Multimodal support is handled by translating OpenAI-style size parameters such as 1024x1024 or 16:9 into Imagen 3 specifications, so an existing image client does not need to learn Google's parameter names. The README states the backend accepts payloads up to 100MB and that this is configurable. That number is high for a desktop process and it is the kind of setting that trades memory for capability: a 4K image sent through the proxy will be buffered somewhere, and on a laptop with limited RAM the ceiling you can actually sustain will be lower than the configured one. There is no discussion of streaming behaviour for large payloads or of what happens when the buffer is exceeded. If image recognition at high resolution is part of your workflow, that is the boundary to probe first, not the account-switching features.
Licence, maintenance cadence and what the repository does not tell you
The repository metadata reports the licence as NOASSERTION, while the README badge states CC-BY-NC-SA-4.0. Those two signals disagree, and the badge is the more specific of the two. Read as CC-BY-NC-SA-4.0, the licence permits sharing and adaptation with attribution, prohibits commercial use, and requires derivative works to carry the same licence. That rules out bundling the tool into a paid product or using it to serve paying customers, and it is a materially different situation from a permissive licence. This is a description of the licence text, not legal advice; check the LICENSE file in the repository before relying on it. Maintenance looks active: releases v4.6.8, v4.6.9 and v4.7.0 all landed within four days of each other in September 2026, and the last push to main is timestamped the same day as v4.7.0. A cadence that tight cuts both ways. Fixes arrive quickly, and so do changes. There is no stated support window, no migration guide for the V1 to V2 database move beyond the mention of hot migration, and no changelog excerpt in the README describing what changed between v4.6.9 and v4.7.0. The README also lists four sponsors and their affiliate links, which is worth knowing when reading feature descriptions that name those vendors' services.
Where a hosted gateway such as LiteLLM fits differently
The obvious comparison is a self-hosted LLM gateway like LiteLLM. The difference is not features, it is the trust boundary. LiteLLM is a Python server you deploy, configure with provider API keys, and share across a team, with the operational work that implies: a database, a deployment target, and secrets management. Antigravity Tools runs on your desktop, uses OAuth sessions you authorized yourself, and keeps credentials local to that machine. That makes it a poor fit for a team that needs one endpoint for everyone, because there is no documented multi-user mode, no role separation, and no server deployment path in the README. It also makes it a poor fit for anyone whose compliance rules forbid storing session tokens in a desktop application's local database. The reverse is true as well: if your accounts are personal web sessions rather than issued API keys, a conventional gateway has nothing to authenticate with, and Antigravity Tools is addressing exactly that case. Pick based on what you hold, not on which feature list is longer.
Editorial conclusion
Adopt Antigravity Tools if you personally hold several Google or Anthropic web sessions and want them reachable from Claude Code, Cherry Studio or Kilo Code through one local port, and you accept the CC-BY-NC-SA-4.0 non-commercial restriction. Do not adopt it if you need a shared team gateway, a hosted service, or a licence that permits commercial redistribution. Before installing, verify three things in the repository: the exact licence file, whether your platform has a signed build among the .deb, .rpm, .AppImage, .dmg and NSIS .exe artifacts, and whether the upstream v4.7.0 release notes mention any breaking change to the /v1/messages or /v1/chat/completions contract.
Community notes