google-gemini/live-api-web-console: a React starter for Gemini's Live API

What the Live API web console actually is

The repository describes itself as a react-based starter app for using the Live API over a websocket. That phrasing matters. This is not a chat UI with a text box and a send button. It is a console for a streaming session: audio playback, recording of user media from a microphone, webcam or screen capture, and a unified log view that the README frames as an aid for development. The audience is a developer who already has a Gemini API key and wants to see the protocol in motion before committing to an architecture. The homepage points at https://ai.google.dev/api/live for the API itself, so the repository is the client side of that story, not the documentation. If you want to understand what a bidirectional audio session with tool calls looks like in React state, this is the shortest path. If you want an end-user product, you are looking at a starting point that still needs product decisions made for it.

How the websocket client, audio layer and log view fit together

The README's development section lists three parts: an event-emitting websocket client that eases communication between the websocket and the front end, a communication layer for processing audio in and out, and a boilerplate view for building apps and viewing logs. The event emitter is the interesting choice. Rather than pushing websocket messages into component state directly, the client emits named events such as toolcall, and components subscribe with client.on and unsubscribe with client.off in a useEffect cleanup. That keeps the transport decoupled from rendering and means several components can react to the same message. Configuration flows the other way: components call setConfig from a context hook to declare the model, a system instruction and tools. The example in the README sets a system instruction that tells the model to call a render_altair function whenever a graph is requested, and registers both googleSearch and functionDeclarations as tools. Tool results are not returned to the model in that snippet. The component receives the call, parses a JSON string out of the arguments and renders it with vega-embed. That is a one-way demo of function calling, and anyone extending it will need to send a response back.

Install the console and run the Altair grounding example

The README gives two steps: create a free Gemini API key at aistudio.google.com/apikey, add it to the .env file, then install and start. The repository ships a .env entry at the top level, and dotenv-flow is a dependency, so the key is read from that file rather than from a shell export.

npm install && npm start

Create React App starts the dev server and the README says to open http://localhost:3000 in the browser. The page reloads on edits and lint errors appear in the console. A second script exists for secure contexts:

npm run start-https

That script sets HTTPS=true before invoking react-scripts start, which matters because browser media capture APIs generally require a secure origin. If microphone or webcam access fails silently on localhost, that script is the first thing to try. For a production bundle the README documents npm run build, which writes to the build folder with hashed filenames. The Altair component in the README shows the shape of a first real use: declare the function, register it through setConfig, listen for the toolcall event, and render the returned JSON. Note that the example imports SchemaType and FunctionDeclaration from @google/generative-ai, while package.json lists @google/genai. The README also points to separate branches for newer GenAI SDK demos, so check which SDK a given branch targets before copying imports.

Where the console stops being the right tool

The README closes with an explicit disclaimer: this is an experiment showcasing the Live API, not an official Google product, with best effort support and mileage that may vary. Treat that as a design constraint rather than boilerplate. There are no releases in the repository, so there is no versioned artifact to pin and no changelog to read before upgrading. The toolchain is Create React App, which is no longer the default recommendation for new React projects, and react-scripts is pinned at 5.0.1. The example hardcodes models/gemini-2.0-flash-exp, an experimental model string that the README does not promise will remain callable. It also does not document rollback, error recovery for a dropped websocket, or how to resume a session after a network interruption. If your requirement is a stable, versioned client library with a support contract, this repository is the wrong shape. It is a readable reference implementation, and reading it is the point.

How it differs from calling the Live API directly

The alternative most teams consider is skipping the console and talking to the Live API from their own client. The difference is not the protocol, which is the same websocket either way. It is what you inherit. Writing your own client means you implement audio capture, resampling, playback queueing, event dispatch and the log view yourself, and you get to choose the framework, the state library and the build tool. Starting from this repository means those pieces already exist in TypeScript you can read, at the cost of accepting Create React App, React 18, zustand for state and eventemitter3 for dispatch. A team already on Next.js or Vite will spend time removing the CRA scaffolding. A team that just wants to see a tool call arrive and a graph render will spend less time here than writing a recorder from scratch. The honest comparison is reference versus production: this repository is optimised for the first, and the README's own framing says so.

Maintenance, licence and what an upgrade costs

The repository is not archived. The last push was on 2026-06-21, which is roughly three months before the date of this article, so the code has moved recently, but the absence of any retrieved releases means there is no tagged version to track. Upgrades therefore happen by pulling the main branch or by diffing the demo branches the README lists: demos/proactive-audio for the proactive audio feature, plus the original demos/GenExplainer, demos/GenWeather and demos/GenList. Those branches are described as example applications rather than as maintained packages. Dependency drift is the real cost. React 18, react-scripts 5.0.1 and TypeScript 5.6.3 with an override pinning the same version will need attention as the ecosystem moves, and because there is no release channel you will not get a notification when they do. The licence is Apache-2.0, which permits commercial use and modification, and the README adds a request to respect copyright and trademark rights when sharing derivative work. That is a description of the terms, not legal advice; read the LICENSE file and Google's site policies before shipping a derivative.

Editorial conclusion

Adopt it if you need a working reference client for the Gemini Live API and want to read how audio in, audio out and tool calls are wired before writing your own. Do not adopt it as a production front end: the README calls it an experiment rather than an official Google product and says support is best effort. Before you build on it, confirm which model string your account can call, since the example sets models/gemini-2.0-flash-exp, and check whether your deployment target needs the start-https script rather than start.

Frequently asked questions

Official sources

1. google-gemini/live-api-web-console on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README