WebContainers, the browser-based runtime StackBlitz built to run Node.js and operating system commands without a server, is the infrastructure Bolt runs on: a written description turns into a running web app inside the browser tab itself. Vibe coding in Bolt keeps every generated file visible while that happens. You prompt in plain English, an agent writes the project into a file tree you can open and edit, and a preview reloads next to it. The chat window is the input; the codebase it leaves behind is the thing you keep.
The browser tab as the runtime
Bolt is built on WebContainers, the StackBlitz technology that runs Node.js applications and operating system commands inside the browser itself. No remote build box sits in a queue somewhere. npm install runs in the tab. The dev server runs in the tab. The file system the agent writes into is a virtual one your tab owns, which is why a fresh project boots in seconds and why the preview refreshes without a deploy step.
Two consequences follow from that design. A project needing a native binary, a long-lived background worker or an unusual system dependency will not fit, because the runtime is a browser sandbox with no Linux server underneath it. And the tab is the machine, so a heavy install competes with every other thing the browser is doing.
Plan mode before build mode
Plan mode lets you plan and ask questions without making changes to your code, and it spends fewer tokens than Build mode because it changes nothing in the project. You describe the app, argue with the outline, ask what it intends to name things, and no file is written until you press the button that hands the plan to Build mode.
Get the plan to name the files, the data model and the routes before any of them exist. A plan reading “a form, a database table and an admin view” produces a different app on every run. A plan reading “a leads table with name, email and created_at, one POST route, one admin list page” produces the same app twice, which is what makes the second prompt cheap instead of another rebuild.
Standard and Max agents
Two agents sit behind the prompt box. Standard is the fast, token-efficient one, aimed at small to medium projects, interface changes and well-defined tasks. Max is the deeper one, meant for large codebases, tangled dependencies and open-ended problems where more reasoning per step pays for itself. Only Standard comes with the free plan.
Bolt handles model selection behind the scenes and does not publish which model powers which agent, so pick by the shape of the task. A colour change and a copy fix are Standard work. A refactor across a dozen files, or a bug nobody has been able to describe precisely, is where Max earns the upgrade.
Token arithmetic on the free plan
Bolt's free plan includes a limited number of tokens each month. Paid plans behave differently. Unused tokens carry over and stay valid for two months from the start of the billing cycle they arrived in, and spending is first in, first out, so the oldest rollover goes before the newest allocation.
What consumes them is worth knowing before the first prompt. Tokens go when Bolt reads your prompts and project files, thinks, responds and builds, while clicking an on-screen button or action uses none, and restoring an earlier version of the project uses none either. Reading is the part people forget about. A large project means a large read on every prompt, so a forty-file app answers a one-line question far more expensively than a six-file one does.
Reading the code the model wrote
The file tree is what makes this different from pasting snippets out of a chat window. You can open the component, see what the agent did to it, and rename a class by hand instead of spending a prompt on it. Version history keeps the earlier states and rolls back to them for free.
Connecting the project to GitHub gives you commits, branches and a repository you can clone and work in on your own machine. Without that connection, the project lives only inside Bolt's browser tab, where nobody else can review it line by line, hand it to a collaborator, or move it if the tool changes. Once the repository exists, the generated code is ordinary code: React components, a package.json, routes you can read.
Where the time goes
Speed felt and speed measured come apart. A tool that writes the first draft fast can still cost time on the read-back, especially on a project nobody on the team, including its own author, has lived in for long.
A model's output that looks right at a glance and is wrong underneath is exactly the failure a code-visible tool is built to catch. When the form submits but writes to the wrong table, a chat transcript gives you nothing to inspect and a file tree gives you the twelve lines where it went wrong. Reading those lines is the skill the tool is quietly teaching, and it is the reason to keep the editor pane open even while the prompts are doing the typing.
A first project worth building
The loop that works on a first build is short and repeatable:
- Write the plan in Plan mode until it names the files, the routes and the data model.
- Switch to Build mode, let it scaffold once, then read the file tree before prompting again.
- Fix small things by editing the file yourself, and save prompts for changes touching several files at once.
- Connect GitHub as soon as the app does something, so the project has a home outside the tab.
A single-page app with a form, a stored list and an admin view is the size that fits this loop comfortably, and it exercises every part of it: a data model, a route, a preview, a rollback when the third prompt breaks the second one.