Add Google AI Studio usage via Cloud Monitoring

[brzvsk]

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.

[clawsweeper]

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.

[brzvsk]

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.

[steipete]

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.

[brzvsk]

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.

[steipete]

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.