If you call Gemini from a web or mobile app through Firebase AI Logic (firebase/ai), check one line of your initialization code before upgrading firebase to 13.x. In firebase 13.0.0, published to npm on October 8, 2026 Japan time (October 7 UTC), VertexAIBackend is gone. With its replacement, AgentPlatformBackend, if you specify nothing, the region where the model is called changes from us-central1 to global.
For companies whose contracts or internal rules dictate where data is processed, an SDK upgrade can directly become a change in processing location. Based on the original changelog text and the results of running 12.19.0 and 13.0.0 locally, we lay out the migration steps. Network traffic was stubbed locally, and we did not connect to any Google services.
What was removed in 13.0.0
The changelog for @firebase/ai 3.0.0 (bundled with firebase 13.0.0) reads as follows.
Removed the previously deprecated
VertexAIBackend(andBackendType.VERTEX_AI). UseAgentPlatformBackend(andBackendType.AGENT_PLATFORM) instead.
In the type definitions, AgentPlatformBackend is described as the configuration for the "Agent Platform Gemini API (formerly known as the Vertex AI Gemini API)." It is the same line of API under a new name, and GoogleAIBackend, which uses the Gemini Developer API, remains unchanged.
We compared the names that are actually exported.
firebase 12.19.0: AgentPlatformBackend Backend BackendType GoogleAIBackend VertexAIBackend getAI
firebase 13.0.0: AgentPlatformBackend Backend BackendType GoogleAIBackend getAI
12.19.0 already includes AgentPlatformBackend. This means you can switch only the backend while staying on 12.x, before upgrading to 13.
The default region becomes global
The changelog explains that the only difference is the default region.
The default location for
AgentPlatformBackendisglobal, whereas the default location forVertexAIBackendwasus-central1. To useus-central1withAgentPlatformBackend, specifygetAI(app, { backend: new AgentPlatformBackend('us-central1') })when initializing the SDK. However, note that most new Gemini models do not supportus-central1.
We stubbed fetch and recorded the URLs that generateContent calls.

There are three key points.
- Simply replacing
new VertexAIBackend()withnew AgentPlatformBackend()changes the destination fromlocations/us-central1tolocations/global - If you pass an argument as in
new AgentPlatformBackend('asia-northeast1'), the URL uses that region. However, the SDK does not check the combination of region and model, so you will not know whether a combination is unsupported until you make the call getAI(app)without a specified backend uses the Gemini Developer API (GoogleAIBackend) and does not include a region in the URL. Apps written this way are not affected by this region change
The changelog also states that "most new Gemini models do not support us-central1." According to Firebase's region guidance (checked on October 16, 2026), only five regions are available for Gemini 3.x and later models: global, us, eu, europe-west2 (London), and asia-southeast1 (Singapore). Both us-central1 and Tokyo's asia-northeast1 appear only in the list for older models such as Gemini 2.5. The guidance explains that specifying an unsupported region results in a 404 error saying the model was not found.
For global, the documentation explains that requests are processed somewhere among the available models worldwide. Companies that want to restrict the processing location to Japan or a specific region should assume that, as long as they use Gemini 3.x or later through Firebase AI Logic, they cannot choose a region within Japan, and then decide, in light of their internal rules, whether to accept global or to specify us, eu, or another region.
Two places where TypeScript fails
In 13.0.0, Part, which represents message parts, became a "discriminated union with explicit type properties." Type-checking code that passes on 12.19.0 against 13.0.0 produced the following errors.
error TS2305: Module '"firebase/ai"' has no exported member 'VertexAIBackend'.
error TS2322: Type '{ text: string; }' is not assignable to type 'Part'.
Property 'type' is missing in type '{ text: string; }' but required in type 'TextPart'.
error TS2339: Property 'text' does not exist on type 'Part'.
The second is where chat history is passed, and the third is where text is extracted from the response parts. Fixing them as follows made the code pass on 13.0.0.
import { getAI, getGenerativeModel, AgentPlatformBackend } from 'firebase/ai';
const ai = getAI(app, { backend: new AgentPlatformBackend('global') }); // 既定値でも明示しておく
const model = getGenerativeModel(ai, { model: 'gemini-3.5-flash' });
const chat = model.startChat({
history: [{ role: 'user', parts: [{ type: 'text', text: 'こんにちは' }] }],
});
const r = await chat.sendMessage('続きをお願いします');
const first = r.response.candidates?.[0]?.content.parts[0];
const text = first?.type === 'text' ? first.text : undefined;
Conversely, this fix caused a type error on 12.19.0 ('type' does not exist in type 'TextPart'). The part type fixes must be made at the same time as the upgrade to 13.
We also checked runtime behavior. 13.0.0 strips type when sending (the body is {"text":"hi"}) and returns response parts with type: "text" attached. Passing old history without type, saved in Firestore or elsewhere, to startChat in 13.0.0 did not cause a runtime error and was sent successfully. Since it only fails at the type level, converting saved data is not required. Code that only extracts strings with response.text() did not produce type errors.
Deprecated generation parameters
In the 13.0.0 type definitions, temperature, topP, topK, candidateCount, presencePenalty, and frequencyPenalty received a deprecation note: "Not supported in Gemini 3.x and later models. The model will ignore this parameter if it's included in a request." The code still compiles, but it means that with Gemini 3 and later models, the value is ignored even if you specify it. Apps that rely on temperature to reduce variation in responses need to consider other approaches, such as prompt design or output validation.
Migration order
The following is the editorial team's proposal.
- While staying on 12.19.0, replace
VertexAIBackendwithAgentPlatformBackendand specify the region explicitly as an argument. Decide at this point whether to rely on the defaultglobal - Upgrade to 13.0.0 and fix the
Parttype errors. Addtype: 'text'where history is passed, and for responses, narrow withtypebefore readingtext - Review settings such as
temperature. Since they are ignored by Gemini 3 and later models, decide whether to keep them
For a comparison of which model to use, see Three new Gemini models: selection criteria for SMBs; for choosing an architecture that builds AI into your operations, see Building AI agents into your operations: build in-house or outsource; and for the approach of managing multiple AI APIs together, see Should you put a gateway in front of your internal AI.
Scope of verification
On October 11, 2026, we checked packages/firebase/CHANGELOG.md and packages/ai/CHANGELOG.md in firebase/firebase-js-sdk (13.0.0 / @firebase/ai 3.0.0), the type definitions (ai-public.d.ts) of @firebase/ai 3.0.0 as published on npm, and the publication timestamps on registry.npmjs.org (document research). We also installed firebase 12.19.0 and 13.0.0 on Node.js 22.22.0 on Linux and compared the exported names, the destination URLs and bodies recorded by stubbing
fetch, and type checks with TypeScript 5 (hands-on testing). On October 16, 2026, we also checked the Firebase AI Logic region guidance and model list (firebase.google.com). We did not connect to any Google services and have not confirmed actual 404 errors, processing locations, or the impact on pricing.
For dependency upgrades in AI-powered apps or sorting out processing location requirements, contact us through Development, AI, and automation consultations.









