How to give complete strangers permission to spend on your credit card

You have built an AI app. It works. Strangers can upload things, ask questions, generate answers and click the little button again when the first answer fails to capture the precise emotional register of their LinkedIn announcement. You are delighted. Engagement! Traction! People using the product! Somewhere, a model provider is equally delighted. It has customers too. One of them is you.

Nobody has stolen your API key. Nobody has hacked anything. Nobody is doing anything devious, prohibited or even particularly rude. They are using the service you offered, within the permissions you gave them. Every perfectly ordinary click authorises work on your account. You have not built a security breach. You have built a public bar with your card behind the counter and a sign saying: help yourselves.

This is the part of vibe coding that does not make the celebratory launch video. AI has made connecting the plumbing absurdly easy. It has not made paying for what flows through it optional.

The button works. So does the meter.

In Lovable, adding an AI feature can be a conversation rather than a technical expedition. Ask for a document summariser, a chatbot or an image generator, and the platform can wire up the model calls. The built-in AI route does not require you to open a separate provider account and hunt for a key. That is genuinely useful. Removing friction is not a conspiracy. But friction used to provide one inconvenient benefit: somewhere between opening the provider account and entering payment details, you occasionally remembered that there was a bill.

Now the distance between “wouldn’t it be nice if this generated ten variations?” and a working ten-variation button is very short. The distance between that button and an economic model may be infinite. Your demo becomes a published app. Your private testing becomes public consumption. You move on to the font. The meter does not.

Your visitor is not normally paying OpenAI, Google or Anthropic when your app makes a call through your account. You are. A visitor having their own ChatGPT subscription does not magically pay your API invoice. Nor does your own ChatGPT or Claude consumer subscription normally include the API usage your application generates. Same logo, different till. Branding is not a billing arrangement.

First, separate the two bills in your head

AI used to build your app and AI used inside your app are different activities. Asking Lovable to fix the layout is building. A hundred visitors asking your finished app to rewrite their CVs is running it. The second activity can continue while you are asleep, on holiday or congratulating yourself for no longer needing a developer.

Lovable’s current system draws building, Cloud and built-in AI usage from one workspace credit balance, with separate included allowances and usage categories. The first four credits of built-in AI usage each month are included on every plan; beyond that, eligible general credits fund it. The five free daily building credits are not an endless public chatbot allowance. Nor is that small monthly AI inclusion a business model.

For accuracy, this is not a claim that Lovable secretly gives every public app an unlimited postpaid tab and invoices you afterwards. Its built-in AI requests fail with HTTP 402 when available AI funding is exhausted. Without automatic replenishment, a nasty surprise may be a drained balance and a broken feature rather than a huge new card charge. Enable auto top-up, fund usage with additional purchases, or connect your own separately billed provider account, and the financial exposure changes. Know which arrangement you actually have before writing the angry forum post.

On monthly Pro or Business plan credits, built-in models are billed at the provider’s list price, without a model-price markup; annual plan credits make the equivalent usage less expensive. The convenience is not the offence. Authorising consumption without deciding how much you can afford is the offence, and the accused is wearing your slippers.

Your nicest user can be your most expensive problem

Imagine a teacher generating materials for tomorrow’s lessons. Twenty worksheets, three versions of each, simplified versions for another group, then answer keys. Or a recruiter uploading a stack of CVs. Or a perfectly satisfied customer refining one image thirty times because you have provided a button labelled “Try again”. None of them needs criminal intent to make your costs unpleasant. They only need a reason to use your product.

The beautiful thing about a useful AI service is that people use it. The awkward thing about a metered AI service is that people use it. You have confused those two sentences because one looks good in analytics and the other arrives in billing.

Sign-in does not solve this. It tells you who is consuming. It does not decide what they are allowed to consume. Payment does not solve it either if you sell “unlimited AI” for a fixed monthly price while buying every generation by the unit. Your most enthusiastic subscriber can be a negative-margin customer with impeccable manners.

A free trial without a finite allowance is not a trial. It is an invitation to find out how much of your money someone needs before deciding they are not interested.

Choosing the wrong model: a limousine for a trip to the bin

There is a peculiar instinct among new builders to select the most impressive model available, as if the expensive label will confer competence on the business. A flagship reasoning model to tidy a sentence. A long-context model sent an entire archive to answer a question about one paragraph. Premium image generation for disposable previews. The application equivalent of hiring a chauffeur to move the wheelie bin six feet.

Model prices do not consist of a single universal “cost per token”. Input and output can have different prices. Cached input can have another price. Long-context tiers can change the rate. Reasoning tokens can be billable even though the visitor never sees them as ordinary answer text. Images, audio, video and tools introduce their own units and fees. Read the pricing for the exact model and feature, not the screenshot from someone’s launch-day thread.

A model that is cheaper per token may still cost more per useful result if it produces longer answers, retries more often or needs several attempts. A model that is more capable may justify its cost for difficult work. The sensible choice is the least expensive configuration that reliably meets the quality requirement for that particular task. That requires representative testing, not religious affiliation to whichever provider currently has the nicest benchmark chart.

Do not automatically downgrade something safety-critical or complex because this article made you nervous. Test real tasks. Compare correctness, latency and total cost for a successful outcome. Your invoice is not improved by delivering rubbish cheaply and generating it four times.

One click is not necessarily one call

Your cheerful “Generate” button can trigger an initial answer, a second model checking it, a third formatting it, a search tool and another call explaining the search results. An agent may loop until it thinks the job is done. A retry may run when an upstream response fails. A workflow can be entirely legitimate and still possess the appetite of a municipal incinerator.

Chat history matters too. If your app resends the full conversation each turn, the next request pays to process earlier material again, unless applicable caching or another supported approach reduces that cost. A long conversation can therefore become more expensive turn by turn. The little input box is not the invoice. What your server actually sends is the invoice.

“Give me a short answer” in a prompt is a preference, not a dependable spending ceiling. Configure supported output limits, bound input sizes and conversation context, and put explicit limits on tool steps and retries. Where a model requires a particular reasoning or output budget, respect its actual API contract. Wishful prose is not financial control.

Here is the maths. It is not a prediction. It is a warning.

A deliberately hypothetical example: suppose you attract 1,000 daily users, each requests ten generations, and each generation costs an average of $0.02 in metered AI usage. That is 10,000 generations and $200 per day. Over thirty equally busy days, $6,000. No attack. No stolen key. No viral catastrophe. Just people accepting your invitation.

Suppose that same workload averages $0.20 per generation instead, because the task, model, context or media requirements are more expensive. Now it is $2,000 per day and $60,000 over thirty days. These are invented unit costs to demonstrate the multiplication, not quoted prices for a named model, forecasts for your app or claims about anyone’s actual bill. Infrastructure, payment fees, tax and support are not included. The arithmetic is already sufficiently rude without adding the rest.

Now try your own numbers: useful completed tasks per customer, actual calls per task, actual input and output usage, applicable model rates, and the usage distribution across customers. Include free users and failed or repeated work. Average cost alone can hide the few heavy users who consume most of the allowance. Your £9 subscription does not acquire magical elastic properties because you put “powered by AI” underneath it.

An alert is not a cap. A cap-shaped label may not be a cap either.

This is the section you should read before launching, rather than afterwards through a veil of tears. Different providers use words such as “budget”, “limit” and “threshold” for different things. An email at a threshold is not a refusal of the next request. It is a polite announcement that the horse has approached the stable door. Sometimes it has already booked an Uber.

Lovable’s paid-plan Usage limits & alerts lets workspace owners and admins choose an alert, blocking, or both. Set the right scope and credit category: a member’s building limit is not a limit on visitors consuming your app’s AI. An AI limit for one project is not automatically a limit on every external provider account you have connected. A low-balance alert does not block anything. Choose an actual blocking rule where you need a stop, and review automatic top-ups separately. More credits arriving automatically is helpful right up until the thing you wanted stopped receives another tank of fuel.

For direct OpenAI accounts, check the precise billing control available to your organisation and project. Current documentation distinguishes usage limits, enforced spend limits and exhausted prepaid balances; do not assume every number labelled “budget” has identical enforcement. Its documentation also warns that changes to enforced limits can take time to apply. Anthropic similarly distinguishes monthly spend limits from request-rate limits, and the available controls and management interfaces depend on your account and product. Provider-specific documentation beats remembered advice from a stranger with an anime avatar.

A request-rate limit controls the pace of consumption. A spending limit controls a financial allowance. Twenty expensive requests a minute can still cost a fortune over a month. A monthly cap can still disappear in the first morning. You usually need several layers, not one very reassuring number. And you must test what happens when the allowance is reached: does the app stop before making another call, or does it merely apologise afterwards?

The controls belong on the server, not in a promise

A disabled button is useful feedback. It is not where the spending permission should live. The service that actually authorises the paid model call must check the user’s entitlement and remaining allowance before starting that work. This is not an accusation that your visitors are attackers. It is basic accounting: the till decides whether a purchase is authorised, not the customer’s screen.

If several jobs start at once, they can all see the same “remaining credit” unless your app reserves allowance consistently before dispatch. A careful implementation reserves a bounded amount, records the actual result, and reconciles the reservation, including failures. That matters for perfectly ordinary parallel uploads as much as anything else. Fifty open tabs do not need to be sinister to expose bad arithmetic.

• →Per-user allowances: finite daily or monthly usage, with smaller trials and explicit paid-plan entitlements. Sign-in provides identity; your own rules must provide the allowance.
• →Per-task boundaries: cap accepted input, enforce supported output limits, and limit batch size, expensive media options, tool steps and retries. One button should not quietly authorise unlimited downstream work.
• →Project and workspace stops: configure actual blocking spend rules where available, plus early alerts and reviewed top-up settings. Leave headroom for work already underway and documented enforcement delays.
• →An emergency off switch: stop new paid work without taking the entire website down. Visitors should get a clear “allowance reached” message, not an endless spinner or a retry storm.

These are design requirements, not a claim that your particular app already implements them. Ask your builder to show where each is enforced, then verify it with a deliberately tiny test allowance. “I added usage limits” is not evidence. A request rejected before another paid job starts is evidence. Do not test the ceiling by letting the public find it on your behalf.

“Unlimited” is a marketing department declaring war on arithmetic

If you buy a metered resource and sell unmetered access, you have accepted a risk. You may consciously accept it after measuring usage and building adequate margin. Streaming services and gyms live with usage distributions too. But a tiny new AI app with three customers and no data has not discovered sophisticated subscription economics. It has guessed, and put the guess on a credit card.

Sell a finite amount of valuable work, with understandable limits and optional paid overages where appropriate. A customer does not need a lecture about tokens. They need to know whether their plan includes twenty document reviews or two hundred, what counts as a review, and what happens when they use them. Be clear about failure, retries and refunds. Do not advertise unlimited and then quietly punish anyone who believed you.

In our previous article, “The App Was The Easy Part”, we discussed monetisation, acquisition costs and whether anyone needs what you built. This is the companion problem: even if people want it and even if they pay, you can lose money fulfilling the thing you sold. Product-market fit is not a dispensation from supplier invoices. Your product can be successful and your finances can be on fire at the same time.

What to measure before calling this a business

Track cost per successfully completed customer task, not just cost per API call. Track free and paying customers separately. Look at the expensive end of the usage distribution, not only the average. Record which model and configuration performed the work, the billable quantities, repeated attempts, tool charges and whether the result was useful. Provider or platform usage views help; reconcile them with your app’s own task records rather than assuming every invoice line maps neatly to one click.

Then calculate contribution margin: the revenue attributable to the customer or plan, minus the variable costs of serving it. AI is one of those costs, not all of them. Payment fees, hosting, storage and delivery can join the queue. Customer acquisition is another cost to recover over the relationship. Do this before deciding your £9 subscription is “basically all profit” because AI wrote the code.

Caching an unchanged result can avoid repeat generation where privacy and freshness permit. Shorter, relevant context can reduce unnecessary input. Good interfaces can prevent accidental duplicate submissions. Those are candidates, not guaranteed savings percentages. Measure equivalent successful work before and after. Do not announce that you have cut costs by 80% because a prompt now says “be concise”.

Before you publish, answer these without saying “probably”

• →Who actually pays for the AI call: my Lovable workspace, a directly connected provider account, or the user’s independently billed account?
• →What is the maximum allowance for one free user, one paying user, one job and the whole app?
• →Which setting actually blocks new spending, which merely notifies me, and is auto top-up replenishing the account?
• →What does my real workload cost per successful task, including history, reasoning, tools, failed attempts and retries?
• →Why did I choose this model? What representative tests show that its extra cost delivers something my customer needs?
• →What happens when limits are reached? Have I verified the stop with a small test budget and checked concurrent jobs?
• →Does the price cover the people who use the product enthusiastically, not just the ones who pay and forget to log in?

The stranger is not the villain

The person generating their seventeenth cover letter has not stolen from you. The teacher making tomorrow’s worksheets has not compromised your infrastructure. The customer refining an image is not mounting a sophisticated exploit. They are doing precisely what your interface, your allowances and your marketing told them they could do.

You wanted a popular app. You forgot to decide how much popularity you could afford. Then the app became popular enough to make the omission visible. That is not an AI safety scandal. It is a business decision you failed to notice you were making.

Connecting AI in Lovable can take minutes. Designing a sustainable service requires a little longer than “make it work” followed by “make the button nicer”. Set the allowances. Choose the model deliberately. Put a real stop on expenditure. Price the work you deliver. Then publish. Otherwise you have not democratised software. You have democratised access to your wallet.

Sources and billing caveats

Researched 31 October 2026. Billing controls and model prices change; check the documentation for your actual account. The dollar examples above are explicitly hypothetical, not measured Lovable usage or current model price quotes. No claim is made about this site’s own spending, limits or payment arrangements.

• →Lovable — AI features for your app: https://docs.lovable.dev/features/ai
• →Lovable — Credits and usage: https://docs.lovable.dev/introduction/credits-and-usage
• →Lovable — Usage limits and alerts: https://docs.lovable.dev/features/usage-limits-and-alerts
• →Lovable — Low credit balance and out-of-credits recovery: https://docs.lovable.dev/introduction/out-of-credits
• →OpenAI — API usage and spend limits: https://help.openai.com/en/articles/6614457-troubleshooting-api-usage-and-spend-limits
• →OpenAI — API rate limits and billing errors: https://help.openai.com/en/articles/5955604-troubleshooting-api-rate-limits-and-429-errors
• →OpenAI — Model and tool pricing: https://developers.openai.com/api/docs/pricing
• →Anthropic — Rate limits and spend limits: https://platform.claude.com/docs/en/api/rate-limits
• →Anthropic — Thinking and billable tokens: https://platform.claude.com/docs/en/build-with-claude/thinking