Modellvalet är ditt, knappen är användarens och krediterna är din arbetsytas. Beställ modellen med dess id, openai/gpt-image-2.5-flare för snabba förhandsvisningar eller openai/gpt-image-2.5-sunburst för slutbilder, och be Lovable bekräfta var valet står i koden. Kör sedan ett tvåbildsprov med transparent bakgrund i ett testprojekt, läs av kostnaden per anrop under Cloud → AI och bestäm en gräns per användare innan du släpper knappen till appens användare. Dokumentationen anger inget pris per bild; priset följer leverantörens modellpris.
Vad Lovable ändrade
Enligt Lovables changelog för 15 september 2026 kan appens AI-funktioner nu generera och redigera bilder med två nya OpenAI-modeller. GPT Image 2.5 Flare, med id openai/gpt-image-2.5-flare, beskrivs som den snabbare modellen, avsedd för förhandsvisningar och bildredigerare inne i appen. GPT Image 2.5 Sunburst, med id openai/gpt-image-2.5-sunburst, beskrivs som den med högsta kvalitet, avsedd för slutbilder och detaljerade bilder. Båda kan enligt posten ge bilder med transparent bakgrund, som PNG- eller WebP-fil. Du ber Lovable använda någon av modellerna när den bygger en bildfunktion för appen, och generering och redigering av bilder drar krediter som annan AI-användning. Samma post innehåller även kopplingar till WhatsApp Business och Power BI; WhatsApp-kopplingen har sin egen nyhet och Power BI behandlas inte här.
Hur mycket snabbare Flare är, eller hur mycket bättre Sunburst är, säger Lovable ingenting om. Orden är Lovables egna, och de säger var modellerna är tänkta att sitta: Flare där användaren väntar på skärmen, Sunburst där bilden ska användas efteråt. Vad det betyder för just din app och dina motiv får provet nedan svara på.
I dokumentationen om AI-funktioner i appen, kontrollerad 18 september 2026, står de två modellerna i tabellen över bildmodeller tillsammans med GPT Image 2, som är markerad som standard, ett antal Gemini-modeller och två modeller markerade som avvecklade. Under tabellen upprepas att Flare och Sunburst kan ge transparent bakgrund som PNG eller WebP; för de andra modellerna nämns det inte. Om du inte namnger någon modell när du beställer får du alltså standardvalet, och det är inte någon av de två nya.
Vem genererar, och vem betalar
Det här är den del av nyheten som avgör om den är bra eller dyr för dig. Bildknappen i din publicerade app används av appens användare, inte av dig. Men anropet görs enligt dokumentationen av din app genom Lovables AI-koppling, och det dras från din arbetsytas krediter. Dokumentationen skriver att användningen mäts när AI-funktioner i den publicerade appen gör modellanrop, att de anropen är skilda från Lovable-agenten som hjälper dig bygga, och att kreditåtgången beror på vilken modell som används och hur mycket arbete som utförs, med genererade bilder som ett av exemplen. Du behöver enligt dokumentationen inte skapa något konto hos leverantören, sätta upp fakturering där eller klistra in nycklar i appen; kostnaden landar i din arbetsyta, inte hos användarna.
Krediterna tas i en bestämd ordning. På planerna Free, Pro och Business får arbetsytan enligt dokumentationen en månatlig AI-tilldelning på 4 krediter för AI-användning i publicerade appar; anropen drar först från den, sedan från arbetsytans vanliga krediter. På Free återställs tilldelningen den första i varje kalendermånad, på Pro och Business med faktureringsperioden, och det som inte används rullar inte över. Vad 4 krediter räcker till i bilder står inte i dokumentationen, och det är inte samma sak som de Build-krediter Lovable drar när den själv skapar bilder åt dig under bygget; nyheten om Build och Media generation går igenom den uppdelningen. En bild som Lovable gjorde i editorn och en bild som din app gjorde åt en användare hamnar i olika kolumner.
Priset finns inte som en siffra. Dokumentationen skriver att taxan bygger på leverantörens modellkostnad och att åtgången beror på modell och utfört arbete. Något kreditpris per bild anges inte, och det anges inte heller om bilder mäts per bild eller på annat sätt. Den siffra som gäller för din app är den du läser av under Cloud → AI efter att bilden har genererats, och den kan ändras när OpenAI ändrar sitt pris. Skriv därför inte in ett bildpris i din kalkyl förrän du har läst av ditt eget prov; artikeln om vad en publicerad app kostar visar var posten hör hemma i helheten.
Enligt dokumentationen svarar Lovables AI-koppling med felkoden 402 när arbetsytans krediter är slut, och åtkomsten återställs genom att du lägger till krediter eller slår på automatisk påfyllning under Settings → Plans & credit usage. Det betyder två saker. En bildknapp som du släppt till appens användare slutar fungera för alla på en gång, mitt i deras arbete, om du inte har sett förbrukningen komma. Och automatisk påfyllning löser det genom att låta appens användare bestämma hur mycket du köper. Inget av alternativen är fel, men båda ska vara valda av dig, inte upptäckta.
Vilken modell ska du beställa
Lovables egen rollfördelning är enkel att följa. Ska bilden visas medan användaren väntar, till exempel en förhandsvisning som uppdateras när användaren ändrar något, eller en bildredigerare där varje ändring ska synas snabbt, är Flare den modell Lovable pekar på. Ska bilden användas efteråt, som en produktbild, en illustration som laddas ned eller en bild som ska tåla förstoring, pekar Lovable på Sunburst. Många appar behöver båda: Flare i redigeraren och Sunburst på knappen Spara slutbild. Det går att beställa, men då ska det stå i beställningen vilken knapp som kör vilken modell.
Skriv modellens id, inte bara namnet. Dokumentationen säger att du kan namnge en stödd modell eller beskriva vad du vill och låta Lovable välja, men beskriver du bara "en snabb bildmodell" är det Lovables tolkning som hamnar i koden, och den kan du inte läsa av efteråt utan att fråga. Samma princip gäller som i nyheten om Chat Latest och det numrerade modellvalet: ett namn som står i koden går att kontrollera, ett alias byts utan att du märker det. Be dessutom Lovable bekräfta var valet står. Dokumentationen säger att avvecklade modeller fortsätter fungera i befintliga appar men inte används för nya funktioner, så den dag Flare eller Sunburst ersätts vill du veta exakt vilken rad som ska ändras.
Bygg en bildfunktion i min app på sidan [sidans namn]. Användaren skriver en kort beskrivning i ett textfält och trycker på knappen "Skapa bild". Appen ska generera bilden med modellen openai/gpt-image-2.5-flare och visa den på sidan. Bilden ska ha transparent bakgrund och sparas som PNG. Lägg också till en knapp "Spara slutbild" som genererar samma beskrivning en gång till med modellen openai/gpt-image-2.5-sunburst, också med transparent bakgrund som PNG, och låter användaren ladda ned den. Funktionen ska bara vara tillgänglig för inloggade användare. Ändra inga andra delar av appen. Bekräfta efteråt exakt var i koden de två modellvalen står, och vilken modell som används om något av valen skulle saknas.
Den sista meningen är inte artighet. Svaret talar om för dig om valet står uttryckligen i koden eller om funktionen faller tillbaka på standardmodellen, och det är samma svar du behöver den dag en av modellerna avvecklas.
Tvåbildsprovet: samma motiv, båda modellerna, transparent bakgrund
Provet gör tre saker på en gång: det visar om transparensen verkligen fungerar i din app, det ger dig en jämförelse mellan modellerna på ett motiv du bryr dig om, och det ger dig den första verkliga kostnadssiffran. Kör det i ett testprojekt eller i ett utkast, inte i den publicerade appen, och gör det innan någon annan än du har tillgång till knappen.
Om vyn visar en annan modell än den du beställde har Lovable valt åt dig trots beställningen. Be då Lovable visa raden i koden där modellen anges och ändra den, och kör steg 3 till 5 igen. Om ett anrop visas som misslyckat, kontrollera först att arbetsytan har krediter kvar; dokumentationen anger 402 som svar när de är slut och 429 när frekvensgränsen per arbetsyta, räknad i anrop per minut, överskrids.
Ändra ingenting i appen. Visa mig var i koden modellen för knappen "Skapa bild" anges och var modellen för knappen "Spara slutbild" anges. Ange det exakta modell-id som används i varje fall. Berätta också om bilderna sparas som PNG med transparent bakgrund, och var i koden det anges.
Sätt en gräns innan appens användare får knappen
Provet ger dig en kostnad per bild och en uppskattning per dag. Det som saknas i Lovables dokumentation är en inställning som stoppar appens användare när en viss summa är nådd; det som finns är frekvensgränsen per arbetsyta, felkoden 402 när krediterna är slut och automatisk påfyllning. Ingen av dem är en budget. Gränsen får du bygga in i appen själv, som en funktion, och det kan du beställa utan att kunna kod. Artikeln om att skydda en AI-app mot överbelastning förklarar varför en öppen AI-knapp utan tak är ett problem oavsett modell; det här är samma sak, räknat i bilder.
Tre beslut räcker för en första version. Kräv inloggning, så att varje bild kan knytas till en användare; det står redan i beställningen ovan. Sätt ett tak per användare och dag, till exempel tio bilder, och låt knappen tala om hur många som är kvar. Och bestäm vad användaren ska se när taket är nått, eller när arbetsytan är tom: ett vänligt meddelande med när knappen öppnar igen är bättre än en knapp som inte gör något. Siffran tio är inte Lovables rekommendation utan en startpunkt; sätt den utifrån steg 6 i provet och höj den när du har sett en månads förbrukning.
Lägg till en gräns för bildfunktionen på sidan [sidans namn]. Varje inloggad användare får skapa högst 10 bilder per kalenderdygn, räknat med knapparna "Skapa bild" och "Spara slutbild" tillsammans. Visa under knapparna hur många bilder användaren har kvar i dag. När gränsen är nådd ska knapparna vara avstängda och texten "Du har använt dagens bilder. Du kan skapa nya efter midnatt." visas. Om bildgenereringen misslyckas för att tjänsten svarar med fel ska användaren se texten "Bildfunktionen är tillfälligt stängd. Försök igen senare." och inget annat. Ändra inga andra delar av appen. Förklara efteråt var gränsen räknas och var jag ändrar antalet.
Med gränsen på plats vet du det värsta som kan hända en enskild dag: antalet användare gånger tio gånger kostnaden per bild ur provet. Först då är det rimligt att ta ställning till automatisk påfyllning, och först då ska knappen släppas till andra än dig.
Du har en beställning där modell-id:t står ordagrant för varje knapp, och Lovables bekräftelse på var valen står i koden. Du har två PNG-filer av samma motiv, en från Flare och en från Sunburst, som du har lagt på en färgad bakgrund och sett vara transparenta. Du har läst av kostnaden per anrop under Cloud → AI, med datum, och räknat upp den till en dag och en månad för dina användare. Du har en gräns per användare och dag inbyggd i appen, med ett meddelande när den är nådd, och du har bestämt om automatisk påfyllning ska vara på eller av innan någon annan än du får trycka på knappen.
Officiella källor · kontrollerade 18 sep 2026
- Lovable Changelog, 15 sep 2026: GPT Image 2.5 Flare och Sunburst i appens AI-funktioner, transparent bakgrund, krediter ↗
- Lovable Docs: AI features – tabellen över bildmodeller med GPT Image 2 som standard, AI gateway-användning och krediter, månatlig AI-tilldelning, frekvensgränser och felkoder, Cloud → AI ↗