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 it’s live in every Bolt.new project, for everyone, starting today. There’s no plan restriction mentioned in the announcement.
You get real control over the queue, not just a waiting line:
- 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, which is often. 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.
There’s a real tradeoff worth knowing before you lean on this habit. A queued prompt is written against the project as it exists right now, not as it will exist once the prompt ahead of it finishes. 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 table comes out with different column names or a different structure than you expected, the dashboard prompt is now building against something that doesn’t quite exist yet, and you’ll likely need a follow-up fix instead of a clean second build.
Bolt’s announcement doesn’t say anything about credit or token cost for queued prompts, so don’t assume queueing itself changes what a build costs you. Nothing in the post suggests it does.
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 the queue mostly saves you from re-typing while you wait, not from a longer chain of decisions.
What builders should do next
Test this against a real multi-step build instead of assuming it saves time. Pick a task you’d normally do in three prompts that depend on each other, for example: add a data table, then a form that writes to it, then a page that displays what’s in it.
Run it twice. First, the old way: type one prompt, wait for the build, look at the result, then type the next. Second, with the queue: type all three prompts back to back while the first one is still building, without stopping to check the result in between.
Compare two things. First, total time from your first prompt to a finished, working three-part build. Second, how many of the three queued prompts needed a follow-up correction because they were written against a project state that hadn’t actually finished yet, versus the sequential run where you could adjust each prompt based on what you’d just seen. If the queued run saves real time and needs few corrections, it’s a good default for chains of related changes. If it costs you a round of fixes that eats the time you saved, keep queueing for independent, unrelated ideas and go back to watch-and-type for anything where each step depends on the last one landing exactly right.
End of article