feat: Add Vertex AI Claude Proxy (Express.js)

[zaherweb-2]

• Add vertex-ai-proxy/ directory with Express.js proxy server
• Supports both OpenAI (/v1/chat/completions) and Anthropic (/v1/messages) formats
• Uses google-auth-library for GCP authentication (no SDK conflicts)
• Full streaming support with SSE
• Image and file processing support
• Automatic token refresh

Models supported:

• Claude 4.x: sonnet-4-5, sonnet-4, opus-4, opus-4-5, opus-4-1, haiku-4-5
• Claude 3.x: 3-7-sonnet, 3-5-sonnet-v2, 3-5-haiku, 3-opus, 3-haiku

NPM scripts added:

• backend:dev now starts both API and proxy concurrently
• backend:dev:no-proxy for API only
• vertex-proxy, vertex-proxy:install, vertex-proxy:dev

Closes #XXXX

Hint

• We can also add all of the vertex AI Model Garden models, but I started with Claude.

[danny-avila]

There’s another PR open, how does it compare? #9798

[zaherweb-2]

There’s another PR open—how does it compare? #9798

Hello @danny-avila,
First of all, thank you for the quick reply.

I took a look at the other open PR (#9798). I think Ziyann did a great job overall, and the direction makes sense. That said, his implementation relies on the Anthropic + LangChain SDKs. While they do support calling Vertex AI models, in practice it can introduce dependency complexity and versioning issues—especially when multiple providers and streaming transports are involved.

The main concerns I ran into were:

• Conflicts between different library and dependency versions
• Extra transitive dependencies that are hard to control in a larger app
• Fragility over time when upstream packages change

This was also mentioned in Ziyann’s PR, for example:

Note that tslib has to be overridden to version 2 to avoid this error caused by @smithy/eventstream-codec@2.2.0 and cohere-ai using a very old version of @aws-crypto/crc32, pulling in version 1.

The problem with this kind of workaround is that it forces specific versions to be pinned, and it won’t always remain stable across environments (or as new releases land). It can also make debugging and upgrades harder for maintainers and users since the failure mode often shows up as runtime or build-time incompatibilities.

---

My implementation takes a different approach:

• I built a lightweight Express.js proxy server from scratch specifically for connecting to Vertex AI
• No dependency/version conflicts now—or likely in the future—because it avoids the SDK chain that introduces most of the transitive dependencies
• Supports both OpenAI (/v1/chat/completions) and Anthropic (/v1/messages) request/response formats
• Uses google-auth-library for GCP authentication (avoids SDK conflicts and keeps auth behavior explicit)
• Full streaming support via SSE

---

In short: Ziyann’s PR is great if we’re comfortable accepting the SDK dependency surface area. My approach is more “thin adapter / minimal deps”: it keeps the integration small, predictable, and easier to maintain long-term, while still matching the APIs and streaming behavior expected by clients.

[zaherweb-2]

Hello @danny-avila,
I know that you are very busy, but I am just checking Is their anything from my side that you want me to do ?

[isaacraja]

@zaherweb-2 - Just curious, This proxy based approach is similar to litellm - Shouldn't this be in a different repo?