Lovable-appen kan söka på webben och läsa PDF:er — bestäm vad den får hämta och vem som betalar

Vad Lovable lade till

Enligt Lovables changelog för 22 september 2026 kan din app nu söka på den levande webben, läsa en publik sida eller en PDF som ren text, få svar med källhänvisning på researchfrågor och köra djupare researchuppdrag som fyller strukturerad data med källor. Lovable nämner själv fyra användningsområden: att fylla på information om leads, att göra bakgrundskontroller, att göra marknadsundersökningar och att bygga chattbotar som svarar utifrån aktuella källor.

På kopplingens egen dokumentationssida, kontrollerad 23 september 2026, står förmågorna i fyra punkter, och det är värt att läsa dem som fyra olika kostnadsposter snarare än som en funktion. Den första är sökning på webben med resultat anpassade för AI, från mycket snabba uppslag till research i flera steg. Den andra är att läsa en känd adress eller en PDF som ren markdown, även när sidan byggs med JavaScript. Den tredje är researchfrågor som besvaras direkt med källhänvisning, i en dialog användaren kan fortsätta. Den fjärde är researchuppdrag som körs i bakgrunden och fyller ett formulär för en eller flera poster, med källhänvisningar och ett säkerhetsvärde på varje fält. Den fjärde punkten är den som gör mest arbete per anrop, och den du bör läsa av först.

Det här är inte samma sak som att appen söker i sitt eget innehåll. Sökning i det du själv lagt in i appen har sin egen modell och sin egen kostnad, och den frågan ligger i nyheten om Lovables sökmodell och de gamla indexen. Parallel går utåt, till sidor du inte styr över, och det är skillnaden som gör avgränsningen nedan nödvändig.

Tre saker den hanterade kopplingen inte gör

Dokumentationen listar tre begränsningar, och de är korta nog att återges i sin helhet. Bevaka webben över tid går inte på en uppkoppling som Lovable sköter; den funktionen kräver att du kopplar in en egen nyckel från Parallel. Att hitta poster utifrån en beskrivning — "alla företag som gör X" — ingår inte. Och det finns ingen inloggning per slutanvändare: varje uppkoppling är ett enda Parallel-konto som delas av alla projekt som använder den.

Den tredje punkten är den som oftast kommer som en överraskning. Det betyder att du inte kan låta varje kund i appen betala för sina egna sökningar, och att du inte kan skilja en kunds förfrågningar från en annans via Parallel. Behöver du det, eller behöver du bevakning över tid, är egen nyckel vägen — och då fakturerar Parallel ditt eget Parallel-konto direkt, utan att Lovable-krediter är inblandade. Den hanterade varianten finns i ett exemplar per arbetsyta; med egen nyckel går det att ha flera.

Vem söker, och vem betalar

Changelogposten är tydlig på den punkt som avgör om det här blir billigt eller dyrt för dig: i den hanterade varianten debiterar Lovable varje förfrågan till den arbetsyta som äger projektet, under Run-krediter. Det är alltså inte appens användare som betalar för sina sökningar, utan du — och det sker i samma stund som någon trycker på knappen, utan att du ser det hända.

Taxan står på kopplingens dokumentationssida: 4 Lovable-krediter per US-dollar av den Parallel-användning som rapporteras, eller 2 Lovable-krediter per US-dollar på Business-planer. Det som inte står någonstans är vad en enskild sökning, sidläsning eller researchuppgift kostar i dollar. Priset räknas alltså om från Parallels rapporterade kostnad, och den kostnaden varierar med vad du ber om. Skriv därför inte in någon siffra per förfrågan i din kalkyl förrän du har läst av ditt eget prov; artikeln om vad en publicerad app kostar visar var den här posten hör hemma bland de andra.

Var siffran dyker upp är däremot bestämt. Enligt Lovables sida om planer och krediter redovisas bygg- och chattarbete under Build-krediter, medan Cloud, AI gateway och kopplingar redovisas under Run-krediter. Det är redovisningsvyer, inte skilda saldon: allt dras ur samma pott. Webbförfrågningarna hamnar alltså i Run-vyn, tillsammans med det appen kostar att drifta, och inte bland det du förbrukar när du bygger. Samma uppdelning ligger bakom nyheten om Build och Media generation, fast från andra hållet.

Avgränsa vad appen får hämta

Innan kopplingen slås på behöver du en mening om vad appen får söka efter. Utan den blir avgränsningen det som råkar hamna i prompten, och den ändras varje gång någon ber om en förbättring. Skriv i stället ned tre saker: vilka frågor som får skickas ut, vilka som ska stanna i appen, och vad användaren ser när en fråga faller utanför. Det tredje är det som oftast glöms, och det som avgör om användaren provar igen tio gånger.

