Skriv ner stoppregeln innan du skickar meddelandet. Den behöver tre led: en tidpunkt, ett synligt tecken på framsteg och ett beslut. Till exempel: vid 45 minuter ska förhandsvisningen gå att öppna och minst en av de tre sakerna jag bett om ska synas där – annars stoppar jag och delar upp uppgiften. Sätt en påminnelse på tidpunkten, öppna More options på det pågående meddelandet när den ringer och läs av Working for och Credits used. Poängen med att skriva regeln i förväg är att du slipper fatta beslutet i just det ögonblick då du har väntat längst och är som mest benägen att låta det rulla en stund till.
Det här står i de två changelogposterna
Posten från den 26 augusti 2026 säger tre saker, och det är värt att hålla isär dem. Den första är själva ändringen: Lovable arbetar nu på varje byggmeddelande i upp till tio timmar innan det avslutas. Den andra är motivet: en stor uppgift hinner därmed oftare bli klar inom ett meddelande i stället för att kapas på mitten. Den tredje är en konsekvens som changeloggen skriver ut själv – byggmeddelanden debiteras efter det arbete Lovable utför, så ett meddelande som kör i timmar drar fler krediter än ett kort. Posten anger ingen kreditkostnad per timme och inget spann. Riktningen är belagd, storleken är det inte.
Posten från den 25 augusti 2026 är den som gör tiden hanterbar. Du kan numera se vad ett meddelande har kostat hittills utan att vänta på att det blir klart: i projektchatten öppnar du More options under meddelandet och ser tiden och krediterna, så att du kan följa ett långt meddelande medan det kör. Dokumentationen för chatten preciserar vad de två fälten heter. Working for är hur länge Lovable har arbetat på meddelandet. Credits used är de krediter som dragits för meddelandet så här långt.
Läser du posterna var för sig ser den 26 augusti ut som en ren förbättring och den 25 augusti som en detalj i en meny. Läser du dem tillsammans blir det tydligare vad som faktiskt ändrades för dig: en körning som förut tog slut av sig själv kan nu fortsätta långt bortom den punkt där du hade slutat titta, och samtidigt fick du för första gången ett sätt att se hur långt den kommit medan den fortfarande går att påverka.
Tio timmar är ett tak, inte en körtid
Det här är den läsning som lättast går fel, och den kostar mest när den gör det. Lovables dokumentation för Build mode skriver att verktyget arbetar på ett meddelande i upp till tio timmar, att de flesta meddelanden blir klara långt före gränsen och att arbetet avslutas under den sista halvtimmen. Tio timmar är alltså den yttersta ramen för hur länge ett meddelande får hållas igång – inte en uppskattning av hur lång tid din ombyggnad tar.
Skillnaden är praktisk. Om du läser taket som en körtid blir tålamod plötsligt en dygd: körningen får ju hålla på i timmar, så det är väl inget konstigt att den gjort det i tre. Om du läser taket som ett tak blir tre timmar i stället en uppgift som du bör ha bedömt vid 30 minuter, vid en timme och vid två – och som antagligen skulle ha delats upp någonstans på vägen.
- ”Det brukar ta timmar.” Källan säger tvärtom att de flesta meddelanden blir klara långt före gränsen. Någon andel, median eller typisk varaktighet anger den däremot inte, så räkna inte fram något eget tal ur den meningen heller.
- ”En lång körning är ett tecken på att den arbetar hårt.” Den kan lika gärna vara ett tecken på att den arbetar på fel sak. Tiden i sig skiljer inte de två fallen åt – det gör bara ett synligt resultat, och det är därför stoppregeln ska innehålla ett sådant.
- ”Nu vet jag vad det kommer att kosta.” Taket säger ingenting om vad din körning drar. Det som är belagt är riktningen: längre körning, fler krediter. Vad det landar på i ditt projekt står varken i changeloggen eller i dokumentationen.
Så läser du av en körning som pågår
Avläsningen sitter på meddelandet, inte på projektet. Det är en viktig avgränsning: du får veta hur det går för det meddelande du skickade, inte hur mycket som är kvar i arbetsytan. Två tal, båda knutna till den pågående körningen.
Chattdokumentationen skriver att More options-menyn är dold medan meddelandet är pausat för en kreditincheckning, och likaså när arbetsytan fått slut på krediter. Är menyn borta behöver det alltså inte betyda att något gått sönder – körningen kan stå stilla och vänta på dig någon annanstans i gränssnittet. Bygger du din stoppregel på att talen finns framme vid en viss tidpunkt behöver den tåla det här: hittar du inte menyn, leta efter pauskortet innan du drar någon slutsats om körningen.
Stoppregeln bestäms före körningen
En regel som formuleras medan du väntar är ingen regel. Den blir en efterhandsmotivering, och den lutar i praktiken åt att fortsätta, eftersom du redan har betalat för tiden som gått. Därför skrivs regeln innan meddelandet skickas, medan du fortfarande är likgiltig inför utfallet.
Formen är enkel: vid [tidpunkt] ska [synligt tecken] finnas, annars [beslut]. Det som gör den användbar är att alla tre leden är avgjorda i förväg. Tidpunkten ska vara tidig nog att ett stopp fortfarande sparar något – för en vanlig ändring i en befintlig app är 30 till 45 minuter en rimlig första avstämning, inte fyra timmar. Det synliga tecknet ska gå att kontrollera på tio sekunder utan att du behöver läsa kod. Beslutet ska vara ett av två: fortsätt till nästa avstämning, eller stoppa och dela upp.
Regel som inte håller
”Jag stoppar om det tar för lång tid.” Ingen tidpunkt, inget tecken, inget beslut. Den utlöses i praktiken när du blir irriterad, vilket kan inträffa efter tio minuter eller efter fyra timmar beroende på dagsform – och den ger dig ingenting att göra när den utlöses.
Regel som håller
”Vid 40 minuter ska inloggningssidan gå att öppna i förhandsvisningen. Gör den inte det stoppar jag, och skickar i stället ett meddelande som bara handlar om inloggningssidan.” Tidpunkt, tecken och beslut, alla bestämda innan körningen började.
Lägg märke till att regeln inte innehåller något kredittal. Det är avsiktligt. Ett tak för hur mycket ett enskilt meddelande får dra är en annan mekanism med en egen inställning, och den behandlas i Lovable pausar när ett meddelande passerat 20 krediter – så ställer du in din egen gräns. Stoppregeln här är en regel om framsteg: den frågar inte hur mycket körningen har kostat utan om den är på väg någonstans. De två går att ha samtidigt, och de svarar på olika frågor.
Att stoppa kostar det som redan är gjort
Behöver du byta kurs klickar du på stoppknappen medan Lovable svarar. Dokumentationen är rak om vad som händer sedan, och det är två saker som drar åt olika håll. Lovable behåller arbetet som hunnit bli klart – du förlorar alltså inte det som redan byggts. Men meddelandet debiteras för det arbete som redan är gjort, och sidan om krediter och förbrukning upprepar samma sak: stoppade Build mode-anrop debiteras utifrån det arbete som utförts hittills.
Följden för din stoppregel är att ett stopp har en kostnad som växer med tiden du väntar. Ju senare du stoppar, desto mer har du betalat för arbete du kanske ändå tänker göra om. Det är hela argumentet för en tidig första avstämning: vid 40 minuter är stoppet billigare än vid fyra timmar, och det du får veta är ungefär detsamma.
Den andra följden är mindre uppenbar. Eftersom arbetet behålls står din app efter ett stopp i ett halvfärdigt läge – nya filer kan finnas, en datamodell kan vara halvt ändrad, en vy kan vara påbörjad. Nästa meddelande utgår från det läget, inte från läget innan du skickade. Att veta var appen står innan du fortsätter är samma arbete som när en session har spårat ur, och det beskrivs i När modellen tappar tråden: arbeta i sessioner, inte i ett oändligt samtal. Har du en säkerhetskopia att falla tillbaka på är stoppet dessutom ett billigare beslut, vilket är själva poängen med Prova att återställa appen från en backup innan du behöver det.
När uppgiften ska delas upp i stället
Det längre taket inbjuder till en frestelse: eftersom ett meddelande får arbeta i tio timmar kan man ju lika gärna beskriva hela appen i ett svep och gå och lägga sig. Lovables egen dokumentation drar åt andra hållet. Den rekommenderar snävt avgränsade instruktioner – be om en ändring i taget och peka ut de filer eller ytor som ska röras, i stället för breda uppdrag – och kopplar snäva instruktioner till lägre kostnad. Det längre taket ändrar inte det rådet. Det gör bara att ett brett uppdrag numera kan hålla på mycket längre innan du får veta hur det gick.
Praktiskt betyder det att uppdelning är förstahandsvalet och den långa körningen undantaget. Det är samma arbetsordning som sajten förespråkar överallt annars och som gås igenom i En sak i taget: varför små steg vinner även när du inte kodar. Skillnaden nu är att priset för att strunta i den har blivit rörligare: förr tog det breda meddelandet slut, i dag kan det fortsätta.
En sak att inte blanda ihop med ett stopp: du kan skicka ett uppföljande meddelande medan körningen pågår. Dokumentationen skriver att Lovable tar upp varje meddelande vid nästa naturliga stopppunkt utan att förlora det som redan gjorts. Det är styrning, inte avbrott – användbart när du ser att bygget är på väg åt fel håll men inte vill kasta det som gjorts. Någon tidsgräns för när uppföljningen tas upp anges däremot inte, så räkna inte med att den träder in direkt.
- Du kan inte formulera ett synligt tecken på framsteg. Går det inte att säga vad som ska synas vid 40 minuter är uppdraget för brett för att övervakas. Det är ett skäl att dela, inte att sätta en längre tidsgräns.
- Meddelandet innehåller ordet ”och” mellan tre olika funktioner. Ny vy, ändrad datamodell och e-postutskick i samma mening ger dig en körning där du inte kan avgöra vilken del som fastnat.
- Du skulle inte kunna beskriva felet för någon annan. Om körningen misslyckas ska du kunna säga vad som gick fel och var. Hur en sådan beskrivning ser ut står i När någon säger ”appen fungerar inte”: få en användbar felrapport.
Gränsen mot kreditincheckningen
Två mekanismer kan avbryta en lång körning, och de utlöses av olika saker. Din stoppregel utlöses av tid utan framsteg och verkställs av dig med stoppknappen. Kreditincheckningen utlöses av förbrukning: Lovable checkar in när ett enskilt meddelande passerar din incheckningsnivå, som är 20 krediter som standard, och eftersom ett meddelande kan köra i upp till tio timmar kan en lång körning checka in flera gånger på vägen.
De två stör varandra på ett sätt som är värt att känna till. Medan meddelandet är pausat för en incheckning är More options-menyn dold, alltså precis den avläsning din stoppregel bygger på. I det läget är det pauskortet som har siffran, och beslutet ligger där i stället. Hur du sätter din nivå, vad kortets två val gör och varför en incheckning inte är ett kostnadstak hör hemma i nyheten om incheckningarna och upprepas inte här. Frågan om vad förbrukningen betyder över en hel månad hör i sin tur hemma i Vad kostar en publicerad AI-byggd app? Sex poster du måste räkna på – den här texten handlar om en körning i taget.
Du har en stoppregel skriven före körningen, med en tidpunkt, ett synligt tecken på framsteg och ett beslut som är ett av två. Du vet var avläsningen sitter: More options på det pågående meddelandet, med Working for och Credits used. Du kan säga varför tio timmar är ett tak och inte en förväntad körtid, och att källan inte anger vad en körning kostar – bara att en längre körning drar fler krediter än en kort. Du vet att ett stopp behåller det arbete som hunnit bli klart men debiteras för det, och att appen därför står i ett halvfärdigt läge efteråt. Och du känner igen de tecken som betyder att uppgiften skulle ha delats upp i stället för att övervakas.
Officiella källor · kontrollerade 28 aug 2026
- Lovable Docs, changeloggen: posten 26 augusti 2026 om att Lovable arbetar på varje byggmeddelande i upp till tio timmar innan det avslutas, att en stor uppgift därmed oftare hinner bli klar i ett meddelande och att ett meddelande som kör i timmar drar fler krediter än ett kort — samt posten 25 augusti 2026 om att du kan se tid och krediter för ett meddelande medan det körs ↗
- Lovable Docs, projektchatten: att More options-menyn också finns på det pågående meddelandet, att Working for är tiden och Credits used krediterna hittills, att menyn är dold vid en pausad kreditincheckning eller när arbetsytan är utan krediter, samt att stoppknappen behåller utfört arbete och debiterar för det ↗
- Lovable Docs, Build mode: tiotimmarsgränsen per meddelande, att de flesta meddelanden blir klara långt före den, att arbetet avslutas under sista halvtimmen, att ett uppföljande meddelande tas upp vid nästa naturliga stopppunkt utan att det gjorda går förlorat, och rådet om en ändring i taget med utpekade filer eller ytor ↗
- Lovable Docs, krediter och förbrukning: att stoppade Build mode-anrop debiteras utifrån utfört arbete, att Lovable checkar in när ett enskilt meddelande passerar incheckningsnivån på 20 krediter som standard, och att en lång körning kan checka in flera gånger ↗