Troubleshooting

Lovable Code Generation Stuck on Thinking? How to Unstick It

When Lovable hangs on 'Thinking...' for sixty seconds or more and stops accepting chats, the generation has usually stalled rather than crashed. The cause is almost always platform load, a circular prompt, or a change too large for one pass. This guide walks the safe unstick sequence, what never to do, and the moment to revert instead.

Get emergency help See the fix-it service

By Founder Name · Last verified: 2026-06-25

Why is Lovable stuck on 'Thinking...' and not generating?

A hang past sixty seconds usually means the generation request stalled, not that your app broke. Three causes dominate: platform overload during peak hours, a circular prompt where the AI loops on its own previous output, and a change too large to complete in one pass. The editor shows 'Thinking...' and quietly refuses new chats while the stuck request holds the lock.

Platform overload is the most common and the least your fault: when Lovable is under heavy load, the model queue backs up and individual requests time out silently. A circular prompt is self-inflicted — you asked the AI to fix a thing that depends on the thing it is fixing, and it keeps re-planning. A too-large change (rename a model across forty files, restructure routing app-wide) exceeds what one generation can finish before the request expires.

The tell that separates a stall from a real crash: the rest of the editor still responds. You can scroll the file tree and open the preview, but the chat input is locked. That is a held request, not a destroyed project. Your code on disk is exactly as it was before you sent the stuck prompt.

Lovable 'Thinking...' Stall — Cause and Action
What you see	Most likely cause	First action
'Thinking...' 60s+, editor still scrolls	Platform overload or queued request timed out	Wait 90s, then hard-refresh the tab
Hangs every time on the same prompt	Circular prompt — AI loops on its own output	Rephrase as one concrete, scoped instruction
Hangs on a big rename or restructure	Change too large to finish in one pass	Cancel and split into 2-3 smaller prompts
'Thinking...' then chat won't accept input	Stuck request is holding the editor lock	Refresh; the lock clears on reload
Spinner stalls right after a Fix click	Bug Doom Loop — compounding fix request stalled	Stop clicking Fix; revert to last checkpoint
Stuck at a fixed percent, not 'Thinking...'	Build step stalled, not generation	See the stuck-at-80-percent guide below

What's the first thing I should do when it hangs past 60 seconds?

Wait a full ninety seconds first — many stalls clear themselves once the platform queue drains. If the spinner is still frozen after that, hard-refresh the browser tab. A refresh releases the stuck request lock so the chat accepts input again. Do not send a second prompt on top of the first; that stacks two requests and makes the hang worse, not better.

Give it 90 seconds without touching anything — let the queue drain.
If still frozen, hard-refresh the tab (Cmd/Ctrl+Shift+R).
Wait for the editor to reload, then open the chat input and confirm it accepts text.
Check the file tree and preview — confirm your code is intact and matches what you had before the stuck prompt.
Only then resend, but rephrase the prompt smaller and more specific than the one that hung.

A hard-refresh does not lose work. Lovable autosaves generated code to your project before the chat returns, so a stuck 'Thinking...' that never completed simply means the last change was not applied — your prior state is untouched.

How do I rephrase a circular prompt that keeps stalling?

A circular prompt hangs because the AI cannot find a stable plan — it keeps re-deriving the same dependency. Break the loop by giving it one concrete, scoped instruction with no conditional logic. Replace 'fix whatever is breaking the build' with a named file, a named symptom, and a single desired outcome. Specificity collapses the search space the model is thrashing through.

Compound and conditional prompts are the usual offenders. 'Fix the auth AND update the layout if the user is logged in' forces the AI to plan two coupled changes plus a branch, and on a large project that plan never converges. Split it: one prompt for auth, confirm it works, then one prompt for the layout.

Bad (loops): Fix everything that is wrong with the login flow and make it work like it used to.

Good (converges): In src/auth/useSession.ts, the session is null after refresh. Persist the Supabase session to localStorage and rehydrate it on mount. Do not change any other file.

Adding 'Do not change any other file' is the single most effective guardrail against a prompt that balloons into a too-large change and stalls. It also limits the blast radius if the generation does land badly.

When should I cancel and split the change instead of waiting?

If the stall follows a sweeping instruction — rename a model everywhere, restructure routing, refactor a shared component used across the app — the change is too large to finish in one pass. Waiting will not help; the request expires before it completes. Cancel by refreshing, then split the work into two or three prompts that each touch a bounded set of files and verify before you continue.

Large single prompts collide head-on with context rot at file 6-7: once a generation has to touch six or seven files, the model loses track of the architectural decisions it made in the first files and starts producing inconsistent edits. A request that tries to touch forty files in one shot either stalls or lands a half-applied mess. Smaller prompts keep each generation inside the model's reliable working set.

A safe split for a model rename: first prompt updates the type definition and the database layer only; confirm the app still loads; second prompt updates the components that consume it; confirm again; third prompt cleans up imports. Each step is independently verifiable, and if one stalls you have lost one small step, not the whole refactor.

Do not respond to a stall by sending a bigger, more detailed prompt to 'force it through.' A larger prompt is more likely to stall, not less. The fix for a too-large change is always to make the next prompt smaller.

Is my code lost while it's stuck on 'Thinking...'?

No. A stuck generation that never returned means the proposed change was never applied — your project sits at the exact state it was in before you sent that prompt. Lovable keeps a full version history, so even a generation that did land before stalling is reversible. Refreshing the tab cannot delete code; it only releases the held request and reloads what is already saved.