Gränsdragningen är också en fråga om vad som lämnar appen. En sökfråga som byggs av användarens egna uppgifter — ett kundnamn, en adress, ett ärendenummer — skickas ut ur appen när den skickas till en webbsökning. Det är samma sorts beslut som i nyheten om vad Replits projektanalys räknar, fast åt andra hållet: där handlade det om vad en påslagen funktion samlar in, här om vad appen skickar ut. Bestäm vilka fält som får ingå i en sökfråga innan någon annan än du använder funktionen.

Lägg till en webbsökning i min app på sidan [sidans namn], via
Parallel-kopplingen.

Appen får bara söka på webben när användaren trycker på knappen
"Sök aktuell information". Ingen automatisk sökning i bakgrunden,
och ingen sökning när sidan öppnas.

Sökfrågan får bara innehålla det användaren skriver i sökfältet plus
ordet [din bransch]. Uppgifter ur databasen, som namn, e-post,
adress och ärendenummer, får inte skickas med i sökfrågan.

Varje svar ska visa de källor som använts, som klickbara länkar
under svaret.

Faller frågan utanför det tillåtna ska appen visa texten
"Den här frågan söker jag inte på webben efter" och inget annat.

Ändra inga andra delar av appen. Bekräfta efteråt var i koden
avgränsningen står och vilka fält som skickas med i sökfrågan.

Sista meningen är kontrollen. Svaret talar om för dig om avgränsningen ligger som en regel i koden eller bara som en formulering i en prompt, och det är skillnaden mellan något du kan kontrollera och något du får hoppas på.

Källprovet: följ tre hänvisningar tillbaka

Att svaren levereras med källhänvisning är en egenskap hos kopplingen. Att hänvisningarna leder till en sida som faktiskt säger det svaret påstår är något annat, och det säger dokumentationen ingenting om. Provet nedan tar tio minuter och ska köras i ett testprojekt eller ett utkast, innan någon annan än du kan trycka på knappen.

Siffran ur steg 6 är den första riktiga uppgiften du har om vad funktionen kostar, och den gäller just dina frågor. En fråga som kräver research i flera steg drar mer än ett snabbt uppslag, så gör om provet med den svåraste fråga du tror att en användare kommer att ställa innan du fastställer taket i nästa avsnitt.

Sätt ett tak innan någon annan får söka

Det dokumentationen erbjuder mot en skenande förbrukning är automatisk påfyllning: krediter köps automatiskt när saldot når en tröskel du själv sätter, så ofta som behövs inom en månadsgräns du anger, på Pro- och Business-planer. Det är ett skydd mot att appen slutar fungera, inte mot att den blir dyr. Ett tak på hur mycket appens användare får förbruka finns inte som en inställning, och behöver därför byggas in i appen — vilket du kan beställa utan att kunna kod. Artikeln om att skydda en AI-app mot överbelastning går igenom varför en öppen funktion utan tak är ett problem i sig; här är det samma sak, räknat i webbförfrågningar.

För ditt eget byggande finns dessutom kreditincheckningen, som pausar ett meddelande när det passerat en gräns du satt. Den gäller chattens arbete, inte appens förfrågningar, men principen är densamma och beskrivs i nyheten om Lovables kreditincheckning. Taket nedan är appens motsvarighet.

Lägg till en gräns för webbsökningen på sidan [sidans namn].

Varje inloggad användare får göra högst 10 webbsökningar per
kalenderdygn. Visa under sökfältet hur många sökningar användaren
har kvar i dag.

När gränsen är nådd ska knappen vara avstängd och texten
"Du har använt dagens sökningar. Du kan söka igen efter midnatt."
visas.

Lägg till en sida som bara jag kommer åt, där jag ser antalet
webbsökningar per dag de senaste 30 dagarna och vilka sökord som
använts.

Misslyckas en sökning ska användaren se texten "Sökningen ä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 taket på plats vet du det värsta som kan hända en enskild dag: antalet användare gånger tio gånger kostnaden per förfrågan ur provet. Sidan med sökorden är dessutom det som visar dig om avgränsningen håller i verkligheten, eller om användarna ställer helt andra frågor än du trodde. Först när båda siffrorna finns är det rimligt att ta ställning till automatisk påfyllning.

Avgränsningen, källprovet med tre hänvisningar och taket per användare och dygn är Perestrojkas arbetssätt. Lovables egna steg är att lägga till kopplingen under Connectors och följa förbrukningen under Usage details; talen tio sökningar och tre hänvisningar är startvärden att justera efter din egen avläsning, inte Lovables rekommendationer.