Repository navigation
Contribution proposal: Antigravity agent source #1488
Description
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|session and 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_metadata table where every row is a GeneratorMetadata protobuf. A small hand-rolled wire-format reader decodes per-generation token counts, with a timestamp fallback chain and dedup by responseId across 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.
Activity
pullfrog commentedon Jul 24, 2026
github-actions commentedon Jul 24, 2026
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.
byte commentedon Aug 1, 2026
i would find this useful
ryoppippi commentedon Aug 3, 2026
Status: a partial implementation landed, and it is not the whole job
#1544 is merged, so
ccusage antigravity daily|monthly|sessionexists onmainnow. 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. Reverting
50614f13is on the table and I wouldnot argue against it if we want #1487 to be the basis instead.
What shipped
Reads
~/.gemini/antigravity-cli/conversations/**/*.db, decodingsteps.metadata(CortexStepMetadata) andgen_metadata.data(
ChatModelMetadata) by protobuf field number, recovered from theFileDescriptorProtoblobs embedded in theagybinary. Dedupes everyinvocation on
response_id, thenprovider_assigned_message_id, thenmessage_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
antigravity-cliand missesantigravity,antigravity-ideandantigravity-backup. The machine it wasdeveloped on has only the CLI installed, which is exactly how that got missed.
IDE users get nothing today.
antigravity-model-<id>andcannot be priced, so cost is silently understated. The alias table described
in this proposal is the fix.
--offlinereports no cost forGemini models, because
is_embedded_modelinccusage-core/build.rscoversonly Anthropic and OpenAI. Embedding models.dev Gemini entries, as proposed
here, is the fix.
conversation, against 23 days across a real install in feat(adapter): add antigravity agent source #1487.
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:
ModelUsageStats.modelis a number (we see1071and1050), and the shipped descriptor names them only asMODEL_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?
input_tokensexcludescache_read_tokens. We concluded they aredisjoint from a record carrying
input_tokens4050 againstcache_read_tokens16275, which rules out the total-inclusive reading. Confirmation would be
welcome, along with when
cache_write_tokensis populated — we have never seenit set.
retry_infossemantics. Does it include the attempt that succeeded, oronly the failed ones? Do failed attempts consume quota? Our dedupe is safe
either way, but a test fixture depends on knowing which it is.
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 inChatModelMetadataandCortexStepMetadatabut are unset on the consumeraccounts we have looked at. Which account types populate them? If any do, that
is authoritative cost and should take priority over our LiteLLM estimate.
stepsorgen_metadataover time? Ifit does, a day's total shrinks on re-run, and we would rather warn about that
than have users discover it.
ModelUsageStatshas no equivalent of Vertex'stool_use_prompt_token_count, or of image and audio counts. Are those foldedinto
input_tokens, or dropped during normalization?assumption that Antigravity cannot renumber fields without breaking its own
persistence. A published
.proto, or any documented local export withtimestamps, 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
the
stepsandgen_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 on
mainor by reverting50614f13first and taking yourbranch 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.
ryoppippi commentedon Aug 3, 2026
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_iddedupereasoning all stay documented in the comment above.
@sambitcreate — with
mainclean again, reopening #1487 becomes thestraightforward 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
whether
model_cost/credit_costare ever populated. Those two decide whethercost reporting can stop being an estimate.
revert(antigravity): remove the Antigravity adapter until #1487 lands (…
asdf8675309 commentedon Aug 20, 2026
Hi @ryoppippi @sambitcreate,
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:
model 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_HOME4. 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.
github-actions commentedon Aug 28, 2026
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.
ryoppippi commentedon Aug 31, 2026
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.