Repository navigation
Retrieve missing Antigravity Gemini and Argon quota pools from a supported native source #519
Description
Status: Source accepted by the Chief on October 27, 2026; fix in PR #529. Earlier status: blocked on a supported native quota source. Primary-source assessment.
Description
The native adapter calls retrieveUserQuotaSummary in CodexBarIOS/Services/AntigravityUsageProvider.swift. The Chief confirmed on October 23, 2026 that this fallback can omit the Gemini and Argon pools that the free agy -p /usage --output-format json command returns under command.data.groups. No supported equivalent backend request has been captured or documented for the iOS app.
The SUS work in #518 parses the stable bucket IDs gemini-5h, gemini-weekly, gemini-argon-wtu-weekly, 3p-5h and 3p-weekly when supplied, and keeps absent pools unavailable. Google documents the CLI's quota command, which refreshes model configuration and quotas. That documentation does not establish an iOS endpoint contract.
Why
Missing weekly pools cannot show measured utilization or a SUS. A partial quota response must not appear to represent the entire subscription.
Goal
Read the missing pools through a supported, documented native-app source when one becomes available, using the account's isolated connection.
Acceptance Criteria
-
Establish the supported request/response contract for Gemini and the separate Argon weekly pool, with primary-source evidence.Amended by the Chief, October 27, 2026: no documented contract exists; use the production host of the existingv1internalservice first, the daily host on error, never mixed, and never show an all-full production placeholder. - Preserve stable pool IDs, explicit windows, reset times, account isolation and disabled/missing states.
- Missing pools remain unavailable and never become a fabricated percentage or score.
- No private endpoint reverse engineering, CLI import, desktop token export or extra end-user credential work.
Definition of Done
- Implement through a linked PR with a clean current-head review and green required checks.
- Test an actual sanitized producer response and missing, malformed, disabled and account-isolation cases.
- Document remaining provider limitations truthfully.
Validation
- Run focused adapter and SUS tests on air with the pinned Xcode toolchain.
- Verify the native request uses the documented source and preserves existing authentication isolation.
- Embed current-head iPhone/iPad screenshots of the newly available pools and the unavailable fallback in the PR, with a recording when useful.
- Live account access remains Franz's verification; automated fixture coverage is the agent's delivery requirement.
Activity
HemSoft commentedon Oct 24, 2026
Blocked: supported native quota contract not established
Primary-source check on October 24, 2026. I could not establish a supported request/response contract for reading the consumer Gemini and separate Argon weekly pools from an iOS app. This is an upstream contract gap, not a request for Franz to export credentials or approve a release.
Sources reviewed:
/usageand/quotain the CLI and says that opening the panel refreshes configuration and quotas. It supplies no supported native HTTP method, OAuth scopes, account-binding contract or response schema for these subscription pools.The conclusion is limited to the public primary sources inspected; it is not a claim that no backend exists. The CLI clearly has quota data, but that alone does not authorize treating its private implementation as a supported native integration.
Current behavior remains unchanged: stable bucket IDs
gemini-5h,gemini-weekly,gemini-argon-wtu-weekly,3p-5hand3p-weeklyare parsed when actually supplied. Absent pools remain unavailable with SUS n/a. Auth and account isolation are preserved. No endpoint probing/reverse engineering, CLI import, desktop token export, inference request, paid purchase or provider outreach was performed.Unblock when Google publishes a supported request, authorization/account-isolation rules, and a response contract identifying these pools, windows and reset times, plus a sanitized response from that supported producer. A private capture alone would not satisfy the supported-source requirement. Leave this issue open and blocked; independent UI-gate engineering in #517 / PR #521 continues.
HemSoft commentedon Oct 25, 2026
Reported P0: Gemini Models metrics unavailable
Franz reports on October 25, 2026 at 5:30 PM EDT that Gemini-model metrics say unavailable: report. This report is not yet reproduced against an actual iOS quota response. Reusing this issue while diagnosis determines whether there is a separate decoder/model/UI defect; no duplicate implementation PR exists.
Current main
d58713e889fbfe3a025f0966cef5345099418e42callsretrieveUserQuotaSummary.AntigravityQuotaParsermatches the five canonical IDs independently and requires matching windows and a valid fraction;GeminiUsageProvidercombines isolated Apps/coding results and the metric catalog maps Gemini Models IDs to the coding source. An alternate consumer having Gemini weekly data does not establish that the iOS endpoint supplied it. The available retained sanitized file contains only a usage timeout, not a quota payload.Next: reproduce through the actual parser/model/presentation with retained sanitized data and missing/malformed/present controls. Fix a proven app defect through an isolated linked PR with current-head review, required CI and native fixture UI evidence. Preserve honest missing states and separate Gemini/3P/Argon IDs; do not substitute another pool, invent quota, launch a provider CLI or reverse-engineer endpoints. The previously documented supported-source block is not cleared by this report alone.
HemSoft commentedon Oct 25, 2026
Diagnosis checkpoint: app defect not reproduced
October 25, 2026. Investigated Franz's reported Gemini Models unavailability at exact main
d58713e889fbfe3a025f0966cef5345099418e42in an isolated, unchanged checkout. No source change or duplicate PR was created.A synthetic, network-intercepted loop exercises the actual
GeminiUsageProviderandAntigravityUsageProvider,AntigravityQuotaParser, refresh cache, dashboard result selection, configurable metric catalog, andProviderMetricTileContent.resolve. All 17 controls passed in 0.036 seconds, including supplied/missing five-hour and weekly buckets, invalid fractions/windows/resets, disabled/duplicate/null/malformed data, Argon-only and 3P-only responses, separate accounts, missing coding credentials, and present-to-missing cache refresh. Supplied canonical Gemini buckets reach measured tiles without borrowing other pools.The separate expected-present assertion passes on supplied Gemini data and exits 1 with “Gemini Models gemini-5h is unavailable” when those buckets are omitted. This confirms that the loop detects the reported symptom; it does not reproduce a production defect or prove the real response omitted the data. The build compiled 123 actual source files with Xcode 26.6 / Swift 6 complete concurrency. It was a macOS diagnostic build, not native iOS or UI qualification. No simulator, provider client, live account request, or full manual workflow was run.
Retained artifacts supply no actual iOS quota response: one records a usage timeout; a historical transformed snapshot is not the producer schema. The available alternate consumer's Gemini values therefore cannot establish parity with the native
retrieveUserQuotaSummaryresponse. The supported-source assessment remains unresolved.Next discriminating evidence: a supported native request/response contract with account-binding/auth rules and a sanitized normal-feed producer response containing the canonical pools. Replay that exact response through this loop: if valid supplied values are rejected or lost, repair that proven decoder/model/presentation seam; if the source lacks them, implement only once a supported native source is established. No private endpoint reverse engineering, CLI import, desktop credential export, inferred quota, or replacement-pool fallback. This is a source-evidence block, not an App Store or human account-testing gate.
Private Air evidence is retained at
/tmp/codexbar-519-20261025-diagnosis/(source loop, results, source list and SHA-256 ledger); the original runnable loop remains at/var/folders/44/dryv_td53db877zl38g0jcbc0000gn/T/codexbar-519-source-loop-dc6eubef/run-loop.sh. Native UI evidence, normal CI and current-head PR review were not run because no source fix was justified. Issue remains open and blocked.HemSoft commentedon Oct 25, 2026
Producer/provenance checkpoint: reported P0 remains unresolved
October 25, 2026, 7:04 PM EDT. No source or runtime changes.
Exact screen and decoder split
The iOS Google Gemini dashboard card (
providerID=gemini) contains two distinct sources. Literal Gemini Models five-hour / weekly tiles have metric IDsantigravity.gemini-5h/antigravity.gemini-weekly; Gemini Apps five-hour / weekly havegemini.five-hour/gemini.weekly. See the immutable metric catalog. Thus this issue matches the report if Franz means the literal Models tiles. A focused screen-label clarification is pending; the report is not dismissed if he means Apps.retrieveUserQuotaSummary. The current decoder contract isgroups[].buckets[]withbucketIdequal togemini-5horgemini-weekly, matchingwindow(5h/weekly), numeric finiteremainingFractionin 0...1, optional valid futureresetTime, and not disabled. Missing, duplicate or invalid matching buckets do not establish an allowance. Unavailable status is serialized asunavailableUsageMetrics["antigravity.<bucketId>"].jSf9Qcbatched response tuples; period 1/2 becomesfive-hour/weekly. These values are not Models quotas.One normally published snapshot obtained
Used the existing Mini agent's cached
GET /usageexactly once, without headers/credentials, refresh, CLI execution, or collector restart. Its handler readsusageStore.Snapshot(); background collection is separate. Selected only provider/pool IDs, quota numbers, reset/window fields, snapshot timestamps and availability booleans; no account identities, config, prompts or other providers were retained.Published snapshot: 7:03:37 PM EDT, read 7:04:32 PM EDT.
cards[key=antigravity]has no error or fallback warning:gemini-5hgemini-weeklyThe canonical comparison PR is hs-pi-dashboard #66, merged at
aa334be72b47f1f1f446ec4baef6c7b395746f6e. The producer prefers its existing CLI usage collection, normalizescommand.data.groupstocards[].gauges[], and marks HTTP fallback with a warning. Its normalizer accepts CLI snake_case and HTTP camelCase separately. The cache's lack of fallback warning is consistent with CLI-path success under that source; it is not proof of deployed source identity or account parity with the phone. Chief'sscripts/usage.pysimilarly prefers the CLI path.What this establishes: measured Gemini pools are available in the normal published alternate-consumer feed. What it does not establish: the iOS HTTP response contained those pools, used snake_case, or lost them downstream. The published normalized cache is not an iOS raw response and cannot be fed to the native decoder as though it were one. No alternate-provider values are imported into iOS. No producer defect is established in hs-pi-dashboard, so no duplicate producer fix is opened there.
Owned next step and exact missing evidence
The existing iOS owner retains this P0 outcome. Confirm the tile labels, then obtain/replay only the normal native response's matching pool IDs/windows/fractions/reset/disabled fields plus response-schema/status provenance. For Models, the missing fact is whether
groups[].buckets[]in the phone's native summary response contains validgemini-5h/gemini-weekly; the alternate cache cannot answer that. If the fields are present and rejected, fix that proven iOS seam with a failing regression and native UI evidence. If absent, the supported native request/auth/account-binding contract remains the source gap tracked here; the CLI-backed publisher does not authorize a private-endpoint reconstruction or account-unsafe shared cache integration. Acceptance is actual source-bound Gemini readings reaching the correct two Models tiles, with missing/malformed pools still unavailable and Argon/3P separate.No manual provider CLI/auth/client launch, account refresh, Home/Laptop operation, app restart, new telemetry, or full UI dispatch occurred. No fix, native iOS validation, PR review or resolution is claimed. Private sanitized snapshot and source ledgers remain under
/tmp/codexbar-519-20261025-diagnosis/.HemSoft commentedon Oct 25, 2026
Screen confirmed: Gemini Models coding quota
Chief/Franz confirmed in the engineering thread that the affected iOS tiles are Gemini Models five-hour / weekly (coding quota). This confirms the scope of this issue:
antigravity.gemini-5handantigravity.gemini-weeklyunder thegeminiprovider card. Gemini Apps is not the reported path.The reported P0 remains unresolved. The source/provenance checkpoint and one published alternate-consumer snapshot establish available Gemini readings elsewhere, but do not establish what the phone's native
retrieveUserQuotaSummaryresponse contained.Next owned diagnostic: distinguish absent native pools from rejected/present native pools using only the normal response's canonical bucket ID, window, remaining fraction, reset and disabled fields plus response schema/status provenance. The missing evidence is specifically the phone's
groups[].buckets[]entries forgemini-5handgemini-weekly, not another screen identification or general permission. No private endpoint probing, CLI import, shared-account cache substitution or invented availability is justified. No source repair or resolution is claimed.HemSoft commentedon Oct 26, 2026
Native-request preflight and missing diagnostic seam
No eligible existing app-authenticated context was identified on Air: known app preferences have no configured accounts, and the owned UI-test contexts deliberately use synthetic stores that never read Keychain. No unknown credentials/simulator contexts were probed and zero native quota requests were made. The one authorized read could not be executed without obtaining or moving an identity, which is outside the boundary. This does not establish whether the phone has a saved coding session.
The app's current native read is POST
{}to the fixed daily quota-summary endpoint. Its response is decoded in memory; it does not persist raw payloads or a schema/bucket diagnostic. Current Copy Diagnostic explicitly excludes provider responses and only exports fixed failure/configuration/freshness categories. The dashboard report action is not guaranteed for partial unavailable pools. A phone refresh alone will not persist the evidence needed to distinguish absent buckets from rejected buckets.One useful existing phone action for Root to request: Google Gemini card → card menu → Configure Account… → Coding Usage; report only Connect Coding Usage versus Reconnect Coding Usage, plus any fixed status message below it. Do not tap either button; omit account labels/IDs. This checks saved-session presence only, not token validity or backend quota data.
Prepared an implementation-ready, privacy-safe diagnostic plan at
/tmp/codexbar-519-20261025-diagnosis/NATIVE-EVIDENCE-PLAN.md: bounded typed projection at the existing response/parser boundary, one transient account/request-bound observation, and an explicit per-account review/copy action. The projection includes only fixed endpoint/status/schema/type/parse enums and the two canonical Gemini buckets' safe window/fraction/reset facts; no raw responses, headers, credentials, identities, arbitrary strings or unrelated pools. No new requests, logs, global telemetry, persistent cache, provider fallback or changed availability verdict. Regression plan covers actual missing/present/malformed contracts, privacy canaries, no extra calls, late completions and account isolation, followed by current-head native fixture UI/review/checks. A future developer-build phone capture would need separately authorized delivery; no deployment or release is requested/performed here.The P0 remains unresolved. No speculative availability repair, commit, PR or duplicate full workflow was made. Existing PR521 and its evidence/watch remain intact.
HemSoft commentedon Oct 26, 2026
Phone observation recorded; Settings navigation corrected
Franz reported “Reconnect Coding Usage” on October 26, 2026 at 1:43 AM EDT, and clarified that this is in Settings. Original observation. My earlier navigation omitted Settings. The complete existing route is Settings → Accounts & Groups → the affected Google Gemini account → Coding Usage. This answers the saved-session question; do not ask it again or infer that he tapped Reconnect.
At unchanged main
d58713e889fbfe3a025f0966cef5345099418e42, the button expression uses hasGeminiCodingSecret, which reads the account-specificsecretAvailabilityboolean. The label establishes the UI's saved-coding-credential state. It does not parse credentials, check expiration, validate authentication, issue a quota request or prove that Gemini buckets were supplied. No authentication or parser fix follows from the label alone.Smallest next discriminator already exposed by the installed app
Root can request one read-only observation in Settings → Accounts & Groups → the same Google Gemini account → Metrics: report only the fixed reason text, or “no reason shown,” under Gemini Models five-hour, Gemini Models weekly, Other models five-hour and Other models weekly. These are existing metric rows; no toggle changes, refresh, reconnect, screenshot, account label or credential is needed. The rows render unavailable reasons; they do not display numeric quota values, so asking for numbers there would be wrong.
The combiner preserves each coding metric's parser reason, otherwise the coding request's fixed failure message. All four metrics share the same coding response. An auth-specific reason across them supports the authentication-error branch; a transport/generic quota error supports request failure. Other-model rows with no reason alongside unavailable Gemini rows support a pool-specific omission/rejection in the displayed result. Bare Unavailable cannot distinguish omitted from rejected buckets. Disabled is explicit. Existing cached results and lack of per-source response provenance limit all these interpretations; no outcome alone proves the latest HTTP response or token validity.
No usable native response is available on Air, and a phone refresh alone still does not persist schema evidence. If these existing reasons cannot discriminate, the next owned engineering step is the bounded, account-bound, optional native-response diagnostic projection already specified in the retained plan, not speculative reconnection, another provider's quota, or a permissive parser. No source repair is justified yet.
No provider request, auth/reconnection, phone/Home action, build, source change, PR or full UI run was performed in this checkpoint. The P0 remains open and unresolved. PR #521's separate cost-pair evidence and active watch are preserved.
HemSoft commentedon Oct 27, 2026
Likely cause found; fix in PR #529 (merge held for a source-bar decision)
October 27, 2026. New primary evidence: the open-source OpenUsage client hit the same symptom and shipped a fix in robinebers/openusage#1395 (merged October 17). There,
daily-cloudcode-pareturned a successful response with only the other-model pools, which blocked the Gemini and Argon pools that productioncloudcode-pareturns. CodexBar iOS reads only the daily host, and that matches Franz's Gemini Models report and the Chief's October 23 note.PR #529 requests the same RPC from production first. Daily is used only after transport or non-auth HTTP errors, and a successful production response is never filled in with daily pools. The parser, UI, scopes and account isolation are unchanged. Focused tests pass 60/60, and the new regressions fail against the old provider.
What this does not establish:
/usagedocs on October 27.agybinary inspection or credential import.Live comparison against the CLI is pending for Franz. Merging requires accepting "same undocumented service, production host" as the source instead of waiting for Google documentation. That decision went to the Chief. Council: Claude Opus 5.5 (active) · missing: GPT 6.1 Sol (Codex weekly projected 140%, over pace), Muse Wonder Full (quota guard unknown) · adopted: 0 · declined: 0 · Council unavailable, proceeded solo.
Never show the all-full production quota placeholder (#519)
HemSoft commentedon Oct 27, 2026
Chief's decision: source accepted (October 27, 2026, 14:25 ET)
The Chief accepted the production host of the same
v1internalservice the app already uses. No Google-documented contract exists, so requiring one would block this issue indefinitely, and OpenUsage (#1395) ships the same order. The first acceptance criterion is amended: no documented contract exists; production first, daily on error, never mixed.Condition: never show the September 5 all-full placeholder. Per the receipt, that response was HTTP 200 with the same four pools, every
remainingFraction1, and reset times present. PR #529 atfc9e4d8treats a production response whose supplied canonical pools are all full as unusable and asks daily instead. If daily fails, the app shows the unavailable state, not full bars. Regression tests use that shape, and they fail with only the guard line removed.The live CLI comparison does not block merge; the Chief will run it read-only with
agylater.Use the daily backend when a production success has no usable pool (#519
Read Antigravity quota pools from the production Cloud Code backend f…
HemSoft commentedon Oct 27, 2026
Fix merged: PR #529
PR #529 merged at
fd3f1217f6a441fb5c195ebe83a482256b632d72on October 27, 2026, 15:4x ET. The merge was squash, guarded with--match-head-commit 7b61b5aand no admin bypass. Codex was clean on that head, the required SwiftLint passed, and the one Codex P2 thread was fixed and resolved.Behavior on main:
cloudcode-pafirst.Left open for the remaining Definition-of-Done items, which are not agent-verifiable here:
agy /usage;No release, TestFlight or device install was made in this work.
HemSoft commentedon Oct 27, 2026
Read-only comparison on home: inconclusive for iOS host parity
On October 27, 2026, I ran the signed-in
agy -p /usage --output-format jsonon home over SSH without opening a browser or changing sign-in or settings. The fresh invocation did not return; a retry with--print-timeout 25salso remained running beyond that interval, so I stopped the processes I started. No fresh CLI numbers were obtained.The running Desktop CodexBar's locally published snapshot, fetched October 27 at 7:39:54 p.m. EDT, contains these last successful CLI-derived readings. Its provider implementation invokes
agy /usageand maps its bucket fractions to used percentages; remaining below is 100% minus used:These are cached CLI-derived desktop readings, not a fresh independent CLI result. The snapshot does not identify the backend host; CLI host provenance is unknown. The desktop and CLI values therefore cannot be treated as two independent measurements.
At merged iOS commit
fd3f121, if its production response contains these same valid pools and fractions, the all-full guard would not trigger because the weekly pools are below full, and iOS would show those production values. If production returns the all-full placeholder or another eligible error, iOS tries daily; absent pools remain unavailable, and if daily also fails the request is unavailable. HTTP 400/401/403 sign-in errors do not trigger daily fallback. No authenticated iOS production or daily response was observed here, so the actual host, branch, and parity with the CLI remain unverified. There is no evidence of a real mismatch, but a match cannot be claimed either. No code changes, credentials, account IDs, or browser/UI interactions were involved.1 remaining item
HemSoft commentedon Nov 1, 2026
Phone delivery completed for Franz’s October 31 request
1566284351384330565at 11:01 PM EDT.com.hemsoft.CodexBarIOS, from current mainf4b93de7b6715d1ce95b8964c90723184e66e43e. This includes Read Antigravity quota pools from the production Cloud Code backend first #529. The previous device inventory reported development 2.0.0, build 6.This completes the approved phone-build delivery portion. Live quota parity and production commerce/entitlement validation remain open under their existing issues. App launch and screen inspection were not performed: this Home thread’s T3 device inventory exposed no iPhone host, and SSH UI driving was not authorized. This is personal development delivery, not App Store/TestFlight release qualification.
Evidence on Air:
/Users/home/.local/state/codexbar-phone-1566284351384330565/withartifact-proof.json,verification-summary.json,source-manifest.json,device-build.log, and private CoreDevice installation/inventory receipts. Existing source checkout remains clean and untouched.Add trailing comma to the #519 regression fixture (SwiftLint)
HemSoft commentedon Nov 6, 2026
Phone check, November 5, 2026: Gemini Models and Argon still unavailable
Franz checked the phone at 7:24 PM EST. It runs CodexBar 2.0.1 build 6 from main
f4b93de, which includes #529. The Google Gemini card ("Google AI Pro") showed:The same day,
agy /usageon Home read Gemini weekly at about 14% used, so the account has Gemini Models usage. The #529 fix didn't bring the pools back on the device.What the code says about it
Only the daily backend answers without Gemini Models and Argon, so the phone's numbers came from daily. Since #529, daily is asked only when production fails (a transport error or an HTTP status other than 400/401/403) or production's 200 is rejected (unreadable, no current pool, or the all-full placeholder).
One of those branches was a real defect. The parser decoded the summary strictly, so one group without buckets, one bucket without an ID or one wrongly typed field made the whole production response "unreadable". OpenUsage decodes this response one bucket at a time, and its fixtures show production groups with such extra entries. PR #553 fixes this. It also makes the card name the production branch in one fixed sentence whenever daily answered without these pools, without logging any response content.
I can't tell from code which branch the phone hit. No phone response was captured, and no live request was made.
The Other models values (0% with resets exactly one window out) match an unused pool on the daily backend. They can't be told apart from a placeholder without a second reading. The all-full guard covers production only, by the October 27 design. A daily answer is shown as reported.
What would settle it
After a phone build with #553, one refresh of the Gemini card:
agy /usage.The issue stays open. No release, install, credential, CLI import or endpoint probing was involved.
Narrow the #519 changelog line to the backup-service case
Keep Gemini Models and Argon when Google's quota response has unused …
HemSoft commentedon Nov 9, 2026
Phone check, November 9, 2026: still unavailable, and the new note names the branch
Franz installed CodexBar from main
0b099e9(2.0.1 build 6, includes #553) at 12:36 PM EST and checked the Google Gemini card at 12:55 and 1:03 PM EST.The card's #553 note reads:
So production answers HTTP 200 for the app's sign-in, but every canonical pool it supplies has
remainingFraction >= 1.isAllFullPlaceholderrejects that, as intended, and daily answers without the Gemini and Argon pools. The guard is doing its job: production really is showing this sign-in untouched pools while the CLI shows Gemini weekly at 24% used. Strict decoding (#553) was not the branch the phone hits.Likely cause: the quota request names no project
AntigravityUsageProvider.quotaRequestposts{}toretrieveUserQuotaSummary. OpenUsage, whose host order #529 copied, does not. ItsAntigravityUsageClient.quotaSummaryfirst callsloadCodeAssist, takescloudaicompanionProjectfrom the answer, and posts{"project": "<that id>"}. ItsAntigravityProjectQuotaTests.testQuotaSummaryNamesTheAccountsProjectpins that (robinebers/openusage, commit61333460, October 31). A project-less request getting default, all-full pools would explain both today's reading and the September 5 placeholder.This is a hypothesis from source comparison, not a captured response. Next: an owned fix that sends the account's own
cloudaicompanionProjectfrom the app's existingloadCodeAssistcall, keeps production first / daily on error / never mixed and keeps the placeholder guard, then a phone build for Franz to check. OpenUsage also sends Antigravity's own User-Agent andideType: ANTIGRAVITYmetadata. That is out of scope here unless the project alone doesn't fix it.Retry production with {} when Google rejects the named project (#519)
Say when the code-assist lookup repeats (#519)
Ask Google for the account's own project in the coding quota request (#…
Guard the fallback's all-full answer and hedge the #519 changelog (#519)
HemSoft commentedon Nov 9, 2026
Research for Franz's decision on PR 555 (November 9, 2026)
PR #555 is parked with
waiting-on-franz. Franz asked for full research first: whether it works for other users, terms of service, and alternatives. A read-only research pass (no code, PR or live requests) finished at 6:09 PM EST.Findings
cloud-platformanduserinfo.email). The live test that restored all five pools used the Antigravity CLI's OAuth client on Mini, so what Google returns to CodexBar's own client, other accounts and other plans is unknown. A diagnostic build under CodexBar's truthful identity could show what Google allows; it can't prove PR 555.v1internalintegration too, not only PR 555's UA change.Recommendation sent to Franz: keep PR #555 parked. In a future release, stop the disputed coding-quota calls and show an explained "not available" state unless Google gives written permission. Optionally, ask Google whether a read-only monitor may use these endpoints under CodexBar's own OAuth identity.
Open items: verification status of CodexBar's OAuth client and scopes, provenance of the phone's saved grant, CodexBar-client eligibility, and any Google exception. This is research judgment, not legal advice. Awaiting Franz's decision.
HemSoft commentedon Nov 9, 2026
Closing as not planned. Franz decided on November 9, 2026 to withdraw Google Gemini/Antigravity support from CodexBar iOS instead of restoring these pools (research: #519 (comment)). PR #555 is closed unmerged, and the removal is tracked in #556.