GoogleGenerativeAI client library failing on Vercel

Discussions
1

Problem Description:

Our Vercel serverless function, deployed to a Sydney region, is attempting to use the @google/generative-ai client library (version ^0.24.1 ) to interact with the Google Gemini API. While the GoogleGenerativeAI class is correctly imported, the instantiation new GoogleGenerativeAI(API_KEY) does not return a proper instance of the class . Instead, it appears to return a plain JavaScript object that only contains the apiKey , lacking any of the class’s methods.

This results in a consistent runtime TypeError: genAIInstance.listModels is not a function when attempting to call any methods on the supposedly-instantiated client.

Steps Taken & Observations:

  1. Initial Problem ( 404 Not Found ): The application initially experienced a 404 Not Found error when deployed to a US Vercel region, indicating regional model availability issues with the Gemini API.

  2. Vercel Region Change: Following advice, we successfully changed the Vercel deployment region to Sydney.

  3. Client Library Failure: Upon deploying to Sydney, the 404 Not Found was replaced by the current TypeError: genAIInstance.listModels is not a function .

  4. Extensive Debugging & Isolation:

    • Minimal Reproduction: We created a brand new, minimal Vercel project with a single serverless function ( api/gemini-test.ts ) that solely imports and instantiates the GoogleGenerativeAI client, and then attempts to call listModels() . This minimal setup reproduces the exact same runtime error.

    • TypeScript Correctness: package.json specifies “type”: “module” and @google/generative-ai": “^0.24.1” . tsconfig.json is standard. npm install and cache cleans have been performed multiple times. TypeScript compilation now passes without errors (even when forcing (genAIInstance as any).listModels() ).

    • Runtime Inspection (via console.log ):

      • console.log(“Imported GoogleGenerativeAI:”, GoogleGenerativeAI) outputs [class GoogleGenerativeAI] , confirming the class itself is correctly imported.

      • console.log(“genAIInstance object keys:”, Object.keys(genAIInstance)) outputs [ ‘apiKey’ ] .

      • console.log(“genAIInstance prototype keys:”, Object.keys(Object.getPrototypeOf(genAIInstance))) outputs .

      • This conclusively shows that new GoogleGenerativeAI(API_KEY) is returning a simple object { apiKey: ‘…’ } instead of an instance of the GoogleGenerativeAI class.

    • Stack Trace Observation: The stack trace consistently points to /opt/rust/nodejs.js , suggesting a custom or wrapped Node.js runtime environment on Vercel.

Hypothesis:

It appears there is an incompatibility or interception occurring within the Vercel serverless function runtime (likely related to /opt/rust/nodejs.js ) that is preventing the GoogleGenerativeAI class from being properly instantiated via the new operator. This runtime interference is causing the constructor to return a basic object instead of a full class instance with its methods.

Impact:

This issue prevents us from using the official and recommended @google/generative-ai client library for interacting with the Google Gemini API within our Vercel deployments. We are currently resorting to making direct HTTP requests to the Gemini API as a workaround, but this bypasses the benefits of the client library.

Request:

I’m seeking insights and potential solutions from the Vercel community and staff regarding this unusual runtime behavior. Has anyone encountered similar issues with the @google/generative-ai library, or other complex client libraries, where class instantiation seems to be interfered with in the Vercel serverless environment?

Specifically, I’m curious if there are known workarounds or configurations that might resolve this, or if this indicates a deeper platform-level interaction with how Node.js class constructors operate in Vercel’s custom runtime ( /opt/rust/nodejs.js ).

Any advice, alternative approaches, or confirmation of similar experiences would be greatly appreciated. Thank you!