Add Google AI Studio usage via Cloud Monitoring

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:

Gemini, which uses Gemini CLI OAuth and private quota APIs;
Vertex AI, which monitors aiplatform.googleapis.com;
Add Google and xAI models.dev pricing lookup #2377, which adds model pricing lookup rather than project quota telemetry.

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.

14 populated native generativelanguage.googleapis.com/* series;
6 unambiguous quota usage/limit pairs;
request, input/output token, and model-level data available;
about 48 minutes of observed reporting lag.

Native Gemini metrics were sufficient; generic Service Runtime quota metrics were not.

Proposed v1

Built-in provider using ADC, reusing/refactoring Vertex AI's Cloud Monitoring transport.
Explicit project selection; no automatic Google Cloud changes.
Primary window: highest unambiguous quota usage.
Details: project/model request and token totals plus update time.
No browser cookies, private AI Studio endpoints, per-key breakdown, billing/cost, or cross-provider fallback.
Never render or log project/credential label values.

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.

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-review comments, 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-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to 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 explain to ask for more context, or @clawsweeper stop to 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.com request/token series; pair quota /usage and /limit only 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 by gcloud auth application-default login on 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_CREDENTIALS override 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 needs monitoring.metricDescriptors.list and monitoring.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_content metric 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,091 and 75,244 over the selected window;
generic request-control totals were 12 and 152;
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.

@brzvsk

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.

Navigation Menu

Repository navigation

Add Google AI Studio usage via Cloud Monitoring #3072

Summary

Evidence

Proposed v1

Authentication proof

Minimal direct API reproduction

Full spike result

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Add Google AI Studio usage via Cloud Monitoring #3072

Description

Summary

Evidence

Proposed v1

Activity

clawsweeper commented on Aug 19, 2026

brzvsk commented on Aug 19, 2026

steipete commented on Aug 19, 2026

brzvsk commented on Aug 19, 2026

Authentication proof

Minimal direct API reproduction

Full spike result

steipete commented on Sep 24, 2026

steipete commented on Oct 8, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions