Gemini Live in the Browser: A Voice AI Prototype in Three Hours
A browser demo with native audio and function calling. What the prototype shows—and what remains unresolved for costs, privacy, and real-world use in a medical practice.
Last week I had one of those typical screening calls again: friendly, structured, but somehow interchangeable. More like a digital form than an actual conversation. Afterward, I wanted to know how far I could take a voice assistant in one afternoon.
The result was Uschi: a browser demo for checking appointments at a fictional general practice, built with synthetic test data.
My prototype took about three hours to build. That is my personal build time for a limited demo, not a promise for other projects. It shows a conversation in the browser, interruptions, language switching, and an appointment lookup from a small text file. Telephony, practice management software, robust error handling, and a production privacy framework are missing.
The prototype: Uschi, AI receptionist
Her name is Uschi. Receptionist at a general practice in Cologne-Ehrenfeld. Mid-fifties, been doing the job for 25 years. Asks how you're doing before she gets to the appointment. Cuts you off when she has something to say. Switches to Turkish if you don't speak German. And looks for an open slot while she's at it.
Uschi is an AI. Her personality is a system prompt running a few paragraphs long; appointment lookup runs through a function. Everything else comes from the model.
The whole thing runs in the browser. Mic on, talk. No “Please press 1.” No “Your call is important to us.” The video shows the actual demo:
Demo and transcript on LinkedIn
Tested in the prototype
- voice input and audio output in the browser
- interruption of a response while it is playing
- switching between several languages in manual conversations
- synchronous appointment lookup from a local text file
Not shown
- a real phone number, SIP/PSTN, or call forwarding
- a connection to Doctolib, a practice management system, or a production calendar
- authentication, authorization, and robust failure logic
- measurements of latency, dialect accuracy, or conversation success
- processing of real patient or appointment data
The demo therefore remains a work sample for prototyping and integration thinking. It is not a finished phone assistant.
Technical status as of August 15, 2026
The demo uses Google’s Live API architecture. The current model name is gemini-3.1-flash-live-preview; Google released it on March 26, 2026, and continues to list it as a preview.12 Preview models and endpoints can change, so every further development step should begin with a release check.
Google documents bidirectional audio, video, and text input as well as native audio output for the model. The capability list names 97 languages and language switching during a conversation.1 This establishes that the function is supported, not that quality is consistent across every accent or dialect. My manual conversations were a functional test, not a language benchmark.
The data flow in my prototype is simple:
Browser → Python server → Gemini Live APIThe browser streams audio to the server. The server holds the API key and forwards audio chunks over WebSockets. An API key does not belong in browser code; for a direct client connection, Google recommends short-lived ephemeral tokens.1
With native audio, this architecture does not require a separate speech-to-text and text-to-speech cascade. Optional input and output transcriptions can still be enabled. Whether this makes the voice sound “more natural” was an observation in my test, not a measurement.
Function calling and wait time
For appointment lookup, the server defines a function with parameters such as date and time of day. When the model detects a matching intent, it calls that function and waits for the result.
With gemini-3.1-flash-live-preview, function calling is synchronous and sequential; according to the current comparison documentation, NON_BLOCKING is not supported.1 The pause was short in the small text-file test. A production system would still need timeouts, authorization checks, cancellation, retries, and a clear error message. That work does not fit into the three-hour prototype.
What does this cost?
All the figures below run the same scenario: a conversation with 90 seconds of input and 90 seconds of output, so three minutes of active audio split between speaking and listening. All prices are as of August 15, 2026.
Google lists $0.005 per minute of audio input and $0.018 per minute of audio output for Gemini 3.1 Flash Live.3 OpenAI prices its realtime models by audio token, which converts to the same scenario.7
| Model | Audio in / out per 1M tokens | One conversation |
|---|---|---|
| Gemini 3.1 Flash Live | $3 / $12 | about 3.5 cents |
| OpenAI gpt-realtime-2.1-mini | $10 / $20 | about 4.5 cents |
| OpenAI gpt-realtime-1.5 | $32 / $64 | about 14.4 cents |
Scaled up to a practice with 50 calls a day over 22 working days — 1,100 calls a month — that's roughly $38 on Gemini, $50 on OpenAI's small model, $158 on the large one.
These are floor prices, not per-call quotes. Native audio tokens in the active context get billed again on every speaker turn, and enabled transcriptions cost extra. Telephony, hosting, monitoring, outages and compliance are all missing entirely. A reliable calculation needs real session logs.
The order of magnitude still supports one point: for comparison, a receptionist who spends a substantial share of her working time on the phone costs a multiple of that per month once you add employer contributions. The API cost is not the bottleneck. What makes a production system expensive is development, telephony integration, operations and compliance.
Privacy and usage limits
The demo uses a fictional practice and synthetic data. It cannot be treated as approval for use in a real clinical setting.
According to its terms, Google does not use prompts and responses from paid Gemini API services to improve its products. This does not mean that data is never stored or processed outside the EU. Abuse logs, caching, the specific region, and contractual terms must be reviewed separately.45
Session Resumption is disabled by default. If the feature is enabled, Google may store the session state—including audio, video, text, and model output—for up to 24 hours so the session can be resumed.5 A goal such as Zero Data Retention therefore depends on the specific configuration and must not be shortened to “audio is never stored.”
Germany is listed as an available country for Google AI Studio and the Gemini API. This is not a promise of EU-only processing.6 Regional Vertex or enterprise endpoints are a separate product and contractual setup; the model and feature set must be reviewed again there.
Most importantly for this demonstrator, Google’s Additional Terms prohibit use in clinical practice and for medical advice.4 It would therefore go too far to say that “pure appointment scheduling is unproblematic.” A production solution for a German medical practice requires its own technical, contractual, data protection, and medical-law review.
Handoff to humans
In a production system, the most important function wouldn't be talking — it would be recognizing when a human needs to take over.
A voice bot in a medical practice would need to notice when it's out of its depth. Words like chest pain, shortness of breath, or emergency should route straight to a person. And after three failed attempts, the AI should say, honestly: “I'll go ahead and connect you with someone from the team.”
None of that is implemented in the prototype. Production would need state logic, call forwarding, an availability check, logging, and a fallback for when nobody happens to be reachable. That's a separate part of the product, not one more sentence in the prompt.
What remains
Three hours, one prototype that holds a conversation, switches languages, and looks up appointments from a text file. The demo shows the leap from model to interaction.
It does not show that a medical phone assistant could be finished, privacy-compliant, or reliable in three hours. Between this demo and a system that actually takes calls in a real practice lie telephony infrastructure, practice-software integration, a privacy architecture, and a lot of testing.
That boundary is exactly what makes the experiment useful. A quick prototype answers whether an interaction can be built and experienced at all. And the effort it takes to find that out has become surprisingly small.
Tech stack and sources
- Backend: Python, FastAPI, WebSockets
- Frontend: Vanilla HTML/JS, AudioWorklet API
- Model:
gemini-3.1-flash-live-preview - Data: synthetic appointment text file