Antigravity Panel: a quota dashboard and cache manager for the Google Antigravity IDE

The quota wall problem Antigravity Panel targets

Antigravity IDE routes work through several models, and the quota is not a single number. The extension's own description groups usage by provider-defined quota pools while keeping individual model identities visible in a model view, which tells you the underlying accounting is per pool and per model, not one global counter. If you are switching between Gemini, Claude and GPT inside one session, the first sign that you have run out is usually a failed request. Antigravity Panel exists to move that signal earlier.

The second problem is disk. The extension exposes two cache categories by name: Brain Tasks, which the README describes as AI conversation caches with task size, file count and creation date, and Code Context, described as code analysis caches per project. Neither is something you can inspect from the IDE's own UI according to the documentation. The panel adds a preview for images, markdown and code files, and one-click deletion that also closes related editor tabs.

The audience is narrow on purpose. The package declares extensionKind as workspace and ui and an engines entry of vscode ^1.104.0, so it is an editor extension, not a CLI or a standalone service. If you do not run Antigravity IDE, nothing here applies to you.

How the dashboard reads quota and builds the runway number

The quota display is a status bar item plus a sidebar webview. The README states the status bar shows remaining quota with green, yellow and red indicators, the cache size, and a warning state when the quota connection fails. Hovering gives all model quotas and reset times. The warning and critical thresholds default to 40 percent and 20 percent and are configurable.

The analytics card is more interesting because of what it refuses to do. It charts reported quota changes over a window of 10 to 120 minutes, adaptively grouped into at most about 24 intervals, and the README says the card stays hidden until the first positive change is recorded. That is a deliberate choice: no chart until there is something real to plot, rather than an empty axis.

History retention has two tiers. The latest 24 hours keep raw samples; anything older is downsampled to 5-minute intervals, and the whole window is 14 days with persistent storage. Two derived numbers come out of this: usage rate in percentage points per hour, and runway prediction, described as estimated time until quota exhaustion. Both inherit the resolution limits of the underlying samples, so a runway figure computed from downsampled history is coarser than one from the last hour.

Credits are tracked separately as Prompt Credits, used for conversation input and result generation, and Flow Credits, used for search, modification and command execution. Static Prompt and Flow rows are hidden by default, Google One AI subscription credit stays visible, and the rows come back with the tfa.dashboard.showCreditsCard setting.

Installing Antigravity Panel and reading your first quota card

The repository publishes to Open VSX under the publisher n2ns, and the README links an Open VSX downloads badge for the extension. The homepage listed in package.json is n2ns.com, and the panel's own page there is the canonical place the project points to. The README does not spell out a marketplace search string, so the reliable route is the Open VSX entry for n2ns.antigravity-panel.

After install, the extension activates on onStartupFinished and adds an activity bar container with the id tfa-sidebar. That is where the webview lives.

If you want the commit generator, the README's setup step is a command rather than a settings field. Run it from the command palette:

Antigravity Panel: Set Anthropic API Key

The README says to get an API key from the Anthropic Console first if you plan to use Claude for commit messages. The alternative path is a local LLM, which the README lists as the other option in the same feature.

For the CDP fallback used by auto-accept, the IDE has to be started with a debugging port. The README gives a Windows launcher that kills existing instances first:

@echo off
taskkill /F /IM Antigravity.exe /T 2>nul
start "" "D:\Develop\Antigravity\Antigravity.exe" --remote-debugging-port=9222

On macOS or Linux the README gives a shell equivalent that kills the process and relaunches the Electron binary with the same port:

#!/bin/bash
pkill -f "Antigravity"
/Applications/Antigravity.app/Contents/MacOS/Electron --remote-debugging-port=9222 &

What you should see after a successful start is the sidebar container in the activity bar and, once the quota connection succeeds, remaining quota in the status bar. If the connection fails, the status bar shows a warning state instead of a number, which is the signal to open the diagnostics view. The README mentions built-in connection check and error reporting but does not document what each diagnostic reports.

Auto-accept: two code paths, and only one of them checks anything

The hands-free mode is toggled by a Rocket switch in the sidebar. It accepts agent-suggested terminal commands and file edits. The README describes the implementation as preferring registered IDE commands and falling back to a panel-scoped CDP path for controls the extension API does not expose.

Command discovery is runtime rather than hardcoded. Accept commands are matched against what the running IDE actually registers, and the README notes that IDs differ between Antigravity 1.x and 2.x, which is why the strategy is written this way. That is a sensible answer to version drift.

