Lovable Credits Explained: What It Costs to Ship an App

Lovable credits are the single unit the platform bills everything in: building the app, chatting with the agent, hosting the published site, and any AI features your live app calls. On the Pro plan, 100 credits cost $25 a month, which puts a typical build message somewhere between 13 and 50 cents. The part that catches founders out is that a published app keeps spending credits after you stop building.

This guide is for founders building on Lovable who want to know what a month actually costs, which plan to be on, and how to stop a stuck loop from running up a bill. It covers the credit model, what individual changes cost, where spend hides after launch, the controls that cap it, and the point where credits stop being the cheapest way to finish a product.

Key takeaways

• One balance pays for everything: building, chat, hosting, the built-in backend, and the AI calls your deployed app makes.
• Pro starts at $25 a month for 100 credits and runs to 10,000 credits a month. Top-up credits cost more per credit than subscription credits.
• Build cost is usage-based rather than per message, so a style tweak and a new sign-in flow are priced very differently.
• Run credits accrue while you sleep. A live app with users and a database has a monthly floor you did not choose.
• Every paid plan can set hard credit limits per project, per member and for the whole workspace. Set them before you need them.

What is a Lovable credit?

A credit is the unit Lovable uses to measure every kind of usage in a workspace, and there is only one balance. Credits belong to the workspace rather than to a person, so everyone on the plan draws from the same pool.

