Skip to main content
A session is a container for persistent conversation state. Where a plain ai.generate() call is stateless, a session automatically accumulates conversation history across multiple send() calls—you never need to manually pass messages back and forth. Sessions also support multiple independent threads within a single session context, so you can run parallel conversations (e.g., a main conversation thread and a side-channel for tool confirmations) under one session ID.

Creating a session and chatting

Sessions vs. plain generate()

System prompts in sessions

Set a system prompt (persona, instructions, constraints) when creating the chat. It is injected automatically at the start of every request:

Multi-thread sessions

A session can hold multiple independent conversation threads. Each thread has its own message history:

Prompts as preambles

You can initialize a chat thread with a Dotprompt, which acts as a reusable preamble:

Streaming chat

Use chat.sendStream() to stream the response token-by-token:

Persisting sessions

By default, session state is kept in memory and lost when the process restarts. For production multi-user applications, plug in a persistent store:
You can also write your own store by implementing the SessionStore interface:

Session state

Sessions can carry arbitrary typed state alongside conversation history. This is useful for tracking things like a user’s preferences, shopping cart, or workflow step:

Reading message history

The full conversation history is available on the chat.messages property. Each entry is a MessageData object with role and content:
Message history includes both user messages and model responses. Tool call messages are also recorded in the history when tools are used.

Next steps

Tools

Tools work seamlessly inside chat sessions.

Streaming

Stream responses in real time with sendStream().

Firebase Deployment

Deploy session-aware flows to Firebase.

Agents

Build persistent agents that maintain state across turns.