Lovable Credits: New Usage Limits Since October 7 and Why an Empty Balance Stops Your Live App

On October 7, 2026, Lovable introduced usage limits and alerts. That sounds like accounting, but it directly affects whether your app stays up. If you use Lovable in production, you pay for development and operation in the same currency.

What do Lovable credits pay for?

Two things: building and running. Credits are Lovable's billing unit, and the docs split them into these types:

Lovable Cloud is the built-in backend: database, login, and file storage that Lovable hosts for you. According to Plans and credits, you get 20 credits each month earmarked for Cloud and 4 for AI. After that, usage comes out of your general balance, starting with the credits that expire soonest. Connector requests use the general balance from the start.

For scale: Pro starts at 25 US dollars for 100 credits a month, Business at 50 US dollars, each with tiers up to 10,000 credits. Top-ups cost 15 US dollars on Pro and 30 US dollars on Business per 50 credits. So a top-up credit costs 0.30 or 0.60 US dollars depending on the plan, while the entry tier with 100 credits on a monthly subscription works out to 0.25 or 0.50 US dollars. Larger tiers are cheaper per credit: at 10,000 credits on monthly billing, roughly 0.23 or 0.43 US dollars.

What happens to your live app when credits run out?

The pages stay online, but the backend stops. Lovable says the database and backend services pause shortly after your balance is used up, and the app's AI features switch off. Your data is kept but stays unreachable until restart. Depending on the case, you may have to restart the backend manually with "Wake up" after topping up.

In practice, an app with a login still shows its homepage, but nobody can reach their data. An internal tool, a customer portal, or a form that writes to the database stops working. The trigger can be harmless: one teammate rebuilds a lot in an afternoon, and the monthly allowance is gone before the next billing date.

What can the new limits do?

They set thresholds per workspace, project, or member that either warn or block. The details from the docs on usage limits and alerts:

• Who: only owners and admins, and only on paid plans. Limits for groups and API access tokens are available on Business and Enterprise only.
• Period: daily or monthly. The month starts on the 1st at 00:00 UTC, regardless of your billing date.
• Early warning: at 80 percent of a blocking limit.
• Tolerance: usage can slightly exceed a hard limit before the block takes effect.
• No buying your way out: adding credits or upgrading does not lift a block. Only a new period, a higher limit, or disabling the limit does.
• Requests: a blocked member can ask for more, and an admin approves it indefinitely or until the end of the period.
• Low-balance alert: notifies you when the balance drops below an amount or percentage, and never blocks.

One detail decides the right setup: member limits only count build credits. Lovable attributes running costs to the project. If you want to cap Cloud or AI costs, set the limit on the project or workspace.

What is the trap in these limits?

A blocking Run limit takes your app down just like an empty balance. The "Pause Cloud" option stops database, storage, and backend, including in published apps. The page loads, but the features are gone for your users. Stored files keep costing credits during the pause. And a limit on all credits (General) stops building and running together.

Our take: for an app your customers or colleagues work with, a hard cap on running costs is almost never the right choice. A sudden outage usually costs more than a few extra credits. Cap building instead.

How should you set up the limits?

Here is how we would set it up today for a workspace with one live app and several people building:

1. Set a low-balance alert. For example at 25 percent of the balance. It blocks nothing and buys you time to top up.
2. Make a build limit per member the default. Monthly, with a block. Nobody can drain the allowance alone, and anyone who needs more can ask.
3. Run limit for the live project as a warning only. No block. If running costs spike, you want to know, not shut down.
4. Cap prototypes hard. For test and demo projects, the Run limit may block. A pause there bothers no one.
5. Limit access tokens (Business). Anyone calling Lovable via API or automation gets a separate token limit.

One more tip that saves credits: in Plan Mode, Lovable says a message costs one credit, plus any research by subagents. Plan larger rebuilds first, then build, and you avoid expensive detours.

What else did Lovable change on October 7?

Two updates for running apps, both in the October 7 changelog:

• Load warnings: Lovable tells you when the Cloud database is under high load, suggests changes to queries or code, and only then offers a larger instance, showing the credit impact. A larger instance raises your ongoing Run usage.
• Migrations in code: every change to the database structure lands as an SQL file in drizzle/migrations/. Drizzle is an open source tool for these change steps. Lovable refuses changes that could break the published app, such as dropping a column, unless you explicitly allow it in the Cloud permissions. Keep that option off for live apps.

What does this mean for you?

If you have a Lovable app in use, check three things today: who is an admin in the workspace, how much balance is left until the end of the month, and whether a live app shares a balance with your build experiments. If it does, set up the limits as above before someone finds out through an outage.

Our take: for client projects with real business processes, decide early in the architecture whether running costs should share a balance with building, or whether a separately hosted backend fits better. How we get from prototype to a robust MVP is covered in our article on MVP development. If you need automation around the app, see our cost comparison of Make vs n8n. And if you would rather set up your app together with us: get in touch.