Add Firebase AI Logic to the shared model client API

[davideast]

Firebase AI Logic can now join every ModelClient consumer

Applications that already use Firebase can now adapt a caller-constructed Firebase AI Logic GenerativeModel into the shared @inbrowser/model contract:

createFirebaseAiLogicModelClient(model, options?): ModelClient

The returned client streams the same text, thinking, tool_call, usage, and error events as the other providers. Existing agent and model-call code can consume Firebase AI Logic without learning a second provider-specific event vocabulary.

The optional id gives the client a stable metrics and provenance name. An optional construction-time temperature supplies a default, while a temperature on an individual ModelRequest takes precedence.

A configured Firebase model becomes a streaming client in one step

The host initializes Firebase, selects the Google AI or Vertex AI backend, configures App Check, and constructs the model. The new adapter starts at that model boundary:

import { initializeApp } from "firebase/app";
import { getAI, getGenerativeModel, GoogleAIBackend } from "firebase/ai";
import {
  createFirebaseAiLogicModelClient,
  type ModelRequest,
} from "@inbrowser/model";

const app = initializeApp(firebaseConfig);
const ai = getAI(app, { backend: new GoogleAIBackend() });
const firebaseModel = getGenerativeModel(ai, {
  model: "gemini-2.5-flash",
});

const client = createFirebaseAiLogicModelClient(firebaseModel);

const request: ModelRequest = {
  messages: [
    { role: "system", text: "Answer using current weather data." },
    { role: "user", text: "Do I need an umbrella in Brooklyn?" },
  ],
  tools: [
    {
      type: "function",
      function: {
        name: "get_weather",
        description: "Get the current weather for a location",
        parameters: {
          type: "object",
          properties: {
            location: { type: "string" },
          },
          required: ["location"],
        },
      },
    },
  ],
  toolUseEnabled: true,
  reasoningEffort: "medium",
};

for await (const event of client.chat(
  request,
  AbortSignal.timeout(30_000),
)) {
  if (event.kind === "text") {
    console.log(event.text);
  }

  if (event.kind === "tool_call") {
    console.log(`Run ${event.name}`, event.args);
  }
}

The package does not depend on Firebase itself. It accepts the narrow structural surface used from GenerativeModel, so applications keep control of their Firebase version, app lifecycle, authentication, backend, and location.

Gemini tool calls keep the existing conversation loop

ToolSpec declarations are translated into Firebase function declarations. Streamed calls are assembled into one tool_call event with their ids, arguments, and Gemini thought signatures intact.

After the application executes a tool, it appends the assistant call and a role: "tool" result to the message history, then calls client.chat() again. The adapter translates that full history back into Firebase model and function content, including the thought signature Gemini needs to continue tool-assisted reasoning.

Sampling and reasoning settings also stay in the shared request shape: temperature, top-p, top-k, and ReasoningEffort are mapped to the matching Gemini generation and thinking configuration.

The provider stays focused on the common Gemini path

This API covers streamed Gemini text, thinking, caller-executed custom functions, usage accounting, cancellation, and Firebase error normalization. Live API sessions, Imagen, server prompt templates, built-in or automatically executed tools, and multimodal lifecycle APIs remain outside this adapter because they require contracts beyond the current text-and-tool-oriented ModelClient.

The Firebase-specific reference documents the model seam, request mapping, event behavior, and deliberate boundaries alongside the other provider APIs.