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 August 19, 2026, 10:09 AM ET / 14:09 UTC.

Summary
Keep open for product direction: current main has only a Vertex AI Cloud Monitoring path scoped to aiplatform.googleapis.com, while this proposes a distinct Google AI Studio provider with new credential, project-selection, and privacy behavior.

Reproducibility: not applicable. this is a feature request, though the report supplies a credible read-only metric spike rather than a report of broken current behavior.

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 CodexBar own a separate Google AI Studio provider that reads gcloud ADC and Cloud Monitoring, with explicit project selection and project-ID privacy guarantees?	Sponsor a scoped built-in provider: Approve a distinct provider only with a documented metric contract, explicit project choice, and tests proving identifiers are not rendered or logged.

Why: The request fits the shared provider architecture, but it creates a new provider and settings/auth/privacy contract that VISION.md reserves for owner sign-off.

Next step
Owner approval is needed for the new provider’s credential, project-selection, and privacy contract before implementation work should begin.

Review details

Best possible solution:

If sponsored, add a distinct built-in Google AI Studio descriptor and settings flow that reuses only the ADC/Monitoring transport, keeps project identifiers out of UI and logs, and validates native metric pairing with redacted fixtures.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a feature request, though the report supplies a credible read-only metric spike rather than a report of broken current behavior.

Is this the best way to solve the issue?

Unclear: reusing the existing ADC transport is sensible, but a separate provider requires an approved metric, privacy, and settings contract before implementation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A shared ADC implementation must not copy Vertex AI’s current project-ID identity mapping into the new provider if project identifiers must never render or log.
• Google’s native metric schema and observed reporting lag need fixture-backed handling before presenting quota windows as reliable user-facing usage.

Codex review notes: model internal, reasoning high; reviewed against 453174fe13ee.

Label changes

Label changes:

• add P3: This is a well-scoped but optional new provider capability awaiting product sponsorship rather than a broken existing workflow.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a well-scoped but optional new provider capability awaiting product sponsorship rather than a broken existing workflow.

Evidence reviewed

What I checked:

• Current provider boundary: Vertex AI’s Cloud Monitoring filters explicitly select only the aiplatform.googleapis.com service, so current main does not implement native Google AI Studio metric collection. (Sources/CodexBarCore/Providers/VertexAI/VertexAIOAuth/VertexAIUsageFetcher.swift:78, 453174fe13ee)
• Reusable authentication seam: The existing Vertex credential store already reads gcloud ADC locations and resolves a selected Cloud project, making transport reuse plausible after product approval. (Sources/CodexBarCore/Providers/VertexAI/VertexAIOAuth/VertexAIOAuthCredentials.swift:70, 453174fe13ee)
• Plugin boundary: Local provider plugins cannot use subprocesses, local files, or OAuth, so the documented plugin surface cannot safely obtain gcloud ADC for this proposed integration. (docs/plugins.md:11, 453174fe13ee)
• Product policy: VISION.md welcomes provider coverage that follows shared patterns, but classifies new features and provider additions with unclear auth or privacy behavior as requiring sign-off. (VISION.md:20, 453174fe13ee)
• Release and current-main check: The latest shipped v0.53.0 Vertex source uses the same aiplatform.googleapis.com selector; current main is not contained by a tag and has no Google AI Studio or generativelanguage.googleapis.com implementation match. (Sources/CodexBarCore/Providers/VertexAI/VertexAIOAuth/VertexAIUsageFetcher.swift:81, 5a2a70458d95)
• History attribution: Current-line blame reaches the shallow-history boundary credited to Peter Steinberger; deeper feature history could not be loaded from the partial clone, so ownership is routed with medium confidence. (Sources/CodexBarCore/Providers/VertexAI/VertexAIOAuth/VertexAIUsageFetcher.swift:78, 5a2a70458d95)

Likely related people:

• steipete: The visible blame boundary for the Vertex Cloud Monitoring and ADC implementation is Peter Steinberger; the local partial history cannot establish earlier ownership. (role: recent area contributor; confidence: medium; commits: 453174fe13ee, 5a2a70458d95; files: Sources/CodexBarCore/Providers/VertexAI/VertexAIOAuth/VertexAIUsageFetcher.swift, Sources/CodexBarCore/Providers/VertexAI/VertexAIOAuth/VertexAIOAuthCredentials.swift, docs/vertexai.md)

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.