Gemini Live API: så bygger du en AI som ser och hör i realtid

Gemini Live API är Googles gränssnitt för dubbelriktad realtidsdialog: du streamar mikrofon och kamera till modellen, den svarar med röst medan du fortfarande pratar. Vi använder det i produktion för aifixlys 14 AI-experter. Den här guiden är allt vi hade velat veta innan vi började.

Vad är Gemini Live API — och hur skiljer det sig från vanliga Gemini?

Vanliga Gemini-anrop är request/response: du skickar en fråga över HTTP, väntar, får ett svar. Live API är istället en öppen WebSocket-session. Ljud, video och text går in kontinuerligt, och modellens svar kommer tillbaka som en ström av ljudchunks och texttranskript samtidigt som du fortfarande pratar.

Den praktiska skillnaden är avbrytbarhet. I en Live-session kan du säga "nej, vänta" mitt i AI:ns mening och den slutar prata direkt. Det går inte att simulera med tur-och-ordning-anrop, oavsett hur snabb modellen är.

• Vanlig Gemini: HTTP, ett svar per anrop, bra för text och analys av enstaka bilder.
• Gemini Live API: WebSocket, kontinuerlig ström, ljud in och ljud ut, video som bildruteström.
• Ljudformat: 16 kHz PCM in till modellen, 24 kHz PCM ut från modellen — resampling måste du sköta själv i klienten.
• Video skickas som enskilda bildrutor (ofta 0,5–2 fps räcker), inte som en videoström.

Kostar Google AI Studio något?

Google AI Studio är gratis att använda som utvecklingsmiljö — du loggar in med ett Google-konto, testar modeller i webbläsaren och genererar en API-nyckel utan att lägga in kort. Det finns dessutom en gratisnivå på API:et med dagliga kvoter, vilket räcker gott för prototyper.

Kostnaden dyker upp när du går i produktion. Då betalar du per token, och för Live API räknas ljud i tokens precis som text — både det du skickar in och det modellen talar tillbaka. Realtids-ljud är dyrare per minut än ren text, eftersom sessionen konsumerar tokens hela tiden den är öppen.

Hur kopplar man upp ljud och video i realtid?

Kort svar: webbläsaren öppnar en WebSocket direkt mot Google, men den får aldrig se din riktiga API-nyckel. Istället begär din server en kortlivad token som skickas till klienten.

• 1. Klienten anropar din egen server-endpoint, till exempel /api/gemini-token.
• 2. Servern använder den hemliga GEMINI_API_KEY för att skapa en ephemeral token — hos oss giltig i 30 minuter och för en enda användning.
• 3. Klienten öppnar WebSocket-sessionen mot Live API med den tokenen.
• 4. Setup-meddelandet skickas först: modellnamn, systeminstruktion, önskat svarsläge (ljud) och röst.
• 5. Därefter strömmas mikrofonens PCM-chunks och kamerans bildrutor löpande in i sessionen.
• 6. Svaren kommer tillbaka som ljudchunks som köas och spelas upp, plus transkript för texten på skärmen.

Lägg rate limiting och origin-kontroll på token-endpointen från dag ett. Utan det kan vem som helst hämta tokens från din domän och köra upp din faktura. Vi begränsar till 5 anrop per minut och 30 per timme per IP.

Vad kostar det att köra i produktion?

Räkna per minut, inte per anrop. En live-session konsumerar tokens kontinuerligt så länge den är öppen — även när ingen säger något, eftersom ljudströmmen fortfarande går in. Ett tio minuters samtal med Gemini Live landar typiskt kring 0,20–0,50 dollar beroende på hur mycket AI:n själv pratar.

• Största kostnadsdrivaren är AI:ns eget tal — utgående ljudtokens är dyrast.
• Näst största är öppna sessioner ingen använder. Sätt en inaktivitetstimeout.
• Video är billigare än man tror om du skickar få bildrutor per sekund.
• Korta, tydliga systeminstruktioner sparar tokens i varje session, inte bara en gång.

Vilka fallgropar gick vi på?

Alla fyra buggarna nedan såg först ut som API-problem. Ingen av dem var det.

Race condition vid uppkoppling

Vi startade ljudströmmen inne i onopen-callbacken och skickade första bildrutan innan sessionsobjektet hade satts. Resultatet: referensen var fortfarande null och de första sekunderna försvann. Lösningen var att initiera strömmen efter att sessionen tilldelats, inte inuti öppningshändelsen.

"WebSocket is already in CLOSING or CLOSED state"

Klienten fortsatte skicka ljud- och bildrutor efter att Google stängt sessionen. Felet fyller konsolen men den verkliga skadan är att gränssnittet fortfarande visar "live". Vi la in en explicit flagga som stängs av vid close och error, och som varje sändning kontrollerar först.

Falskt live-läge

Att WebSocket öppnas betyder inte att modellen svarar. Vi visade "live" så fort socketen var uppe, och användaren satt i tystnad. Nu visar vi anslutet först när första svaret faktiskt kommit tillbaka, med en timeout på 12 sekunder som ger ett begripligt felmeddelande istället för evig tystnad.

Fel ljudformat

Webbläsarens AudioContext kör ofta 48 kHz. Live API vill ha 16 kHz in och skickar 24 kHz ut. Skippar du resamplingen får du antingen brus eller en AI som låter som en chipmunk. Det här är inte en bugg i API:et — det är en rad i dokumentationen som är lätt att missa.

Vad passar tekniken till — och inte?

Live API lyser när kontexten är visuell och frågan är omedelbar: du står med en läckande kran, en trasig cykelkedja, en okänd växt eller en jobbintervju om tio minuter. Det är precis de situationerna vi byggde aifixlys experter för.

• Passar bra: handledning i realtid, språkträning, felsökning där man behöver visa något.
• Passar bra: coachning där avbrott och följdfrågor är själva poängen.
• Passar sämre: uppgifter som kräver exakt faktakontroll — då är text med källor bättre.
• Passar sämre: allt som kräver behörighet i verkliga livet, som elinstallationer eller gasarbeten. Där ska AI:n hänvisa till fackman, inte gissa.

Vill du se det i praktiken: välj en expert, tillåt kamera och mikrofon och börja prata. Ingen inloggning krävs för att testa.