Repository navigation
Contribution proposal: Antigravity agent source #1488
Description
Activity
This issue was auto-closed. Issues from new contributors are auto-closed by default.
Maintainers review auto-closed issues and reopen worthwhile ones. Issues that do not meet the quality bar in CONTRIBUTING.md may not be reopened or receive a reply.
Keep the issue short, concrete, and written in your own voice.
If a maintainer replies
lgtmi, your future issues will stay open. If a maintainer replieslgtm, your future issues and PRs will stay open.See CONTRIBUTING.md.
i would find this useful
Status: a partial implementation landed, and it is not the whole job
#1544 is merged, so
ccusage antigravity daily|monthly|sessionexists onmain
now. It landed while this proposal was still open, which was the wrong order —
apologies, @sambitcreate. Your proposal and #1487 came first and cover more
ground than what shipped.To be direct: what is on
mainis half-finished. It is not released yet
(latest is v20.0.19; the antigravity commit is queued in the tagpr PR #1507), so
we still have a free hand. Reverting50614f13is on the table and I would
not argue against it if we want #1487 to be the basis instead.What shipped
Reads
~/.gemini/antigravity-cli/conversations/**/*.db, decoding
steps.metadata(CortexStepMetadata) andgen_metadata.data
(ChatModelMetadata) by protobuf field number, recovered from the
FileDescriptorProtoblobs embedded in theagybinary. Dedupes every
invocation onresponse_id, thenprovider_assigned_message_id, then
message_id.Verified against a real install: 44,463 input / 456 output / 16,275 cache-read
tokens and $0.0724, matching a hand calculation from the raw protobuf.Where it falls short of this proposal
- Only one data directory. It looks at
antigravity-cliand misses
antigravity,antigravity-ideandantigravity-backup. The machine it was
developed on has only the CLI installed, which is exactly how that got missed.
IDE users get nothing today. - No model alias table. Opaque ids become
antigravity-model-<id>and
cannot be priced, so cost is silently understated. The alias table described
in this proposal is the fix. - No Gemini rates in the offline snapshot.
--offlinereports no cost for
Gemini models, becauseis_embedded_modelinccusage-core/build.rscovers
only Anthropic and OpenAI. Embedding models.dev Gemini entries, as proposed
here, is the fix. - Thin verification. It was validated against three chat turns in one CLI
conversation, against 23 days across a real install in feat(adapter): add antigravity agent source #1487. - Three code paths shipped unexercised. Retries actually occurring,
subagents, and model comparison (battle mode). The dedupe is designed to be
correct either way, but nothing has run through them.
Items 1-3 are already solved in #1487. That is the main reason I think it should
supersede or absorb what landed.What we still need
Questions for the Antigravity team
These are the ones no amount of local reverse engineering can settle, and getting
them answered would let this adapter stop hedging:- Model id mapping.
ModelUsageStats.modelis a number (we see1071and
1050), and the shipped descriptor names them only as
MODEL_PLACEHOLDER_M71/MODEL_PLACEHOLDER_M50. Is there an authoritative,
reasonably stable id-to-name mapping we can read or vendor? Which ids are
internal utility models rather than user-selected ones? - Whether
input_tokensexcludescache_read_tokens. We concluded they are
disjoint from a record carryinginput_tokens4050 againstcache_read_tokens
16275, which rules out the total-inclusive reading. Confirmation would be
welcome, along with whencache_write_tokensis populated — we have never seen
it set. retry_infossemantics. Does it include the attempt that succeeded, or
only the failed ones? Do failed attempts consume quota? Our dedupe is safe
either way, but a test fixture depends on knowing which it is.- Subagents and battle mode. Do sub-conversations always get their own
database, and can the same invocation appear in both a parent and a child? For
a model comparison, are both arms charged, and is the losing arm's data
retained? model_cost,credit_cost,consumed_credits. These exist in
ChatModelMetadataandCortexStepMetadatabut are unset on the consumer
accounts we have looked at. Which account types populate them? If any do, that
is authoritative cost and should take priority over our LiteLLM estimate.- Retention. Does Antigravity prune
stepsorgen_metadataover time? If
it does, a day's total shrinks on re-run, and we would rather warn about that
than have users discover it. - Missing token categories.
ModelUsageStatshas no equivalent of Vertex's
tool_use_prompt_token_count, or of image and audio counts. Are those folded
intoinput_tokens, or dropped during normalization? - Schema stability, or a supported export. We decode by field number on the
assumption that Antigravity cannot renumber fields without breaking its own
persistence. A published.proto, or any documented local export with
timestamps, model, and token counts, would remove that assumption entirely.
What would help from anyone reading this
Fixtures we do not have. Specifically: a conversation from an IDE install
(not the CLI), one that actually retried, one that invoked a subagent,
and one battle-mode comparison. Redacted or synthetic is fine — we only need
thestepsandgen_metadatablobs, not prompt text.Proposed next step
@sambitcreate — would you be willing to reopen #1487? The sensible outcome is
that its data-directory coverage, alias table, and pricing embedding land, either
on top of what is now onmainor by reverting50614f13first and taking your
branch as the base. Your call which is less work; I am happy to do the rebasing
either way.Whichever route we take, I would rather not ship v20.0.20 with the current
half-finished version as-is.- Only one data directory. It looks at
Opened #1569 to revert #1544 for now, so v20.0.20 does not go out with the
half-finished version.To be clear about intent: this is a temporary revert, not a decision to drop
Antigravity support. The plan is still to ship it — just from the better base.
Nothing about the reverse engineering is lost; the field numbers, the disjoint
input_tokens/cache_read_tokensevidence, and theresponse_iddedupe
reasoning all stay documented in the comment above.@sambitcreate — with
mainclean again, reopening #1487 becomes the
straightforward path: it lands on an unmodified base with no need to reconcile
against my version. Happy to do the rebase and review legwork if that helps.The questions for the Antigravity team in my previous comment still stand
regardless of which implementation lands, particularly the model id mapping and
whethermodel_cost/credit_costare ever populated. Those two decide whether
cost reporting can stop being an estimate.- added a commit that references this issue
on Aug 3, 2026 I opened a PR before reading this, fortunately the auto close thing sent me digging deeper. The ccusage adapter came after a python experiment to answer the question about my own usage from the last day.
Details on Antigravity telemetry from the wire format on macOS:
1. **Model names vs. IDs**: In `gen_metadata.data` (`ChatModelMetadata` / `GeneratorMetadata`), **Field 19** contains the actualmodel name string (e.g.,
gemini-3.7-flash) whenever present, which avoids having to guess numerical placeholder IDs.
2.input_tokensvs.cache_read_tokens: They are disjoint. Total prompt tokens =input_tokens+cache_read_tokens.
3. Data directories:
- CLI:~/.gemini/antigravity-cli/conversations/*.db
- IDE:~/.gemini/antigravity/conversations/*.dband~/.gemini/antigravity-ide/conversations/*.db
- Config:~/.config/antigravity/conversations/*.db
- Useful environment overrides:ANTIGRAVITY_HOME,ANTIGRAVITY_DATA_DIR,AGY_HOME
4. Subagents: Subagent runs generate their own child conversation UUIDs and are stored in separate conversation database files.
5. Retention: Local SQLite databases are persistent per conversation and are not pruned automatically.In case it helps - here is an adapter branch with a zero-copy Protobuf wire decoder, SQLite loader, and test suite: https://github.com/asdf8675309/ccusage/tree/feat/antigravity-adapter
I ran it on my machine against the python script (gist) for comparison and they matched.
Pullfrog triage: priority:high
A maintainer explicitly requested an implementation attempt. Detailed, repository-scoped proposal with local offline data, tests, and an existing implementation PR. Maintainer discussion confirms the feature is worthwhile and the prior revert was temporary, so it should remain open.
Decision: kept open; Pullfrog will attempt a focused implementation PR.
Historical audit: this discussion was auto-closed by the legacy contributor gate. That closure did not assess technical importance.
Audit result: resolved. A later merged change or the current
mainimplementation covers this request. This item is kept for history and does not need to be reopened.
What do you want to change?
Add Google Antigravity (Google's agentic IDE, and its CLI) as a supported agent source, exposed as
ccusage antigravity daily|monthly|sessionand included in the unified all-agents report.Why?
I split my work across several agents and Antigravity is the one ccusage can't see. It turns out Antigravity stores every conversation locally as SQLite databases under
~/.gemini/antigravity{,-cli,-ide,-backup}/conversations/, and each generation's token usage (input, output, cache-read, thinking, model, timestamp) is fully recoverable from those files offline — no API, no live process, no credentials. So the gap is fillable with the same read-local-logs approach as the other adapters.How?
Each conversation DB has a
gen_metadatatable where every row is aGeneratorMetadataprotobuf. A small hand-rolled wire-format reader decodes per-generation token counts, with a timestamp fallback chain and dedup byresponseIdacross databases. Antigravity's opaque model ids (MODEL_PLACEHOLDER_*,gemini-3-flash-a/b/c, tier suffixes) resolve through an alias table to LiteLLM-priced names, and Gemini entries from models.dev get embedded in the pricing snapshot so offline cost calculation works for models LiteLLM hasn't published yet (e.g.gemini-3.6-flash).Full disclosure: I got ahead of myself and opened PR #1487 before reading CONTRIBUTING.md — sorry about that. Feel free to leave it closed until this proposal is approved. The implementation there is complete and tested (469 cargo tests pass, clippy/fmt clean, verified against a real Antigravity install: 23 days of usage aggregated with correct models, tokens, and costs), and I'm happy to rework any part of it based on your feedback.