Skip to content

fix(rate-limits): stop presenting Gemini quota as Antigravity usage - #20151

Closed
nwparker wants to merge 3 commits into
mainfrom
fix/agy-quota
Closed

nwparker wants to merge 3 commits into
mainfrom
fix/agy-quota

Conversation

@nwparker

@nwparker nwparker commented Sep 11, 2026 •

Copy link
Copy Markdown
Contributor
Files Added Deleted Net
Test 5 $\color{#1a7f37}{\Huge{\mathbf{+}}}$​104 $\color{#cf222e}{\Huge{\mathbf{−}}}$​103 $\color{#1a7f37}{\Huge{\mathbf{+}}}$​1
Prod 6 $\color{#1a7f37}{\Huge{\mathbf{+}}}$​88 $\color{#cf222e}{\Huge{\mathbf{−}}}$​88 0

In plain language

Orca's usage bar was showing Google Gemini's quota numbers and labelling them "Antigravity". If you used Antigravity, the percentages you saw were a different product's usage, not your own — and they only showed up at all if you happened to have Google's Gemini command-line tool installed and signed in. There is no way for Orca to read Antigravity's real usage today, so instead of continuing to show you someone else's numbers, Antigravity now says plainly that its usage can't be read.

What you'll see differently: where Antigravity used to show a percentage bar, it now shows a dimmed dash, and the usage panel says "Usage unavailable" on the Antigravity row. Gemini's own numbers are unchanged. If you have Antigravity installed but never connected the Gemini tool, you'll now see that dimmed Antigravity row where previously you saw nothing at all.

User-visible downsides, stated up front

There are exactly two, and both are real:

  1. You lose a number you used to see. Anyone who had both Antigravity and a connected, working Gemini CLI sign-in saw a percentage on the Antigravity row; they now see "Usage unavailable". The number was never theirs — it was Gemini's — but it looked like information, and it is gone. This applies on every surface that reads this snapshot: desktop, mobile, and paired web.
  2. Some people gain a dimmed row they didn't have. The Antigravity usage item is on by default, so users who have Antigravity installed but never opted into the Gemini sign-in newly see a dimmed -- where they previously saw nothing. This is the honest state, but it is new visual clutter for that group — and it is likely the larger group of Antigravity users, since it no longer requires a Gemini install.

Two further candidates were checked and ruled out rather than assumed:

  • The Antigravity sign-in shortcut. Routing it away from Gemini's Accounts section looked like it removed an affordance, but the roster only renders a sign-in CTA when getUsageRosterRowState returns kind: 'sign-in', which requires the error text to match a confirmed-signed-out pattern. None of the three Antigravity error strings — the two old ones or the new one — match, so the row always rendered kind: 'unavailable' and canSignIn was never consulted. Verified against the real function, not by inspection. No user ever had that shortcut.
  • A delayed setup CTA. Making Antigravity durable on its own means it now participates in the isUsageEmptyState pending check, which could in principle delay the "connect an account" prompt at startup. It does not: every provider is published in one state object, the others are equally unsettled on the first push and already gate the CTA, and Antigravity resolves synchronously — so it is never the last one outstanding.

What this fixes — and what it does not

Read this first. This is a deliberate partial fix. Please do not merge it thinking it closes either linked issue.

Status
Orca shows Gemini's quota pools under the Antigravity name (#14515) Fixed
Antigravity usage requires a Gemini CLI install to show anything (#9122) Fixed
Orca shows Antigravity's own native quota pools (#14515's other half) Not fixed — no reachable source
Antigravity usage refreshes (#9122's other half) Not fixed — nothing to refresh yet

Refs #14515 / Refs #9122 on purpose, not Fixes.

The bug

deriveAntigravityRateLimits() took a successful Gemini snapshot, relabelled it provider: 'antigravity', and published it. Antigravity was never queried at all. Two consequences:

  1. Orca displayed another provider's numbers under the Antigravity label.
  2. Antigravity usage silently depended on a Gemini CLI sign-in existing.

Why there is no native replacement yet

A native Antigravity quota source is not implementable or verifiable from this repo today:

  1. No CLI surface. agy --help lists every subcommand — agent, agents, changelog, help, install, mcp, mic-serve, models, plugin, plugins, remote-control, update. There is no usage, quota, limits, or status.
  2. No readable credential. The token lives in the OS keyring (macOS keychain service gemini, account antigravity), not on disk. Orca has no keyring reader, and the Windows/Linux store layouts are undocumented here.
  3. No usable contract. The only native quota surface is three gRPC method names inside a 178 MB proprietary binary — no documented host, auth scheme, or message schema.

So the substitution is removed rather than replaced. fetchAntigravityRateLimits() is a real provider fetcher in the Promise.allSettled cycle (7th slot) that returns status: 'unavailable' with an Antigravity-attributed reason. antigravity-usage-mirror.ts is deleted, so the Gemini→Antigravity derivation edge no longer exists in the type graph.

Visual proof

Captured from the real Electron app (dev build on this branch, background launch, CDP screenshots of the hidden renderer). The renderer is byte-identical across the fix, so before/after differ only in the snapshot the main process publishes — each is the exact object the old and new code produce at runtime (see the runtime evidence below).

🔴 BEFORE — the bug

Gemini reports Pro 42% / Flash 11%, and Antigravity reports the same two numbers directly beneath it. This single image is #14515.

BEFORE - usage panel: Antigravity shows Gemini's Pro 42% / Flash 11%

Usage panel. And in the status bar itself, the same pair of numbers appears twice — once under the Gemini icon, once under the Antigravity icon:

BEFORE - status bar: Pro 42% / Flash 11% duplicated under both the Gemini and Antigravity icons

Status bar.

🟢 AFTER — the fix

Same app, same Gemini quota. Gemini keeps its own numbers; Antigravity states its own unavailability instead of borrowing them.

AFTER - usage panel: Gemini keeps Pro 42% / Flash 11%, Antigravity row reads Usage unavailable

Usage panel. The status bar now shows Antigravity as a dimmed -- rather than a borrowed percentage:

AFTER - status bar: Gemini keeps its numbers, Antigravity shows a dimmed dash

Status bar.

🟢 AFTER — with the Gemini sign-in turned off

What this one proves: Antigravity no longer needs Gemini to exist. Gemini drops out of the panel entirely, and Antigravity still has its own row with its own explanation — where previously it would have vanished along with Gemini. This is the #9122 half of the fix.

AFTER with Gemini opt-in off - Gemini is absent from the panel but Antigravity still has its own Usage unavailable row

Is the chip hidden? No — and that's the recommendation

isProviderConfigured() returns false for 'unavailable', which raised the question of whether the Antigravity chip silently disappears. It does not. getVisibleUsageProvider() falls through to the durable-settings check, so a configured Antigravity slot renders ProviderSegment's unavailable branch: a dimmed icon + -- in the bar, and an explicit "Usage unavailable" row in the roster, with the full reason on drill-in.

Recommendation: keep the visible unavailable state; do not hide the chip. It is the only place Orca can tell an Antigravity user why there is no usage — which is exactly the question #9122 was filed to ask. Hiding it would answer that question with silence.

Runtime proof (not just unit tests)

Driving the real RateLimitService.refresh() cycle with a Gemini source returning a successful quota:

// gemini source returned
{ "provider": "gemini", "session": { "usedPercent": 42, ... }, "status": "ok",
  "buckets": [ { "name": "Pro", "usedPercent": 42, ... }, { "name": "Flash", "usedPercent": 11, ... } ] }

// state.gemini after refresh() — intact, untouched
{ "provider": "gemini", "session": { "usedPercent": 42, ... }, "status": "ok",
  "buckets": [ { "name": "Pro", "usedPercent": 42, ... }, { "name": "Flash", "usedPercent": 11, ... } ] }

// state.antigravity after refresh() — no numbers, no Gemini
{ "provider": "antigravity", "session": null, "weekly": null, "error":
  "Antigravity usage is not available. Orca cannot read the Antigravity account quota pools yet.",
  "status": "unavailable" }

With no Gemini CLI installed (real unmocked fetchers, HOME pointed at an empty directory, no network reached):

// real fetchGeminiRateLimits(true)
{ "provider": "gemini", "error": "Gemini CLI credentials not found", "status": "unavailable" }

// real fetchAntigravityRateLimits()
{ "provider": "antigravity", "error":
  "Antigravity usage is not available. Orca cannot read the Antigravity account quota pools yet.",
  "status": "unavailable" }

// /gemini/i.test(antigravity.error) === false

Stale-policy path. A cached impersonated snapshot from before the upgrade ({ ...gemini, provider: 'antigravity' }, status: 'ok', Pro 42% / Flash 11%) was seeded into service state, then a refresh was run. applyStalePolicy() takes the fresh.status === 'unavailable' early return and discards it — the stale Gemini numbers do not survive the upgrade as an Antigravity snapshot.

Two stale-coupling loose ends — resolved here, not deferred

Both were flagged as out of scope by the original implementation. Leaving Gemini coupling in a PR whose entire point is severing Gemini coupling would be the wrong call, and both fixes are one-liners in the same conceptual unit, so they are in this PR.

1. status-bar-provider-visibility.ts — Antigravity visibility ANDed with geminiCliOAuthEnabled.
The original rationale ("the snapshot mirrors the Gemini fetch") is now false, but the gate was not inert — it was the only thing preventing a permanently dim chip. Now hasUsageProviderSettingsForProvider('antigravity', …) depends only on Antigravity signals: the checked status-bar item plus agy detected on PATH.

The tradeoff, stated plainly: the antigravity status-bar item is default-on, so users who have agy installed but never opted into Gemini CLI OAuth newly see a dimmed A --. That is intentional — it is an honest "Orca can't read this yet" for a provider they have installed, and it is the same treatment every other unavailable-but-configured provider gets. The alternative (returning false outright and hiding the slot until a native source lands) is a one-word change if a reviewer prefers it; I recommend against it for the reason in the visual-proof section.

hasUsageProviderSettings() deliberately still has no Antigravity term, so an Antigravity-only user still gets the setup CTA rather than a slot that can never fill.

2. usage-provider-settings-target.ts — Antigravity's sign-in CTA routed to accounts-gemini.
Now returns null, like Kimi. accounts-gemini configures Gemini; sending an Antigravity user there configures the wrong provider. canSignIn already handles null by suppressing the CTA.

Readiness review

Area Result
Remote wire No contract change. ProviderRateLimits shape and the antigravity key are unchanged; only the value differs. mobile/src/components/accounts-snapshot.ts already accepts status: 'unavailable', so old paired clients and mobile decode it.
Backward compat / data loss Rate-limit state is in-memory only — no schema, migration, or persisted cache. The pre-upgrade impersonated snapshot is discarded (above), not carried forward.
Crash / retry / growth No casts, no new retry lane, no unbounded structure. fetchAntigravityRateLimits() cannot reject; a rejection is still handled. trackActiveFailureStreak resets on unavailable. The activation planner restamps updatedAt each cycle, so the permanently-unavailable slot adds no fetch churn — same shape as Grok's unavailable path.
Security Net reduction in surface: Antigravity no longer implicitly reads Gemini's OAuth credential files. No network, shell, or credential access added.
Cross-platform No platform-conditional code; the unavailability reason is platform-independent. The removed path was implicitly POSIX-path-dependent through the Gemini OAuth file reads.
Performance One extra Promise.allSettled entry resolving synchronously.
Code organization antigravity-native-usage-source.ts sits with the other provider sources in src/main/rate-limits/, named for what it contains.

No P0/P1/P2 findings.

Reviewing this diff

Use ?w=1. service-full-cycle-preparation.ts shows 83 changed lines, of which only 17 are substantive; the remaining ~66 are a two-space reindent of the provider array.

The reindent is unavoidable. The original destructuring pattern was already 99 characters, right at the formatter's print width, and it only kept the array at its old indent because that length forced a = / await line break. A seventh binding name pushes the pattern multi-line, which moves Promise.allSettled([ up a level and shifts every element with it. I confirmed by experiment that oxfmt collapses a hand-written wrapped assignment back onto one line, so there is no formulation that preserves the old indent without a contrived, formatting-driven type annotation.

What I did instead was delete the cause of the surrounding churn. The seven settled results were being bound to names and immediately reassembled into an identical array, so a provider had to be listed in three places. The third commit returns the awaited tuple directly, which drops 16 lines of ceremony, cuts the substantive change from 19 lines to 17, and leaves the fetch array as the single place a provider is added or removed — which should also reduce conflicts with any other PR touching this cycle.

The 17 substantive lines, in full:

+import { fetchAntigravityRateLimits } from '../antigravity-native-usage-source'
+    PromiseSettledResult<ProviderRateLimits>,        // 7th tuple slot
-    const [claudeResult, codexResult, geminiResult, opencodeGoResult, kimiResult, miniMaxResult] =
-      await Promise.allSettled([
+    const results = await Promise.allSettled([
-            })
+          }),                                        // trailing comma before the new entry
+      fetchAntigravityRateLimits()
-      results: [
-        claudeResult, codexResult, geminiResult, opencodeGoResult, kimiResult, miniMaxResult
-      ],
+      results,

Verification

  • npx vitest run src/main/rate-limits/ src/renderer/src/components/status-bar/ … — 97 files, 844 tests passing
  • oxlint — clean
  • oxfmt --check — clean
  • tsc --noEmit on tsconfig.node.json, tsconfig.tc.web.json, tsconfig.tc.cli.json — all clean

Refs #14515
Refs #9122

Antigravity was derived solely from Gemini and relabeled, so it showed another
provider's pools and required a Gemini CLI install. It is now its own provider
slot reporting explicit unavailability when no native source exists.

Refs #14515
Refs #9122
…mini

The Antigravity status-bar slot required `geminiCliOAuthEnabled`, and its
sign-in CTA opened Gemini's Accounts section. Both were artifacts of the
deleted Gemini mirror. Antigravity now earns its slot from Antigravity
signals alone (checked item + CLI on PATH) and renders its own explicit
unavailable state; it no longer offers a CTA that would configure a
different provider.

Refs #14515
Refs #9122

@pullfrog pullfrog Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ No critical issues — a couple of stale comments worth cleaning up; otherwise a clean, well-scoped partial fix.

Reviewed changes

  • Antigravity quota source — deletes antigravity-usage-mirror.ts and adds antigravity-native-usage-source.ts, whose fetchAntigravityRateLimits() always reports Antigravity-native unavailable instead of relabelling a Gemini snapshot.
  • Fetch-cycle integration — fetchAntigravityRateLimits() joins the Promise.allSettled cycle as the 7th slot; the rejected branch also resolves to buildAntigravityNativeUnavailable() so it never borrows another provider's failure.
  • Status-bar visibility — hasUsageProviderSettingsForProvider('antigravity') now depends on the checked item alone (CLI on PATH), no longer on geminiCliOAuthEnabled; the aggregate hasUsageProviderSettings() still omits Antigravity.
  • Sign-in routing — getUsageProviderAccountsSectionId('antigravity') returns null instead of routing to accounts-gemini.
  • Tests — new source tests plus updated service/visibility/routing tests pin the unavailable state, the exact reason, that Gemini's own snapshot is untouched, and the stale-impersonation discard.

The core claims check out against the surrounding code: applyStalePolicy discards stale data on unavailable (service-result-policy.ts:28), trackActiveFailureStreak resets on unavailable (service-result-policy.ts:79), and the activation planner treats unavailable like ok (service-polling.ts:95), so the permanently-unavailable slot adds no retry churn. Mobile's ProviderRateLimitsSchema already accepts status: 'unavailable', and the wire shape is unchanged.

ℹ️ Nitpicks

  • src/renderer/src/components/status-bar/use-status-bar-controller.ts:106 still claims Antigravity visibility "also requires geminiCliOAuthEnabled because its usage snapshot mirrors the Gemini fetch" — that gate is removed by this PR.
  • src/renderer/src/components/status-bar/status-bar-provider-visibility.test.ts:126 still says "antigravity durability requires the Gemini OAuth opt-in" — the new rationale is the "no readable source" reasoning already documented in status-bar-provider-visibility.ts.

Pullfrog  | Fix it ➔ | View workflow run | Using DeepSeek Pro (free via Pullfrog for OSS) | 𝕏

@coderabbitai

coderabbitai Bot commented Sep 11, 2026 •

Copy link
Copy Markdown
Contributor

Review Change StackReview Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: afd40f31-3733-4f90-b006-43953ff1a7be

📥 Commits

Reviewing files that changed from the base of the PR and between 7e5f335 and 985dd54.

📒 Files selected for processing (1)
  • src/main/rate-limits/service/service-full-cycle-preparation.ts

Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.


📝 Walkthrough

Walkthrough

Antigravity rate limits now use a dedicated native source that reports unavailability instead of mirroring Gemini data. The full fetch cycle retrieves Antigravity results independently and applies a native fallback when needed. Renderer visibility now depends only on antigravityUsageConfigured, and Antigravity no longer routes to Gemini’s Accounts section. Tests cover the new source, service behavior, visibility states, and routing.

Priority: ⬇️ Low

Severity of issue fixed: Low

Merge Risk: 🔵 Low · up to 985dd

Antigravity usage now correctly reports unavailable, but its new error text may not be translated for localized users. This is a bounded follow-up rather than a merge-blocking functional failure.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 20.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 9 files. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Title check ✅ Passed The title clearly and concisely states the primary change: stopping Gemini quota data from being presented as Antigravity usage.
Description check ✅ Passed The description is detailed and covers the change, rationale, linked issues, user impact, visual proof, testing, compatibility, security, and performance. It omits some template headings and checklist…
  • Fix all pre-merge checks with AI
✨ Finishing Touches 💡 1
📝 Generate docstrings 💡
  • Create stacked PR
  • Commit on current branch

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1


ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: afe1e644-df76-472b-9965-5bd3020162d6

📥 Commits

Reviewing files that changed from the base of the PR and between 7294915 and 7e5f335.

📒 Files selected for processing (11)
  • src/main/rate-limits/antigravity-native-usage-source.test.ts
  • src/main/rate-limits/antigravity-native-usage-source.ts
  • src/main/rate-limits/antigravity-usage-mirror.test.ts
  • src/main/rate-limits/antigravity-usage-mirror.ts
  • src/main/rate-limits/service-antigravity-usage.test.ts
  • src/main/rate-limits/service/service-full-cycle-application.ts
  • src/main/rate-limits/service/service-full-cycle-preparation.ts
  • src/renderer/src/components/status-bar/status-bar-provider-visibility.test.ts
  • src/renderer/src/components/status-bar/status-bar-provider-visibility.ts
  • src/renderer/src/components/status-bar/usage-provider-settings-target.test.ts
  • src/renderer/src/components/status-bar/usage-provider-settings-target.ts
💤 Files with no reviewable changes (2)
  • src/main/rate-limits/antigravity-usage-mirror.test.ts
  • src/main/rate-limits/antigravity-usage-mirror.ts

Included review availability: Your plan provides up to 10 included reviews per hour; 4 remain after this review.

Comment on lines +9 to +10
export const ANTIGRAVITY_NO_NATIVE_SOURCE_REASON =
'Antigravity usage is not available. Orca cannot read the Antigravity account quota pools yet.'

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Localize the Antigravity unavailability message.

buildAntigravityNativeUnavailable() stores raw English in ProviderRateLimits.error, and the unavailable-provider tooltip renders p.error directly. This bypasses translate() and shows English for non-English locales. Add an intent-named localization ID and resolve it at this display boundary.

…rebuild it

The seven settled results were bound to names and immediately reassembled into
an identical array, so adding a provider meant editing the same list in three
places. Returning the awaited tuple directly drops that ceremony and leaves the
fetch array as the single place a provider is added or removed.

Checks run manually in place of the pre-commit hook: oxlint, oxlint
--config config/oxlint-react-doctor.json, oxfmt --check.

@pullfrog pullfrog Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ No new issues found.

Reviewed changes

Since the prior pullfrog review at 7e5f335, one commit landed:

  • Provider cycle returns its settled tuple directly — prepareFetchAllCycle now returns the Promise.allSettled result as results instead of destructuring seven bindings and reassembling an identical array; service-full-cycle-application.ts destructures prepared.results by position. Behavior-preserving: same provider order, same rejected-branch handling, same signal.aborted bail-outs.

The results field stays a hand-written seven-element PromiseSettledResult<ProviderRateLimits> tuple, so adding a fetcher without widening the type still fails typecheck. No references to the deleted antigravity-usage-mirror remain.

Pullfrog  | View workflow run | Using openrouter/deepseek/deepseek-v4.1-flash (free via Pullfrog for OSS) | 𝕏

@ZedObaia

Copy link
Copy Markdown

Agreed that Gemini's numbers shouldn't be labelled as Antigravity. But one line in the description is out of date: "There is no way for Orca to read Antigravity's real usage today." There is now, and it's simple.

The Antigravity CLI reports its own usage as JSON:

agy -p /usage --output-format json
  • It doesn't need any tokens, keychain access, or a Gemini CLI install. agy handles the sign-in itself.
  • It doesn't start an agent turn, use any quota, or leave a conversation behind. It returns in about 3 seconds.
  • It was added in agy 1.1.11. From agy changelog:

    Added non-interactive answers for the read-only slash commands in print mode, so -p "/usage", /quota, /credits, /model, /effort and /skills emit one tab-separated record per line — or a structured payload under --output-format json and stream-json — without starting an agent turn, spending quota, or leaving a conversation behind.

  • Docs: Headless mode | Google Antigravity Docs. It lists /usage as a slash command the CLI answers directly in print mode.

The shape of what it returns (trimmed, example values):

{
  "status": "SUCCESS",
  "command": {
    "name": "usage",
    "data": {
      "groups": [
        {
          "name": "Gemini Models",
          "buckets": [
            { "id": "gemini-weekly", "window": "weekly", "remaining_fraction": 0.5, "reset_time": "<RFC 3339 time>" },
            { "id": "gemini-5h", "window": "5h", "remaining_fraction": 0.5, "reset_time": "<RFC 3339 time>" }
          ]
        },
        {
          "name": "Claude and GPT models",
          "buckets": [
            { "window": "weekly", "remaining_fraction": 0.5, "reset_time": "<RFC 3339 time>" },
            { "window": "5h", "remaining_fraction": 0.5, "reset_time": "<RFC 3339 time>" }
          ]
        }
      ]
    }
  }
}

These are the real Antigravity limits: two pools (Gemini, and Claude/GPT), each with a 5-hour and a weekly window, plus reset times. They match what /usage shows inside agy.

Other tools already use it: CodexBar switched to this report in 0.60.2 (steipete/CodexBar#3607). With it, the Antigravity row shows all four limits.

So instead of changing the row to "Usage unavailable", Orca could read this report. #20797 already does that. Could you take a look at it before merging this one? Otherwise the row goes blank for everyone even though the data is available.

@nwparker

Copy link
Copy Markdown
Contributor Author

Current review verdict: do not merge this head as-is; superseded by #21654 → #21678.

ELI5: this PR correctly stops labeling Gemini numbers as agy, but the maintained stack now reads agy’s supported /usage contract with version gating and the configured executable. Keeping both paths would reintroduce competing quota behavior. Please use the maintained stack for the fix.

@nwparker

Copy link
Copy Markdown
Contributor Author

Closing as superseded after checking current main.

The quota behavior has been superseded by merged #24073 and #24593. Current main reads native Antigravity usage with CLI-version and preference gating. This older implementation reports usage as unavailable instead of retaining the real usage now supported on main.

Closing this PR only; its branch is being retained.

@nwparker nwparker closed this Oct 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants