Lovable credits are three balances wearing one name: build credits for editor work, Cloud credits for the live app, and AI-gateway credits for its model calls. A balance hitting zero mostly measures your editing rather than your app, which is why the spend can outrun what actually shipped, and it’s worth reading correctly before you decide the fix is a bigger plan.
Lovable meters three separate things, and only one pair of them tracks what a real user does to your app. Build credits pay for the editor session where you or Lovable’s agent write and revise code: 1 credit per message in Plan mode, roughly 0.50 to 2.00 credits per task in the Default build mode, per Lovable’s own documentation (verified 2026-07-16). Cloud credits pay for what your deployed app runs on: database, storage, compute, and realtime. AI-gateway credits meter every model call your live app makes on a visitor’s behalf, priced by tokens and model. The Free plan grants a small daily build allowance on top of a monthly Cloud and AI-gateway trickle, and what stops working when the balance hits zero is the part worth knowing before you rely on it; Pro and Business keep the same daily build grant with no monthly cap. Build credits are a development-time cost. Cloud and AI-gateway credits are the two that scale with traffic, and they’re the ones worth watching once real users show up.
Lovable Cloud credits vs. build credits: the distinction the docs bury
Build credits, Cloud credits, and AI-gateway credits sit under one “credits” umbrella in Lovable’s documentation, and in practice they behave nothing alike: build credits are a development-time cost, while Cloud and AI-gateway credits are the two that scale with traffic.
| Credit type | What it meters | Free monthly grant | Rolls over? |
|---|---|---|---|
| Build credits | Plan-mode messages (1 credit each) and Default-mode build tasks (about 0.50 to 2.00 credits each) | 5 a day, capped at 30 a month | Daily grants expire at day’s end and never roll over; unused monthly plan credits on paid plans roll over while the subscription stays active, expiring 2 months from issue on monthly plans and 1 month after the annual period ends on annual plans |
| Cloud credits | Database, storage, compute, and realtime for the live app | 20 a month | No. The unused grant resets: 1st of the calendar month at 00:00 UTC on Free, each billing cycle on paid plans |
| AI-gateway credits | Model calls your deployed app makes on a visitor’s behalf, priced by tokens and model | 4 a month | No. Same reset as Cloud: calendar month on Free, billing cycle on paid plans |
Beyond that grant, top-ups price out by plan: Pro runs $15 per 50 credits ($0.30 each), Business $30 per 50 ($0.60 each), and either batch stays usable for 12 months (verified 2026-07-16). Lovable run credits is what longtime users still search for, the name the product used before the current build, Cloud, and AI-gateway split. The docs now call the same balance build credits. The name changed. The disappearing act didn’t.
This is where the mismatch you noticed at the top of this post usually comes from. Watching the build-credit balance drain, it’s easy to assume the app itself is getting more expensive to run. Usually the editing is what’s getting expensive, not the app: stop re-prompting the same file ten times and the build-credit line flattens on its own.
When Lovable credit costs stop being a billing question
Cloud and AI-gateway credits are the honest signal, because they only move when your app is doing something for a real visitor. A build-credit spike means you had a busy afternoon in the editor. A Cloud or AI-gateway spike means your app is being used, in a way the free tier’s 20 Cloud credits and 4 AI-gateway credits a month were never sized for.
Once you’re buying top-ups every month just to keep the app answering requests, the editor fee has quietly turned into a hosting bill denominated in a currency you can’t compare to anything else. It’s one of the hidden costs of vibe coding, precisely because nothing on the pricing page frames it that way, and the question stops being how to spend fewer credits and starts being whether this app should still live on a metered backend at all.
I saw the sharper version of this on one of my own apps, not a client’s. A translation-management platform I built went through the same audit I point at client apps, and the cost story it told was exactly this shape: every paid call metered faithfully, and nothing positioned to stop the next one, no rate limit and no cap on any caller. It came back red, 53 out of 100. Measured and ignored are not the same thing as controlled. Lovable’s AI-gateway credits run the same mechanism with better guardrails: metered, visible in the dashboard, and still nobody’s job to cap unless you go set the limit yourself.
What the credits actually bought you
Lovable’s meter is honest about what it counts: messages, compute, tokens. What it can’t count is whether the code those credits bought survives a stranger using the app instead of you clicking through a demo. None of this is really a pricing complaint.
In the 21 third-party apps AxonBuild has audited, the credits (or their equivalent on whichever generator built each app) bought 958 confirmed findings, about 46 for each app, and only 58 of them critical. Every finding was adversarially verified against the code, not pattern-matched. Scores across the full 26-app corpus landed between 29 and 81 out of 100, mean 52. Even the 81, the best score in the set, wasn’t a green light: it belonged to an app with no real backend at all, which is its own answer about what a high number can mean.
Credits measure how much code you generated. They say nothing about whether the 6% that matters got written.
That last row is the decision buried inside every credit-cost question. Spending fewer credits and needing fewer credits are different goals, and only one is worth optimizing for once the app has real users. Whether the specific app your credits built actually clears that bar, independent of what it cost, is worth checking on its own terms: what a passing Lovable check can and can’t see covers the mechanism in full.
When graduating off Lovable is the right call, and when it isn’t
Not every app that burns through its Cloud and AI-gateway allotment needs to leave. If the spend is proportional (more users, more usage, a bill that scales the way you’d expect), staying on a managed backend is the reasonable choice: it’s still cheaper than running your own infrastructure team of one. The signal worth watching for is disproportion: a bill growing faster than your user count, or an AI-gateway line that moves even when usage looks flat, usually because a call somewhere has no cap on it.
The other trigger has nothing to do with the credit number. Once something real depends on the app (paying customers, a compliance requirement, data you’d have to explain losing), the question becomes the one whether an AI-built app is actually ready to launch already asks: not whether you can afford to keep building here, but whether what got built here is something you can depend on. Whether Lovable is safe to keep building on at all is a related, separate question, worth checking against the platform’s own data-breach history before the credits take the blame.
If the answer is to leave, the credit question mostly resolves itself: stop paying for a metered backend by not using one. Moving off Lovable Cloud (what the export actually gives you, what it leaves out, and what has to be re-verified on whatever you land on) is its own long answer, worth reading before you touch the delete button, and which Lovable alternatives actually change the outcome scores the six most-named ones on the four things that decide it. The same shape shows up one layer further down the stack, in Supabase egress limits, once your own backend replaces Lovable Cloud entirely.
Either way, the code getting harder to change every week you keep prompting it is the same code whether it lives on Lovable’s servers or your own, and moving it only changes who sends the bill.
Common questions about Lovable credits
How do Lovable credits work?
Three separate balances, not one: build credits for editor work (1 per Plan-mode message, roughly 0.50 to 2.00 per Default-mode build task), Cloud credits for your live app’s database, storage, compute, and realtime, and AI-gateway credits for the model calls your deployed app makes on a visitor’s behalf, priced by tokens and model. The Free plan grants 5 build credits a day, capped at 30 a month, plus 20 Cloud credits and 4 AI-gateway credits a month.
Does Lovable Plan mode use credits?
Yes, 1 credit per message. Plan mode draws on the same build-credit balance as building does, one credit for every message you send in it, while a Default-mode build task runs roughly 0.50 to 2.00 credits. Ten messages spent agreeing on an approach cost ten credits before a line of code exists, which is why a long planning conversation can empty a day’s grant with nothing shipped.
Do Lovable credits roll over on paid plans?
Unused monthly plan credits roll over while the subscription stays active, expiring 2 months from issue on monthly plans and 1 month after the annual period ends on annual plans; top-up batches stay usable for 12 months. Daily build grants never roll over on any plan, and Cloud and AI-gateway grants reset each billing cycle instead of accumulating. The free-plan version of the same question, where nothing carries forward at all, sits in what the Lovable free plan limits actually are.
Why are my Lovable credits running out so fast?
Usually one of two reasons. If it’s build credits, you’re re-prompting the same files repeatedly, chasing a fix that breaks something else. If it’s Cloud or AI-gateway credits, real traffic is hitting your app, a better problem, unless nothing is capping the model calls behind it.
Are Lovable credits too expensive?
Priced per credit, top-ups run $0.30 each on Pro and $0.60 each on Business (verified 2026-07-16), which is hard to judge against a competitor’s flat monthly fee. The more useful question is whether your Cloud and AI-gateway spend is proportional to real usage or growing because something’s uncapped, not the per-credit rate.
Are Lovable credits worth it?
For building and hosting an app without running your own infrastructure, yes, the same way any managed platform’s markup buys you out of running servers. What the credits can’t buy is a verdict on whether the code they paid for is ready for real users, and that verdict comes from looking at the app, not the invoice.
Don't guess where you stand.
The free 2-minute Beyond the Demo Scorecard estimates where you stand across 12 readiness areas and shows what to check first.