Vibe coding 101 with Replit starts with checkpoints: Replit Agent logs one each time it finishes a request, and that single rule decides whether your bill reflects five small fixes or one expensive rewrite. You type a prompt, Agent edits files, the preview pane reloads with a working app, and you keep prompting until the thing on screen matches what you pictured. Two meters run while you do it: the AI work that builds the app, and the hosting that keeps it online once you publish.
The browser tab as the whole toolchain
One page holds everything. Replit's own documentation for building with Agent describes Agent as able to plan changes, write code, explain behavior, debug issues and improve an app, with its code changes updating the running application in the browser preview.
That last part is the piece people underestimate. You are not reading a diff and imagining the result. The app restarts and you click through it, which means every prompt gets tested against a running thing seconds after it lands.
Agent also has a Plan checkbox. Turning it on makes Agent write out the user flows, the components it intends to touch, the risks it sees and a testing approach, and wait for you to approve before it edits a file. For a first project this is worth the extra step on anything bigger than a copy change. Reading a plan and saying "no, the login should use email codes instead of passwords" costs one message. Discovering the same thing after Agent has written an auth system costs a rebuild.
The other input Agent takes is visual. You can paste a screenshot of a broken layout or annotate the preview on the Canvas, and Agent works directly from the image. Describing a misaligned button in words is slow and lossy. Showing it is neither.
Checkpoints and rollback
A checkpoint is the unit Replit measures work in. Replit's Agent billing documentation says that one checkpoint per request removes intermediate checkpoints and cuts billing noise. So a checkpoint maps to one request you made, with every file Agent touched along the way folded into it.
Checkpoints stack up in the History panel, and each one carries a "Rollback here" action that restores the file state from that point. Before it runs, the rollback confirmation spells out what will be put back.
Prompt one change at a time, click through the preview, and when the app still works you have a clean point to fall back to. Batch five unrelated changes into one prompt and the only rollback available takes all five away, including the two that were fine. Small prompts are cheaper to undo, and they are easier to diagnose when something breaks.
Effort-based pricing
Replit bills Agent on effort rather than on a flat per-message rate. Its billing documentation states that simple requests such as bug fixes and small changes cost less, while complex builds such as full features and integrations cost more, to reflect the total effort involved.
Two things follow from that. A long conversation of small corrections is not automatically expensive, because each correction is small work. And a single ambitious prompt ("build me a marketplace with payments, reviews and messaging") is one request that carries the whole build behind it. Beginners often assume the opposite, that fewer prompts means a smaller bill, and prompt in large vague blocks to save money.
Integrations have a second meter behind them. Replit says Agent wires up third-party services without you supplying API keys, and that you are billed at the provider's public API rate, deducted from your Replit credits. An app that calls an image model or a mapping service on every page load is spending on each of those calls, separately from the effort charge for writing the code.
Plan Mode is also the cheap way to argue. Refining the approach in conversation before Agent commits to generating code keeps the disagreement in the chat, before anything lands in the codebase.
Publishing costs after the build works
Building and hosting are priced apart, and the hosting bill depends entirely on what shape the app is.
For a first project, what the app needs matters more than any single number attached to it. A portfolio site or a landing page compiles to static files and costs cents in transfer. A small app with a database and a handful of daily visitors sits in autoscale territory, where the base fee dominates and the per-request line stays near zero. Reserved VMs exist for work that has to stay warm, like a Discord bot or a scheduled job that cannot tolerate a cold start, and that is where a hobby project quietly turns into a monthly subscription.
Where a first build goes wrong
The failure mode is rarely a broken app. It is an app that looks correct and is wrong in one place.
Vibe coding does not exempt you from that. It changes where the work sits. You spend your time reading behavior instead of reading syntax, which is why clicking through the preview after every checkpoint is the whole discipline. If you have not run a prompt-driven build before, working through a first vibe coding project end to end teaches more than reading about the loop.
Four habits catch most of it. Prompt one change at a time so a rollback costs one change. Turn on Plan before anything structural. Say what the app should do in specifics, including the empty state and the error case, because Agent builds the happy path when that is all you described. And open the app in a private window before you call it finished, since a logged-in session hides every permission bug you have.
The concrete next move is smaller than most first projects: pick something with one screen, one form and one stored record, ship it to a static or autoscale deployment, and watch what the first week costs before you build the version with accounts and payments in it.