Confirm it for yourself after the refresh: open the project timeline (clock icon in the left sidebar) and look at the most recent entry. If the stuck prompt produced no new checkpoint, nothing was committed and you are safe to resend. If it did create a checkpoint but the result looks wrong, revert to the entry just above it.

The one real risk is not the stall itself but what you do next. Sending three more prompts on top of a confused state is how a recoverable hang turns into the Bug Doom Loop — each new request spends a credit, generates fresh file changes, and often introduces a second error while chasing the first. Stop, refresh, verify state, then proceed deliberately.

Related: recover a lost Lovable project

When do I revert instead of trying to unstick it again?

Revert the moment unsticking stops being free. If a refresh-and-resend cycle has hung twice on the same prompt, or the editor returned to a state that no longer matches what you had, restore the last known-good checkpoint before doing anything else. Reverting first and diagnosing second is always cheaper than prompting your way out of a confused generation.

If the same prompt stalls every time even after reverting and scoping it down, the blocker is structural, not transient — there is a circular dependency or a model limitation that no rephrase will clear. That is the point to bring in a human. A senior engineer reads the actual source files instead of fighting the prompt context window, lands the change directly, and hands back a working build with a written explanation of what was stuck and why.

Open the project timeline (clock icon, left sidebar).
Find the last checkpoint where the app was working — check the preview thumbnail.
Click Revert to restore that version.
Open the pop-out preview to confirm the restored build loads cleanly.
Resend your change as one small, scoped prompt — and stop if it stalls a second time.

How is 'stuck on Thinking' different from stuck at a percentage?

They are different failures with different fixes. 'Thinking...' is a stalled generation request — the model never returned a plan, usually from load or a circular or oversized prompt. A spinner frozen at a fixed percentage (often 80) is a build or deploy step that hung after generation already finished. Knowing which one you are looking at tells you whether to refresh the chat or chase a build error.

If you are stuck on 'Thinking...', the unstick path is everything above: wait, refresh, rephrase smaller, revert if it repeats. If the chat already returned but the progress bar is frozen mid-build, the generation succeeded and a downstream step is the problem — a failed compile, a stuck publish, or a queued deploy. Those need a different diagnosis, not a chat refresh.

Frequently asked questions

Lovable has been stuck on 'Thinking...' for over a minute — is it broken?

Almost certainly not. A hang past sixty seconds is usually a stalled generation request, most often from platform load. Wait a full ninety seconds, then hard-refresh the browser tab to release the stuck request. Your code is unchanged — a generation that never returned was never applied. Resend the prompt smaller and more specific than before.

Will I lose my work if I refresh the tab while it's stuck?

No. Lovable autosaves your project before a generation returns, so a refresh only reloads what is already saved and clears the held request lock. A stuck 'Thinking...' that never completed means the proposed change was never committed, so you land back exactly where you were before sending it. Refreshing cannot delete code.

Why does Lovable stop accepting my chats when it's stuck?

The stalled request is holding the editor lock. Lovable processes one generation at a time, so while a request hangs, the chat input refuses new prompts to avoid stacking two jobs. A hard-refresh releases that lock and the input accepts text again. Do not try to send a second prompt on top of the first while it is frozen.

What is a circular prompt and how do I fix it?

A circular prompt asks the AI to fix something that depends on the thing it is fixing, so it loops on its own output and never converges — the spinner just hangs. Fix it by giving one concrete, scoped instruction: name the file, name the symptom, state one outcome, and add 'do not change any other file.' Specificity collapses the loop.

Does a stuck generation cost me a credit?

A generation that stalls and never returns typically does not complete a billable change, but the bigger credit risk is your reaction. Resending three or four prompts to force it through is what drains credits fast. Refresh, confirm your state, then send one deliberate prompt. If you are watching credits vanish on a single stuck issue, stop and revert.

How do I keep a large change from stalling in the first place?

Split it. Any prompt that touches six or seven files runs into context rot, where the model loses track of decisions made in the earlier files and either stalls or lands an inconsistent edit. Break a sweeping change into two or three prompts that each touch a bounded set of files, and verify the app loads between steps so a stall costs you one step, not the whole refactor.

It hangs every single time on the same prompt — now what?

That points to a circular dependency or a change too large for one pass, not a transient load issue. Revert to your last working checkpoint, then resend the change scoped down to a single named file and outcome. If the same prompt still stalls after reverting and shrinking it, the blocker is structural and no rephrase will clear it — that is the point to bring in an engineer.

Is being stuck on 'Thinking...' the same as being stuck at 80 percent?

No. 'Thinking...' is a stalled generation request before any code is produced — fix it by refreshing and rephrasing smaller. A bar frozen at a percentage means generation already finished and a build or deploy step hung afterward, which needs a build-error diagnosis instead. Identify which one you are seeing before you decide whether to refresh the chat or chase a build failure.

I refreshed and resent, but it stalled again — should I keep trying?

No more than once. If a refresh-and-resend cycle has hung twice on the same prompt, stop prompting and revert to your last known-good checkpoint first. Continuing to resend pushes a recoverable stall into the Bug Doom Loop, where each attempt spends a credit and adds new file changes. Restore a clean state, then send one small scoped prompt or get a human to land the change directly.

Can you unstick my Lovable project and finish the change for me?

Yes. For a project that hangs on the same generation no matter how you scope it, we book an emergency review within 24 to 48 hours. A senior engineer reads your actual source instead of fighting the prompt window, lands the stuck change directly, restores a clean build without burning your credits, and explains what was stalling. You keep full ownership of your code throughout.

Keep reading

App down or leaking data? Get an expert on it within 24–48h.

Book a free 30-minute audit call. We'll diagnose what's wrong and tell you exactly what it costs to fix.

Get emergency help