What changed
Bolt.new added prompt queueing, so you no longer have to wait for a build to finish before typing your next instruction. Bolt.new is a browser-based tool that builds working apps from plain-English prompts: you describe what you want, and it writes and runs the code for you.
Before this update, the prompt box locked while Bolt was working. You’d type a request, watch the build run, and only get to type again once it finished. Now you can type a second, third, or fifth prompt while the first one is still building. Each one joins a queue and fires automatically, in order, once the build ahead of it finishes.
Bolt says prompt queueing is live in every Bolt.new project for all users.
You can manage queued work:
- Reorder: drag any queued prompt up or down.
- Edit: open your own queued prompt, rewrite it, and confirm. Confirming does not send it early; it still waits its turn.
- Delete: remove your own prompt before it runs.
- Stop: halt whatever Bolt is building right now. The whole queue pauses with it.
- Resume: one button restarts the queue where it left off.
If a prompt fails, it keeps a retry button instead of vanishing or auto-retrying, so you decide when the queue moves again. On team projects, everyone sees the same queue update live and can add to it together. Each prompt also remembers which agent mode you picked for it (Bolt’s standard mode or its more thorough “max” mode), so a quick prompt and a heavier one can sit in the same line without conflicting.
Why it matters
The old flow forced a rhythm: type, watch, wait, type again. That’s fine for a single change, but it breaks down the moment you’re thinking faster than Bolt can build, if you have several changes in mind. Queueing removes that forced pause. You can think in bursts and let the ideas land in order instead of losing them or holding them in your head until the spinner stops.
A later instruction may rely on assumptions you have not checked in the previous result. If you queue “add a table to store customer leads” and then, in the same breath, queue “build a dashboard that shows those leads,” the second prompt is betting that the first one lands exactly the way you imagined it. If the first step produces a different structure, the next prompt may need adjustment. Queueing preserves order, but it does not confirm that the previous result matches your intent.
Check your project’s usage when queued prompts run; queueing is not a reason to assume builds cost less.
Who should care
This matters if you’re the kind of builder who fires off several small changes back to back, especially in one active session where you already know roughly what you want next. It matters less if you tend to make one change, look closely at the result, and decide your next step from there. In that case, you still need to review the result before deciding the next step.
What builders should do next
Use the queue for independent prompts, and pause to inspect results between steps that depend on earlier changes.
End of article