The safety story is where the design gets uneven. On the CDP path, each pass locates and scans the current Agent Panel once, leaves no page-side observers or timers behind, and uses a short DOM-node timestamp to avoid immediate repeat clicks. The README also states that CDP interactions leave destructive-looking action cards for manual review. Then it states the limitation plainly: the command-API path cannot inspect pending command text and is therefore not covered by that check. So the path that is normally used is the one without the destructive-action filter, and the path with the filter is the fallback.

The README's own framing is that auto-accept remains a trust-the-agent feature and should stay off for untrusted or prompt-injection-prone tasks. Treat that as the operating instruction, not a disclaimer.

Where Antigravity Panel is the wrong tool

The extension is bound to one IDE. Every capability reads Antigravity's quota reporting or drives Antigravity's agent panel. There is no documented export of the 14-day history, so the analytics are for looking at, not for feeding into a cost model or a team dashboard. If you need quota data in a billing pipeline, this is not the source.

The runway prediction is an estimate built on reported quota changes, and the README does not describe how it handles resets, plan changes or long idle periods. A number that says you have two hours left is a projection from recent consumption, not a guarantee, and the documentation does not claim otherwise.

Auto-accept is the clearest case for opting out. If your workflow involves agent-suggested commands you would not run yourself, the command-API path will accept them without reading the text, per the README's own limitation. Also note the CDP fallback requires relaunching the IDE with --remote-debugging-port=9222, which opens a debugging endpoint on your machine. The README frames it as needed only when the command API is unavailable due to webview sandboxing, but the launcher scripts it provides always pass the flag.

Finally, the project's last push was on 2026-07-25, with v2.7.3 released the same day. That is recent enough that the codebase is moving, but it also means the extension tracks an IDE that changes underneath it, and the README's own note about command IDs differing between Antigravity 1.x and 2.x shows how quickly that surface moves.

Compared with a plain Antigravity setup and with generic VS Code monitors

The baseline alternative is Antigravity's own UI. The IDE shows quota somewhere, but the README's framing is that you get real-time status with visual thresholds, a status bar readout, reset times on hover, and history that survives restarts. The difference is persistence and thresholding, not access to data the IDE hides entirely.

A generic VS Code usage or token monitor is the other option. Those extensions are built around API keys and per-request token accounting, which is a different model from Antigravity's provider-defined quota pools. A token counter will tell you what a request cost; it will not tell you how much of a pool remains or when the pool resets. Antigravity Panel reads the pool state, which is why its runway number is possible at all.

For commit messages, the comparison is with the IDE's built-in generate feature. The README describes the extension's generator as a workaround for when that built-in is unavailable, and offers two backends: a local LLM or Claude via an Anthropic API key. That is a fallback, not a replacement, and the documentation presents it that way.

On cache cleanup, the alternative is deleting directories by hand. The extension's contribution is the preview and the size and file-count metadata before deletion, plus closing related editor tabs afterward. If you are comfortable with a file manager, you lose convenience rather than capability.

Licence, maintenance and the cost of keeping up

The project is Apache-2.0, and package.json carries the same identifier. That permits commercial use and modification with the usual notice and patent terms, but the repository also asks for sponsorship through GitHub Sponsors and Ko-fi, which is a funding request rather than a licence condition. Nothing in the licence text changes because of it. For anyone embedding this in a product, the practical question is the trademark and naming side, not the copyright grant, and that is a question for your own counsel rather than something the README answers.

Upgrade cost is dominated by the IDE, not the extension. The README documents that accept command IDs differ between Antigravity 1.x and 2.x and that the extension resolves them at runtime, which is an ongoing maintenance burden the author has taken on. The l10n directory and the package.nls.*.json files at the repository root cover the localization set, and the README's feature list says 15 languages including runtime notifications while the project description says 13, so the two counts in the project's own materials disagree. Neither number affects behaviour.

There is no documented migration path between versions, and the README does not describe rollback. If a release breaks your setup, the releases page is the only route back, and you would be pinning an older VSIX manually.

Editorial conclusion

Adopt Antigravity Panel if you work inside Google Antigravity IDE all day and keep hitting quota walls without warning, or if the Brain Tasks cache has grown to the point where you want to see file counts before deleting anything. Skip it if you do not use Antigravity at all, since every feature reads or drives that IDE, or if you need an auto-accept tool that can inspect the pending command text before agreeing to it, because the README states the command-API path cannot. Before installing, verify that your Antigravity build registers the accept commands the extension looks for, and if you want the CDP fallback, confirm you are willing to relaunch the IDE with --remote-debugging-port=9222.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. n2ns/antigravity-panel on GitHub
3. Project website
4. README
5. Releases