That usage splits into five kinds: build, chat, Cloud (hosting and the built-in backend), AI gateway (model calls your deployed app makes), and metered connectors such as Perplexity and Firecrawl. Included grants are spent first, then general credits, starting with the ones closest to expiry (Lovable's credits and usage documentation).

Build credits and run credits

The reporting views group those five into two numbers, and the difference matters more than the names suggest.

What to compare	Build credits	Run credits
What they pay for	Plan and Build mode messages, chat, generated images and video	Hosting, database, storage, network, realtime, AI calls, connectors
Who spends them	You and your team	Your users and your scheduled jobs
Spend when you stop working	Nothing	Continues
Can be capped per member	Yes	No, only per project or workspace

Founders budget for the first column and get caught out by the second.

How much does Lovable cost per month?

The Free plan costs nothing and includes five build credits a day, capped at 30 in a calendar month, which works out as the first six days and then nothing. Paid plans start at $25 a month for Pro and $50 a month for Business, both at the 100-credit tier, and both scale to 10,000 credits a month.

Plan	Entry price	Monthly credits	What it adds
Free	$0	None; 5 build credits a day, 30 a month	Git sync, publishing, templates
Pro	$25 a month	100 to 10,000	Editing and downloading code, custom domains, top-ups, rollover
Business	$50 a month	100 to 10,000	SSO, role-based access, security centre, the Lovable API
Enterprise	By contract	Volume-based	Audit logs, SCIM, EU inference; no daily grants

Inside Pro, the first four tiers price credits at a flat 25 cents: $25 for 100, $50 for 200, $100 for 400 and $200 for 800. Volume discounts begin at the 1,200-credit tier and reach 10 percent at 5,000 credits for $1,125 a month, and annual billing is charged as ten months rather than twelve (Lovable's pricing page). The feature differences, including the fact that editing or downloading your own code and using a custom domain all need a paid plan, are set out in Lovable's plan comparison.

Top-ups are priced separately and cost more: $15 for 50 credits on Pro, so 30 cents each, and $30 for 50 on Business, so 60 cents each. Lovable's own advice is that a recurring need is better served by moving up a tier than by topping up, and the arithmetic agrees.

For context on what the whole job costs, our breakdown of what an MVP costs to build puts a simple, single-workflow product at $8,000 to $25,000. A full year of Pro at the 400-credit tier is $1,200. Those numbers are not competing, because they buy different things, which is the subject of the last section.

What does one change cost in credits?

Plan mode costs one credit per message, plus any research the agent runs while planning. Build mode is priced on the work completed, so there is no flat per-message price.

Lovable publishes illustrative figures, which are best read as orders of magnitude rather than as a price list. The right-hand column converts them at the Pro rate of 25 cents a credit.

Request	Credits used	At 25 cents a credit
Make the button gray	0.50	$0.13
Remove the footer	0.90	$0.23
Add authentication	1.20	$0.30
Build a landing page with images	2.00	$0.50

Two things follow. A day of small, well-aimed edits is genuinely cheap, and the five free daily build credits cover a fair amount of it. And the price of a request tracks how much the agent has to explore, verify and regenerate, not how long your prompt was.

You can read the exact figure for any reply from the More options menu under it, and that is the only number that describes your project. A Build mode run you stop before it changes anything is not charged at all.

Why do credits disappear faster than founders expect?

Three patterns account for most of the gap between the examples above and a real monthly bill: repeated attempts at the same bug, long autonomous runs, and the app itself.

Re-prompting the same bug

Every retry is billed on the work done, so the fifth attempt at a sign-in problem costs roughly what the first did. It also rewrites code that was probably fine, which is how one bug becomes three.

The cheap fix is to read the error before prompting. Open the browser console on the live site, copy the exact message, and paste that into the chat instead of "it is broken". Many of these faults are configuration rather than code, and a published app behaving differently from the preview is almost always a setting. No amount of regeneration fixes a setting.

Long runs and goal mode

A single Build mode message can run for up to ten hours. Lovable pauses to check in when one message passes your credit check-in level, which defaults to 20 credits, but that is a notification threshold rather than a cap: a run can go slightly past it, and sending a new message resets the count.

The /goal command is the expensive one. The same work uses noticeably more credits because the agent keeps going until the goal is met. It suits a well-defined job and is a poor way to explore.

Your live app spends credits too

Once an app is published, its database instance, stored files, network traffic, background jobs, realtime messages and AI calls all draw on the same balance. Free, Pro and Business workspaces get a 20-credit monthly Cloud grant and a 4-credit monthly AI grant, both described as a temporary offering, and anything above that comes out of general credits (Lovable's notes on project usage and costs).

Twenty credits is five dollars of hosting. That is plenty for a quiet app and nowhere near enough for one with an AI feature in the main user flow, because AI gateway usage is priced on the underlying model and scales with tokens and call volume.

How do you cap Lovable spend before it happens?

Use the workspace controls instead of watching the balance yourself. Usage limits and alerts is available on every paid plan and lets owners and admins set a threshold, choose what it watches, and decide whether reaching it notifies, blocks, or both.

1. Set a workspace monthly limit at the figure you are willing to spend, with blocking enabled. A limit that takes effect immediately asks you to type BLOCK to confirm.
2. Add a per-project default so one experiment cannot drain the pool. A default gives every project its own allowance rather than a shared one.
3. Cap each member's build credits if more than one person prompts. Member and group limits can only watch build usage, because run usage belongs to the project.
4. Create a low-balance alert, as either a credit figure or a percentage. This is the one that warns you before a deployed app pauses.
5. Give auto top-up a monthly spend limit. The defaults add 100 credits whenever the balance falls below 25, up to 400 credits a month. Leaving that at "No limit" is how a stuck loop becomes an invoice.
6. Read Usage details weekly for the first month, filtered by project and by person, until you know your own numbers rather than anyone else's.

On the run side the levers are different: pause the backend on projects you are not using, right-size the database instance instead of leaving it large, delete storage you no longer need, and check how often scheduled jobs fire. Asking the agent in the project chat what drives that project's run usage is a reasonable first step, because it reads the recorded usage rather than guessing.

What happens when you run out of credits?

The published site stays online, but the parts of it that need credits stop. Building is blocked until credits are available, and work already in progress pauses with the choice of adding credits to resume or having the agent finish what it started.

• AI features in the deployed app stop working while the balance is at zero, so a chatbot or a summariser fails for real users.
• Apps that rely on the built-in backend can pause, which takes the database, storage and authentication with them.
• Your data is safe but out of reach while those services are paused. Adding credits may not restart them on its own, and the project's Cloud overview has a Wake up control for that.
• Chat keeps working until the daily chat allowance is used up, because that allowance does not depend on your balance.

That order of failure is the argument for the low-balance alert. Running out while you are building is an inconvenience. Running out while customers are using the app is an outage.

When do credits stop being the cheap option?

Credits are good value for exploration and small changes, and poor value for work that needs judgement rather than generation. The signal is not the size of the bill but what the bill is buying.

Monthly credit spend	What it usually means	What to do next
Under $25, mostly free grants	Prototyping and light edits	Stay where you are and keep building
$25 to $100	Steady work on a real product	Set limits, and match the tier rather than topping up
$100 to $300 with a live app	Real users, or repeated attempts at the same fix	Separate build from run before upgrading anything
Over $300 and climbing	Credits are paying for rework	Have an engineer read the code

The practical test is to look at last month's build credits and ask how many of them produced something you kept. Credits spent generating features you shipped are an investment. Credits spent re-attempting the same sign-in bug, or regenerating a payment flow until the webhook finally sticks, are rework, and rework does not get cheaper with more attempts.

Two moves reduce spend without leaving the platform. Taking the code into a repository you control lets an engineer work normally on the parts that need care while quick changes stay in Lovable. And finishing the unglamorous work properly once, rather than prompting around it, removes the loop altogether; the pre-launch checklist for an AI-built app covers the gaps that generate the most retries.

Common mistakes with Lovable credits

• Enabling auto top-up with no monthly limit. It will do exactly what you told it to do, all month.
• Treating a published credit figure as a quote. The examples describe small, isolated changes. Only your own usage history describes your project.
• Buying top-ups every month. At 30 cents against 25 cents on a subscription tier, that is a premium paid for not deciding.
• Forgetting that monthly plan credits expire. On monthly billing they last two months from issue, so a quiet month does not bank indefinitely.
• Leaving old projects with files and jobs in place. Idle backends pause on their own, but stored files keep using credits while a project is paused, and a scheduled job stops it going idle at all.

Frequently asked questions

Do Lovable credits expire or roll over?

Unused monthly plan credits roll over at the end of each billing cycle while the subscription is active, but they keep their original expiry date: two months from issue on monthly billing, and one month after the annual period ends on annual billing. Top-up credits last 12 months from purchase. Daily and monthly grants never roll over.

Is it cheaper to buy top-ups or move up a credit tier?

A tier, if the need repeats. Subscription credits are 25 cents each on Pro up to the 800-credit tier, while top-ups are 30 cents on Pro and 60 cents on Business. Top-ups suit a genuine one-off spike, and their 12-month validity is longer than a monthly credit's two months.

Why does my app use credits when I am not building anything?

Because hosting and the built-in backend bill from the same balance. The database instance, stored files, network traffic, realtime messages, scheduled jobs and any model calls your app makes all count as run credits. Open More, then Cloud, then Usage inside the project to see which category is responsible before you change anything.

How many credits does it take to build an MVP?

There is no honest single number, because Build mode is priced on work completed and the same prompt costs more in a tangled project than in a clean one. The useful approach is to build for a week on the 100-credit tier, read your own usage breakdown, and extrapolate from that.

Budgeting a Lovable build

Start on the tier that matches how much you actually build, set a workspace limit and a low-balance alert on day one, and track build credits and run credits as two separate numbers. If the build number keeps climbing while the product does not, the problem is rework rather than the plan you are on.

If you would rather have the last stretch finished for a known figure, AlgoSmiths works on fixed-price projects with senior engineers and a working demo every week. You can see the fixed-price path from a stuck build to launch on our home page.