vxcontrol/pentagi
1
0
Fork 0
mirror of https://github.com/vxcontrol/pentagi.git synced 2026-07-20 23:57:11 -04:00
Code Issues 45 Packages Projects Releases 9 Wiki Activity

[GH-ISSUE #321] [Enhancement]: Native Google Vertex AI provider (service-account auth) #104

New Issue
Open
opened 2026-06-06 22:09:09 -04:00 by yindo · 0 comments
yindo commented 2026-06-06 22:09:09 -04:00
Owner
Copy Link
Copy Source

Originally created by @mrigankad on GitHub (May 31, 2026).
Original GitHub issue: https://github.com/vxcontrol/pentagi/issues/321

Summary

Add a native Google Vertex AI provider (vertex) so users can authenticate with GCP project credentials instead of an API key. Today the only Google option, gemini (GEMINI_SERVER_URL=https://generativelanguage.googleapis.com), targets AI Studio and does not accept Vertex project/service-account credentials. Anthropic Claude-on-Vertex is likewise unsupported.

Motivated by #310, where a user could not configure Vertex AI keys. The current workaround is to front Vertex with a LiteLLM proxy and use the custom provider — functional but requires running extra infrastructure.

Goals

  • Authenticate via GCP Application Default Credentials / a service-account JSON key, with explicit project ID and region/location.
  • Support Gemini models on Vertex; ideally also Claude-on-Vertex (Anthropic models served through Vertex).

Non-goals

  • Replacing the existing AI Studio gemini provider (kept as-is).
  • Per-request dynamic credentials / multi-project routing (future work).

Proposed implementation

Follows the repo's documented "Adding a New LLM Provider" checklist (CLAUDE.md). Concrete touch points verified against main:

  1. Provider impl — backend/pkg/providers/vertex/vertex.go implementing provider.Provider. The official genai/Vertex Go SDK exposes Gemini-on-Vertex; the existing backend/pkg/providers/gemini/gemini.go is the closest reference and the request-shaping logic may be largely reusable behind a Vertex transport/auth layer.
  2. Constants — add ProviderVertex ProviderType = "vertex" and DefaultProviderNameVertex in backend/pkg/providers/provider/provider.go.
  3. Registration — wire into DefaultProviderConfig, NewProvider, buildProviderFromConfig, GetProvider in backend/pkg/providers/providers.go.
  4. REST validation — add vertex to the Valid() whitelist in backend/pkg/server/models/providers.go (without this the REST API returns 422).
  5. Config — add env keys in backend/pkg/config/config.go, e.g.:
    • VERTEX_PROJECT_ID
    • VERTEX_LOCATION (e.g. us-central1)
    • VERTEX_CREDENTIALS_FILE (path to service-account JSON; fall back to ADC / GOOGLE_APPLICATION_CREDENTIALS when empty)
    • optionally VERTEX_SERVER_URL for regional/private endpoints
  6. Migration — goose migration in backend/migrations/sql/ adding 'vertex' to the PROVIDER_TYPE enum, following the enum-swap pattern in 20260227_120000_add_cn_providers.sql (Up: recreate enum incl. vertex; Down: delete vertex rows then recreate without it).
  7. Frontend — provider icon frontend/src/components/icons/vertex.tsx registered in provider-icon.tsx, plus settings-page wiring.
  8. Docs/.env.example — document the new keys.

Open questions for maintainers

  1. Adapter strategy — extend/parameterize the existing gemini adapter to support a Vertex transport+auth mode, or a fully separate vertex package? (Affects code reuse vs. clean separation.)
  2. Scope — Gemini-on-Vertex only first, or include Claude-on-Vertex in the same provider? Claude-on-Vertex uses the Anthropic message schema, which may argue for routing it through the anthropic adapter with a Vertex auth/endpoint mode instead.
  3. Auth surface — is service-account JSON file + ADC sufficient, or is workload-identity / bearer-token (mirroring the Bedrock multi-auth approach) also desired?
  4. Web settings — should Vertex be configurable from the Settings UI like other providers, or env-only initially given the credential-file requirement?

I'm happy to implement this once direction on Q1–Q2 is confirmed. Note the DB migration + GCP auth flow are areas that will need maintainer review and GCP credentials to test end-to-end.

References

Originally created by @mrigankad on GitHub (May 31, 2026). Original GitHub issue: https://github.com/vxcontrol/pentagi/issues/321 ### Summary Add a native **Google Vertex AI** provider (`vertex`) so users can authenticate with GCP project credentials instead of an API key. Today the only Google option, `gemini` (`GEMINI_SERVER_URL=https://generativelanguage.googleapis.com`), targets **AI Studio** and does not accept Vertex project/service-account credentials. Anthropic Claude-on-Vertex is likewise unsupported. Motivated by #310, where a user could not configure Vertex AI keys. The current workaround is to front Vertex with a LiteLLM proxy and use the `custom` provider — functional but requires running extra infrastructure. ### Goals - Authenticate via GCP **Application Default Credentials** / a service-account JSON key, with explicit **project ID** and **region/location**. - Support Gemini models on Vertex; ideally also **Claude-on-Vertex** (Anthropic models served through Vertex). ### Non-goals - Replacing the existing AI Studio `gemini` provider (kept as-is). - Per-request dynamic credentials / multi-project routing (future work). ### Proposed implementation Follows the repo's documented "Adding a New LLM Provider" checklist (CLAUDE.md). Concrete touch points verified against `main`: 1. **Provider impl** — `backend/pkg/providers/vertex/vertex.go` implementing `provider.Provider`. The official `genai`/Vertex Go SDK exposes Gemini-on-Vertex; the existing `backend/pkg/providers/gemini/gemini.go` is the closest reference and the request-shaping logic may be largely reusable behind a Vertex transport/auth layer. 2. **Constants** — add `ProviderVertex ProviderType = "vertex"` and `DefaultProviderNameVertex` in `backend/pkg/providers/provider/provider.go`. 3. **Registration** — wire into `DefaultProviderConfig`, `NewProvider`, `buildProviderFromConfig`, `GetProvider` in `backend/pkg/providers/providers.go`. 4. **REST validation** — add `vertex` to the `Valid()` whitelist in `backend/pkg/server/models/providers.go` (without this the REST API returns 422). 5. **Config** — add env keys in `backend/pkg/config/config.go`, e.g.: - `VERTEX_PROJECT_ID` - `VERTEX_LOCATION` (e.g. `us-central1`) - `VERTEX_CREDENTIALS_FILE` (path to service-account JSON; fall back to ADC / `GOOGLE_APPLICATION_CREDENTIALS` when empty) - optionally `VERTEX_SERVER_URL` for regional/private endpoints 6. **Migration** — goose migration in `backend/migrations/sql/` adding `'vertex'` to the `PROVIDER_TYPE` enum, following the enum-swap pattern in `20260227_120000_add_cn_providers.sql` (Up: recreate enum incl. `vertex`; Down: delete `vertex` rows then recreate without it). 7. **Frontend** — provider icon `frontend/src/components/icons/vertex.tsx` registered in `provider-icon.tsx`, plus settings-page wiring. 8. **Docs/`.env.example`** — document the new keys. ### Open questions for maintainers 1. **Adapter strategy** — extend/parameterize the existing `gemini` adapter to support a Vertex transport+auth mode, or a fully separate `vertex` package? (Affects code reuse vs. clean separation.) 2. **Scope** — Gemini-on-Vertex only first, or include **Claude-on-Vertex** in the same provider? Claude-on-Vertex uses the Anthropic message schema, which may argue for routing it through the `anthropic` adapter with a Vertex auth/endpoint mode instead. 3. **Auth surface** — is service-account JSON file + ADC sufficient, or is workload-identity / bearer-token (mirroring the Bedrock multi-auth approach) also desired? 4. **Web settings** — should Vertex be configurable from the Settings UI like other providers, or env-only initially given the credential-file requirement? I'm happy to implement this once direction on Q1–Q2 is confirmed. Note the DB migration + GCP auth flow are areas that will need maintainer review and GCP credentials to test end-to-end. ### References - #310 (original Vertex AI request) - CLAUDE.md → "Adding a New LLM Provider" - LiteLLM Vertex docs: https://docs.litellm.ai/docs/providers/vertex
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
help wanted
pull-request
Mirrored from GitHub Pull Request
 question
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: vxcontrol/pentagi#104
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?