Repository navigation
Add Google AI Studio usage via Cloud Monitoring #3072
Description
Activity
- added
on Aug 19, 2026 Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 5, 2026, 10:54 AM ET / 14:54 UTC.
Summary
Keep open in the owner’s provider queue. Current main and v0.56.6 lack this capability; the contributor’s user-ADC trace strengthens feasibility, but the owner has not approved implementation.Reproducibility: not applicable. this requests new provider coverage rather than reporting broken behavior; the supplied direct-API trace supports feasibility and was not rerun.
Ways to help us reproduce this
- Add a screenshot or short recording showing the behavior.
- Add expected vs actual behavior.
Maintainer decision needed
Question Recommendation Should the provider batch accept a separate AI Studio provider using an explicit project plus existing user ADC, with delayed telemetry and no cloud configuration changes? Sponsor the narrow native provider: Approve an explicitly configured user-ADC v1 using shared provider UI, with service-account expansion and unrelated billing features deferred. Why: Feasibility evidence supports the proposed credential path, but the owner has only queued the proposal and authentication, privacy, and presentation scope require sign-off.
Next step
Owner approval of the project-selection, user-ADC, and telemetry-presentation contract is required before implementation; automated repair is inappropriate for this new capability.Review details
Best possible solution:
If sponsored, use an opt-in native provider with explicit project selection, reusable ADC/Monitoring transport, strict quota pairing, redacted diagnostics, and clearly dated telemetry.
Do we have a high-confidence way to reproduce the issue?
Not applicable: this requests new provider coverage rather than reporting broken behavior; the supplied direct-API trace supports feasibility and was not rerun.
Is this the best way to solve the issue?
Yes, conditionally: native integration fits existing ADC ownership, while plugins lack the required access; Vertex-specific metric parsing and identity rendering should not be reused unchanged.
AGENTS.md: found and applied where relevant.
Remaining risk / open question:
- The single-project spike does not establish metric availability and pairing behavior across all supported models, tiers, and locations.
- Whether delayed quota telemetry should drive the primary usage display remains a product decision; the observed lag was approximately 48 minutes.
Codex review notes: model internal, reasoning high; reviewed against 1696c7a71c94.
Label changes
Label justifications:
P3: This is optional provider coverage awaiting product approval, with no reported regression or blocked existing workflow.
Evidence reviewed
What I checked:
- Owner explicitly queued the proposal: The owner placed this proposal in the provider decision batch and favored explicit configuration over automatic detection: Add Google AI Studio usage via Cloud Monitoring #3072 (comment). This is engagement and routing guidance, not implementation approval.
- User ADC feasibility clarification: The contributor supplied redacted direct-API output using authorized_user ADC, without service-account credentials: 14 populated native series, six unambiguous quota pairs, and 2,867 seconds of observed lag. This corrects the service-account-only setup assumption: Add Google AI Studio usage via Cloud Monitoring #3072 (comment). These are contributor-reported observations; no embedded commands were executed.
- Current Monitoring implementation targets Vertex AI: The existing fetcher queries Service Runtime quota metrics restricted to aiplatform.googleapis.com. Its parser matches quota metric, limit name, and location; it does not implement the proposed native Gemini metric families, model/tier pairing, or telemetry timestamps. (
Sources/CodexBarCore/Providers/VertexAI/VertexAIOAuth/VertexAIUsageFetcher.swift:78, 1696c7a71c94) - Existing user ADC contract: The credential store already parses user ADC client credentials and refresh tokens. The corresponding user-ADC fixture test verifies credentials and project loading, so user ADC is an established native integration pattern rather than a service-account-only path. (
Sources/CodexBarCore/Providers/VertexAI/VertexAIOAuth/VertexAIOAuthCredentials.swift:185, 1696c7a71c94) - Plugin capability boundary: Local plugin documentation excludes subprocesses, local files, and OAuth. The QuickJS host function list independently exposes settings, HTTP, cookies, cache, logging, and formatting helpers without an ADC broker; a plugin cannot directly preserve the proposed gcloud credential contract. (
Sources/CodexBarCore/Plugins/QuickJSProviderPluginEngine.swift:458, 1696c7a71c94) - No current AI Studio integration found: The first-party provider manifest contains Gemini and Vertex AI but no AI Studio provider. Searches across source, tests, documentation, README, and changelog found no AI Studio or generativelanguage integration; Gemini documentation identifies its separate CLI OAuth/private-quota path. (
Sources/CodexBarCore/Providers/ProviderManifest.swift:7, 1696c7a71c94)
Likely related people:
- steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
- chaurasiak: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
How this review workflow works
- ClawSweeper keeps one durable marker-backed review comment per issue or PR.
- Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
- A fresh review can be triggered by eligible
@clawsweeper re-reviewcomments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch. - PR/issue authors and users with repository write access can comment
@clawsweeper re-reviewor@clawsweeper re-runon an open PR or issue to request a fresh review only. - Maintainers can also comment
@clawsweeper reviewto request a fresh review only. - Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
- Maintainer-only repair and merge flows require explicit commands such as
@clawsweeper autofix,@clawsweeper automerge,@clawsweeper fix ci, or@clawsweeper address review. - Maintainers can comment
@clawsweeper explainto ask for more context, or@clawsweeper stopto stop active automation.
Thanks — agreed. To make the proposed contract explicit:
- Auth: gcloud ADC only; no browser cookies, private endpoints, or API-key handling.
- Project selection: require an explicit project choice and never mutate gcloud or Google Cloud configuration.
- Metric contract: read-only native
generativelanguage.googleapis.comrequest/token series; pair quota/usageand/limitonly when metric family, model, tier, location, and limit name match unambiguously. Ambiguous pairs fail soft. - Privacy: project and credential label values are query/pairing inputs only; never render or log them. Cover this with redacted fixtures and explicit tests.
- UX: identify the source as delayed Cloud Monitoring telemetry, expose its update time, and avoid presenting it as an immediate rate-limit counter.
A screenshot would not add meaningful evidence before implementation because this is API feasibility rather than broken UI behavior. The read-only spike provides the expected-vs-observed evidence: requests, input/output tokens, model labels, and six unambiguous quota pairs were available, with roughly 48 minutes of observed lag.
I’ll wait for owner sign-off before starting production implementation.
Triage: provider proposals are batched for an owner decision, so parking this with the queue (Vercel AI Gateway #2975, Notion #2888, Atlas #2714, etc.). Noting the design constraint for whenever it's picked up: Cloud Monitoring requires a GCP project + service-account auth, which is a heavier setup than most CodexBar providers — it would likely land as an explicitly-configured, API-key-style provider rather than an auto-detected one.
Thanks for the thoughtful triage and for parking this with the provider queue.
One clarification for the eventual owner decision: the successful spike did not use a service account. It used
ordinary user ADC created bygcloud auth application-default loginon an account that already had read access to Cloud
Monitoring.Exact commands and redacted output
Authentication proof
$ gcloud version | head -1 Google Cloud SDK 581.0.0 $ gcloud auth application-default login ... Credentials saved to file: <redacted>/application_default_credentials.json $ jq -r '.type' ~/.config/gcloud/application_default_credentials.json authorized_user $ jq -r '.quota_project_id // "unset"' ~/.config/gcloud/application_default_credentials.json unset $ gcloud auth application-default print-access-token >/dev/null && echo "ADC token available" ADC token available
No service-account key JSON, service-account impersonation, API key, browser cookie, or
GOOGLE_APPLICATION_CREDENTIALSoverride was used. The access token was short-lived and never written to the report or
logs.Minimal direct API reproduction
This reproduces the relevant read-only calls on macOS for a project that already has Gemini API traffic and an enabled
Monitoring API. The user needsmonitoring.metricDescriptors.listandmonitoring.timeSeries.list; the commands do not
enable APIs or change IAM/project configuration.GEMINI_PROJECT_ID="your-existing-project-id" GEMINI_ADC_TOKEN="$(gcloud auth application-default print-access-token)" GEMINI_START_TIME="$(date -u -v-168H '+%Y-%m-%dT%H:%M:%SZ')" GEMINI_END_TIME="$(date -u '+%Y-%m-%dT%H:%M:%SZ')" curl -sS -G \ -H "Authorization: Bearer ${GEMINI_ADC_TOKEN}" \ -H "X-Goog-User-Project: ${GEMINI_PROJECT_ID}" \ --data-urlencode 'filter=metric.type = starts_with("generativelanguage.googleapis.com/")' \ --data-urlencode 'pageSize=1000' \ "https://monitoring.googleapis.com/v3/projects/${GEMINI_PROJECT_ID}/metricDescriptors" \ | jq '{ descriptor_count: (.metricDescriptors | length), selected_generate_content_metrics: ([ .metricDescriptors[].type | select(startswith("generativelanguage.googleapis.com/")) | select(contains("generate_content")) | select((contains("usage")) or (endswith("/limit"))) ] | unique | length) }'
Observed output:
{ "descriptor_count": 146, "selected_generate_content_metrics": 36 }Example native quota query:
for GEMINI_QUOTA_KIND in usage limit; do GEMINI_METRIC_TYPE="generativelanguage.googleapis.com/quota/generate_content_paid_tier_2_requests/${GEMINI_QUOTA_KIND}" curl -sS -G \ -H "Authorization: Bearer ${GEMINI_ADC_TOKEN}" \ -H "X-Goog-User-Project: ${GEMINI_PROJECT_ID}" \ --data-urlencode "filter=metric.type=\"${GEMINI_METRIC_TYPE}\"" \ --data-urlencode "interval.startTime=${GEMINI_START_TIME}" \ --data-urlencode "interval.endTime=${GEMINI_END_TIME}" \ --data-urlencode 'view=FULL' \ --data-urlencode 'pageSize=1000' \ "https://monitoring.googleapis.com/v3/projects/${GEMINI_PROJECT_ID}/timeSeries" \ | jq '[.timeSeries[] | { metric: .metric.type, model: "<redacted-model>", limit_name: .metric.labels.limit_name, location: .resource.labels.location, latest_value: (.points[0].value.int64Value // .points[0].value.doubleValue) }]' done unset GEMINI_ADC_TOKEN
Redacted excerpts from the actual run included unambiguous per-model request pairs:
[ { "limit_name": "GenerateRequestsPerMinutePerProjectPerModel-PaidTier2", "model": "<redacted-model-a>", "usage": 3, "limit": 1000, "used_percent": 0.3 }, { "limit_name": "GenerateRequestsPerMinutePerProjectPerModel-PaidTier2", "model": "<redacted-model-b>", "usage": 18, "limit": 2000, "used_percent": 0.9 } ]Full spike result
For the 168-hour read-only run:
- 146 native Gemini metric descriptors were discovered;
- 36 relevant
generate_contentmetric types were queried; - 14 populated native series were returned;
- 6 quota usage/limit pairs matched unambiguously, with 0 ambiguous and 0 unmatched;
- model-level request, input-token, and output-token data was present;
- the highest observed input-token quota usage was
1,172,772 / 3,000,000(39.0924%); - output-token totals for the two redacted models were
16,091and75,244over the selected window; - generic request-control totals were
12and152; - the closest observed data point lagged collection time by 2,867 seconds (about 48 minutes);
- no authentication, permission, pagination, or parsing errors occurred.
So I agree that this should be explicitly configured rather than auto-detected, but the minimum setup can be **project ID
- existing user ADC**. Service-account support could be optional rather than required for v1, and CodexBar would never
change the user's gcloud project or Google Cloud configuration.
The Cloud Monitoring endpoint is documented, and the reporter’s clarification confirms existing user ADC is sufficient; a service-account key is not inherently required. Bundled plugins currently lack ADC acquisition and OAuth refresh. Keeping this open for a shared, project-scoped auth capability before implementing delayed Gemini API telemetry. No Google account or project configuration was changed.
Thanks @brzvsk. The native Gemini metrics are documented, but their aggregation/model matching differs from Vertex quota data. Plugins also lack project-scoped ADC acquisition/refresh. Closing the configuration-only approach; AI Studio needs that shared auth capability and a delayed-telemetry contract. Existing user ADC can work; a service-account key is not inherently required.
Summary
Could CodexBar add a separate Google AI Studio provider for project-level Gemini API usage through the official
Cloud Monitoring API and gcloud Application Default Credentials?
This is distinct from:
aiplatform.googleapis.com;Evidence
I ran a read-only seven-day spike against an active project. It made no Gemini generation calls, imported no cookies,
and changed no APIs, IAM, or project settings.
generativelanguage.googleapis.com/*series;Native Gemini metrics were sufficient; generic Service Runtime quota metrics were not.
Proposed v1
A local provider plugin cannot support this safely today because plugins cannot access gcloud/ADC.
Would a separate built-in Google AI Studio provider fit CodexBar's provider boundary?
If accepted, I can prepare a focused implementation that reuses the existing Vertex AI ADC and Cloud Monitoring code
where practical, with fixture-only tests and no live credentials.