Base44 stuck on 'Thinking'? Here's how to get unstuck

The spinner next to “Thinking” hasn’t moved in three minutes. No error, no partial response, no progress bar — just the same three dots, cycling forever. You refresh the tab out of habit. Still thinking. You type “are you stuck?” into the chat. Nothing comes back.

If you searched “base44 stuck on thinking,” “base44 not responding,” or “base44 infinite loop,” this is a known failure mode, not a one-off glitch. And if you’ve watched a sandbox session time out mid-generation and burn credits for a response you never got, that’s the same underlying problem showing up on the billing side.

Why Base44 hangs on “Thinking”

There isn’t one cause — there are three, and they compound the longer a session runs.

1. Context overflow. The longer a chat runs and the bigger the app gets, the more context Base44 has to hold to generate a coherent response — the full file tree, prior messages, your app’s schema, whatever it’s already built. Past a certain size, the model either takes a very long time to process all of it or effectively stalls trying to reason over more than it can handle in one pass. This is the same class of problem as any long-running AI coding session — more history in the window means more for the model to reconcile before it can act.
2. Contradictory instructions piling up. Across a long conversation, you’ve likely asked for things that partially conflict — “make it simpler,” then later “add this feature back,” then “actually keep it the way it was.” Each instruction on its own is fine; the accumulated set isn’t always resolvable. The agent can end up trying to satisfy constraints that don’t fit together, and instead of asking for clarification, it just doesn’t produce anything.
3. Silent API timeouts that retry in the background. Base44 calls out to an underlying model API to generate its response. If that call times out, the retry sometimes happens invisibly — the UI still says “Thinking” because, as far as the frontend knows, it’s still waiting on a response. You have no way to tell “this is a slow generation” apart from “this call failed and is quietly retrying” from the chat window alone.

None of these are your fault, and none of them are fixed by asking the agent if it’s stuck — the agent isn’t reading your messages while it’s in this state, so “are you stuck?” just becomes one more unread message queued behind the hang.

The get-unstuck sequence

1. Give it a real wait threshold before you act. Two to three minutes is normal for a complex request on a large app. Past five minutes with zero movement — no partial text, no tool-call indicator — treat it as hung, not slow.
2. Refresh first, but know what a refresh does and doesn’t fix. Reloading the tab can clear a frontend-side rendering stall. It will not fix a genuinely hung backend generation — if the request is still stuck server-side, you’ll refresh into the same “Thinking” state a moment later.
3. If a refresh doesn’t clear it, start a new chat instead of continuing the old one. This is the actual fix, not a workaround. A fresh session drops the accumulated context and any contradictory instructions baked into the old thread — which removes two of the three causes above in one move. Don’t try to resume the exact same request in the old thread; start clean.
4. Restate the request precisely in the new session — don’t just paste your last message again. The old message was written assuming the agent already had all the prior context in view. In a fresh chat it doesn’t. State the current state of the app, the one thing you want changed, and nothing else. This is also the moment to cut anything vague — “make it better” or “fix the issues” is exactly the kind of underspecified ask that leads back into another long, meandering session. If you’re not sure your restated request is precise enough, running it through something like Traileo, which turns a rough “it’s still off” into a specific, scoped fix request, is a fast way to sanity-check it before you spend another generation on it.
5. Break big asks into smaller ones before you resubmit. If the original request bundled multiple changes — new feature, plus a schema change, plus a style pass — split it. Ask for one piece, confirm it lands, then ask for the next. Large multi-part requests are more likely to hit context overflow and more likely to produce a response that partially contradicts what’s already there.
6. If it hangs again immediately in the new, smaller-scoped chat, that’s a signal the timeout is on Base44’s infrastructure side (the silent-retry case), not something you can prompt your way around — wait it out or try again after a few minutes rather than resubmitting repeatedly, since repeated resubmits are what burns credits on sandbox sessions that time out mid-generation.

The blank-screen variant

A related symptom: the agent finishes — the “Thinking” indicator clears, the chat shows a normal response — but your app preview is now blank or white. Same underlying territory, different failure point: the generation completed, but something in the result broke the render. Quick checks, in order:

1. Open the browser console in the preview pane. A blank screen after an AI-generated change is very often a JS error — a component that references a prop or import that no longer exists after the edit. The console will usually name the exact file and line.
2. Check for a schema mismatch. If the change touched your data model, look for a preview trying to render data shaped for the old schema. This shows up as errors referencing a field that’s undefined or a type mismatch, not a generic crash.
3. Hard-refresh to rule out stale cache. Before assuming the generated code is broken, force a full reload (not just a soft refresh) — a cached bundle serving old JS against a new schema, or vice versa, produces the same blank-screen symptom as an actual bug and is much cheaper to rule out first.
4. If the console is clean and a hard refresh doesn’t help, treat it as a real regression and describe the specific blank state (not “it’s broken”) back to the agent in a fresh message — what you expected to see, what you see instead, and whether the console showed anything.

Avoiding the recurrence

Both failure modes get worse the longer and messier a session runs, so the prevention is the same for each:

• Keep conversations short. When a chat has been open for a long time and covered a lot of ground, that’s your cue to start a new one for the next piece of work rather than continuing to build on top of it.
• One change at a time. Resist bundling a feature add, a style tweak, and a bug fix into a single message. Each one you isolate is one less thing that can conflict with something you asked for three messages ago.
• Don’t let “make it better” accumulate. Vague follow-ups are how contradictory instructions build up in the first place. Precise, scoped asks keep the context clean enough that the agent isn’t reconciling six different versions of what you want.

Verify

1. Confirm the new chat actually produced a response — text in the chat pane, not just a cleared spinner.
2. Reload the preview with a hard refresh and check the browser console is clean before deciding the fix landed.
3. If the original ask was split into smaller pieces, confirm each piece individually rather than assuming the whole set worked because the last one did.
4. Check your credit usage after a hang — if a sandbox session timed out mid-generation, confirm whether that generation was charged, so you know whether to avoid repeating the exact conditions that caused it.