Antigravity Usage Intelligence: Track Tokens, Quotas, Cache, Reasoning, and Agent Activity

A developer built Antigravity Usage Intelligence, an open-source usage tracker and analytics dashboard for Google's Antigravity agentic development environment. The tool breaks down token consumption into fresh input, cached context, and reasoning tokens, tracks quota usage via Antigravity's local language server with local rolling-window fallbacks, and visualizes activity through heatmaps and model-level analytics. The developer says the goal is to make the behavior of AI development workflows visible rather than to serve as a billing calculator.

I’ve been using Antigravity heavily for development, and one thing kept bothering me: I could see the agent doing a lot of work, but it was hard to understand how much was actually being used. How many tokens were going through my sessions? How much of that was fresh input versus cached context? How much reasoning was happening? Which projects were using the most? How often was I hitting the quota? And what did my usage actually look like over time? That led me to build Antigravity Usage Intelligence , an open-source usage tracker and analytics dashboard designed around those questions. GitHub: https://github.com/Nir-Bhay/antigravity-usage-intelligence https://github.com/Nir-Bhay/antigravity-usage-intelligence Antigravity has become much more agent-oriented. With Antigravity 2.0, Google introduced a standalone desktop experience alongside features such as subagents, scheduled tasks, agent management, CLI support, and other tools for longer and more autonomous workflows. That changes the way we think about usage. A simple prompt counter is not enough anymore. An agent can perform multiple turns, call tools, read files, generate output, use reasoning, and reuse cached context during a single task. The official Antigravity documentation also explains that quota limits are tied to the amount of work performed by the agent, which can vary significantly from one task to another. That makes visibility much more useful than simply knowing whether a request succeeded. The dashboard breaks usage into several parts instead of showing one mysterious number. The dashboard separates: That distinction matters. For example, two agent sessions can both look like large workloads, while their actual token behavior is very different because one relies heavily on cached context. The goal is not to turn token usage into a billing calculator. The goal is to make the behavior of your AI development workflow visible. One of the most useful parts is quota visibility. The extension can query Antigravity’s local language server and surface information such as: When live server data is unavailable, the project can fall back to local rolling-window calculations. That distinction is important because local estimates and server-reported quota are not the same thing . I would treat the server-side value as the authoritative quota signal and the local calculations as a useful approximation for understanding recent activity. Numbers become much easier to understand when you can see them over time. The activity heatmap gives a quick visual view of when you were actually using Antigravity. Instead of opening individual sessions, you can quickly spot: It is basically a contribution graph for your agent activity. That sounds small, but it changes the experience. After a few weeks, you start seeing how your development habits actually look. The dashboard also shows usage over time. This helps answer questions like: Am I gradually using more AI every week? Which days have the highest token consumption? Did one project cause a sudden spike? Am I relying more on reasoning-heavy models? Those are much more useful questions than simply asking how many messages you sent. Antigravity can work with multiple models, and the project identifies model activity so you can see which models are actually being used during your workflows. For example, the current Antigravity model lineup includes Gemini and Claude reasoning models, with availability depending on the user's plan. That makes model-level analytics particularly useful when you're comparing different workflows or trying to understand where your usage is going. One thing I wanted to make visible was reasoning usage. With thinking-oriented models, a task may involve significantly more internal reasoning than what you see in the final response. Treating all tokens as one number hides that difference. Separating reasoning tokens gives you another lens into how your agent is working. It is not necessarily about using fewer tokens. Sometimes more reasoning is exactly what you want. The point is to understand the tradeoff. When a task goes wrong, aggregated statistics are not enough. The session inspector lets you drill down into individual sessions and look at things such as: Tool calls are also categorized, so you can see the type of work the agent actually performed. That makes it easier to investigate long-running or unexpectedly expensive sessions. Agent development is not just about model responses. A large amount of useful work happens through tools. Reading files, searching code, running commands, replacing content, writing files, and other actions all contribute to the overall shape of a session. Tracking tool requests gives another way to understand whether an agent was mostly answering questions or actually doing work inside a codebase. This was important from the beginning. The project is designed to operate locally. It reads local Antigravity data and communicates with the local language server through loopback rather than sending your usage history to a remote analytics service. The repository also documents read-only database access and local caching so that active sessions are not unnecessarily disturbed. There are no external telemetry calls in the project. That means you can inspect your usage without handing your development history to another analytics backend. This is probably the most obvious question. Antigravity already provides quota information, especially through its current settings and model interfaces. The difference is depth . A quota indicator tells you where you stand. An analytics dashboard can help explain why you are there. Those are different problems. If you are doing serious agent-based development, historical context becomes useful: Which project consumed the most? Which days were the heaviest? How much context was cached? How many tool calls did the agent make? Which sessions were unusually large? How does my usage change over time? That is the gap this project is trying to fill. The biggest lesson is that token usage is not a single number. A large token count can come from very different workflows. A session may have: Looking only at the total hides the interesting part. Once the data is separated, you can start thinking about how you work with agents , not just how much you use them. I think it is most useful for developers who: It is probably unnecessary if you only use Antigravity occasionally and never care about usage patterns. You can install the extension from the VS Code-compatible marketplace or use the repository directly. bash git clone https://github.com/Nir-Bhay/antigravity-usage-intelligence.git cd antigravity-usage-intelligence npm install