Lovable app with OpenRouter: AI launch checklist
Lovable apps call OpenRouter with your own API key, from server code, so OpenRouter's own limits are your safety net. Of the 20 checks before you charge users, Lovable handles 1, partly handles 5, and leaves 14 to you.
Checked 12 Nov 2026 against each platform's docs; every fact links to its source.
How AI calls work in Lovable
- Built-in AI
- Yes: Lovable AI, a built-in connector that adds chat, summaries, images, video, music, search, speech and more without a provider account, API keys or billing setup. It is separate from the Lovable agent that writes code.
- How calls run
- AI calls go through a backend function Lovable creates, keeping credentials and prompts server-side (the page calls this 'AI gateway usage'). Exception: live voice streams audio from the browser directly to the voice model, while the server starts the call and holds the key. Chat streams via SSE.
- API keys
- Lovable generates and manages a LOVABLE_API_KEY per project; you never create it. Remixed projects get a fresh key.
- Who pays
- Your Lovable workspace. AI usage in deployed apps consumes workspace credits ('Run credits'), priced by model and work (tokens, images, video seconds, tracks, audio, voice time). Free, Pro and Business workspaces get a temporary 4-credit monthly AI grant that is used first and does not roll over; then general credits. Priority processing costs more; canceled requests may still be billed; live voice has a 15-second minimum.
- Your own key
- The built-in connector always runs through Lovable and bills credits; it can't use your own OpenAI/Anthropic/Google key. To use your own key, have Lovable call the provider from an edge function with the key stored as a secret; the provider bills you and only the function's Cloud usage hits credits.
- When credits run out
- Lovable AI returns 402 Payment Required; app AI features fail with an error and Lovable shows no message for the failed calls themselves.
Keys and secrets
- Where secrets live
- Lovable Cloud: More menu → Secrets ('Store API keys and other sensitive values securely'). Lovable detects API keys pasted into the project chat and guides you to Secrets.
- Server-side by default?
- Yes for Lovable AI (backend function). For BYOK, only if the call is in an edge function.
- How keys end up in the browser
- Putting a provider key in frontend code instead of Secrets; Lovable's own docs say 'API keys and other secrets cannot be stored safely in client-side code.' Separately, a 2026 Lovable API flaw exposed hardcoded Supabase credentials in pre-November-2025 projects (see commonMistakes).
- Secret scanning
- Quick scan runs on every publish (database review, dependency audit, MCP check); Deep scan (manual) checks leaked secrets, unauthenticated endpoints, access control.
The 20 checks, in Lovable
What Lovable does for you, and what to ask it (or your coding agent) to add. Tick them off in the interactive checklist.
Cost and abuse
- Partly
A spending cap per user
Usage limits & alerts can pause AI for a whole project, not one user, so ask Lovable: 'Create a Cloud table ai_usage (user_id, day, credits_used) and, in the edge function that calls Lovable AI, sum today's credits for the signed-in user and return a daily-limit error before calling the model when it's over the cap.'
- Partly
Rate limits on every AI endpoint
Lovable AI only limits requests per minute per workspace, so ask Lovable: 'Add a rate_limits table (key, window_start, count) and check it at the top of every edge function that calls AI, keyed by user id or IP, returning 429 after 10 calls a minute.'
- Handled
AI keys only on the server
With Lovable AI the LOVABLE_API_KEY lives only in the backend function; if you add your own OpenAI, OpenRouter or fal key, paste it into More → Secrets, keep the call in an edge function, and run a Deep scan for leaked secrets.
- You add it
Retries capped, with a timeout
Ask Lovable: 'In each AI edge function add a 30-second timeout and at most 2 retries with backoff, only on 429 and 5xx, never on 402 (out of credits) or other 4xx, and remove any retry in the React code.' Lovable notes canceled requests may still be billed.
- Partly
A budget alert at each AI provider
For Lovable AI your provider is your Lovable credit balance: set an AI or Run limit with 'Pause AI' and the 80% warning in Usage limits & alerts, and a monthly spend limit on auto top-up; for any BYOK provider also set a limit in that provider's dashboard.
Charging for AI use
- You add it
Every AI call charged or deliberately free
Ask Lovable: 'List every edge function and Job that calls Lovable AI or another provider, including Jev classification, embeddings and transcription, and mark each one as charged to the user or free on purpose.'
- You add it
Credits deducted on the server, after success
Ask Lovable: 'Create a user_credits table with an RLS policy that lets users read but never update their own row, and a database function that the AI edge function calls with the service role to deduct credits in the same transaction as inserting the ai_results row.'
- You add it
Failed AI calls refunded
Ask Lovable: 'If the AI call returns 429, 402, times out, or gives an empty reply or invalid JSON, release the reserved credits, insert a credit_refunds row with the reason, and tell the user they weren't charged.'
- You add it
One charge per request, even on a double click
Ask Lovable: 'Generate a request_id per click, add a unique index on ai_results.request_id, have the edge function return the existing row on a repeat instead of calling AI again, and disable the button while it runs.'
A record of every AI result
- Partly
Each AI result stored with its feature, model, prompt version and settings
More → AI shows each run's model and credits but not your user or prompt version, so ask Lovable: 'Create ai_results (id, user_id, feature, model, prompt_version, params jsonb, input, output, credits, request_id, created_at) and insert a row from the edge function for every AI call.'
- You add it
Retries and corrections saved next to the original, never over it
Ask Lovable: 'When a user regenerates or edits an AI result, insert a new ai_results row with parent_id, version and edited_by; never update the original; show the latest version by default.'
- You add it
What users do next with each AI result, recorded on the server
Ask Lovable: 'Create ai_events (result_id, user_id, type, created_at) and an edge function log-ai-event called from the Retry, Undo, Edit, Copy, Send and Export buttons, with RLS so users can only insert their own events.'
What worked, for whom, at what cost
- You add it
Worked first time, per feature, model and prompt version
Ask Lovable: 'Create a SQL view of worked-first-time by feature, model and prompt_version for 7 and 30 days, and an admin-only page that shows it with result counts.'
- Partly
A cost record for every AI step
Lovable AI bills in credits and the More → AI list shows credits per run, but not per user or step, so ask Lovable to save step name, model, credits and the reported usage in an ai_costs row after every call, retries included.
- You add it
Wasted AI spend and real cost per result, per feature
Ask Lovable: 'Add an admin page that joins ai_costs to ai_events and shows, per feature and model for 30 days, total credits, credits spent on results that were retried, undone or edited, and credits per result that worked.'
- You add it
Who the AI fails for
Ask Lovable to save input_language, input_length_band, input_kind, plan and is_new_user on each ai_results row and add a worked-first-time-by-trait table to the admin page.
Switching safely
- You add it
Prompts in version control, with version labels
Ask Lovable: 'Move every prompt string out of the edge functions into one shared prompts file with exported version labels like support_reply@v3, and save the label on each ai_results row.'
- You add it
Model and prompt switchable by a flag
Ask Lovable: 'Store the model id and prompt version per feature in an admin-only app_settings table read by the edge function, with a percentage split assigned by hashing the user id.' Lovable AI lets you swap between its listed models without new keys.
- You add it
Real past requests to replay before a change
Ask Lovable: 'Add an admin-only edge function that takes 50 past ai_results (mixing worked and failed), strips names and emails, re-runs them through a chosen model and prompt version, and saves outputs and credits next to the originals.'
- You add it
A plan for model shutdowns
Ask Lovable to list every model id used across edge functions, move them into one config, and write MODELS.md. Whether Lovable migrates retired Lovable AI models for you: not found in its docs.
OpenRouter limits to set before launch
- Per-key limit
- Key dialog → 'Key limit' → 'Credit limit', reset interval and 'Include BYOK usage in limit' (toggle appears only with BYOK keys configured). API: PATCH https://openrouter.ai/api/v1/keys/{key_hash} with limit (USD), limit_reset (daily, weekly, monthly; unset = lifetime; resets at midnight UTC) and include_byok_in_limit (default false).
- When a key hits its limit
- Conflicting docs: the capping guide says requests fail with 403 'Key limit exceeded'; the limits reference says over-limit requests return 402 with limit_source openrouter_key_limit (or openrouter_guardrail_budget / openrouter_workspace_budget). Test before relying on either.
- Workspace and guardrails
- Workspace budget: one pooled cap for all members and keys. Guardrail budgets: per member or per key, daily/weekly/monthly; 'the first limit reached blocks the request'; the lower of key limit and member guardrail wins.
- Account balance
- Prepaid credits; an 'in-flight spending budget' (a fraction of balance) can fail paid requests with 402 even when balance is positive; a negative balance can error even free models.
- Alerts and top-up
- Low-balance alerts and auto top-up: not found in the pages read.
- Key scoping
- Per-key credit limits and per-key guardrails (model, provider, ZDR and data-region policy). Keys are owned by a member or a workspace; spend is attributed to the key's creator, so per-person enforcement needs one key per person. Management API key can create keys (POST /api/v1/keys).
- Rate limits
- Free model variants (':free'): 20 RPM; 50 requests/day if under 10 credits ever purchased, 1,000/day at 10+. Paid models: 'no platform-level request cap' (upstream provider limits still apply). Key-management endpoints 10,000 requests/day. Cloudflare DDoS protection blocks dramatic excess.
- Where usage shows
- Activity page filters by API key, model, provider and user; export CSV or PDF grouped by Model, API Key or Creator. GET /api/v1/activity (management key, last 30 days) filters by api_key_hash. GET https://openrouter.ai/api/v1/key returns usage, usage_daily, usage_weekly, usage_monthly, limit_remaining and applicable budgets for the calling key.
openrouter.ai ↗openrouter.ai ↗openrouter.ai ↗openrouter.ai ↗
Mistakes Lovable apps make at launch
Tables left readable or writable by anyone (RLS missing or 'USING (true)').
CVE-2025-48757 (CVSS 9.3): insufficient RLS in Lovable-generated sites through 2025-04-15 let unauthenticated attackers read or write arbitrary tables; Matt Palmer found about 170 of 1,645 showcase apps exposed. TNW reports about 70% of those had RLS disabled. A Feb 2026 Lovable-hosted EdTech app with inverted auth logic exposed 18,697 user records.
No per-user rate limit or cap on AI endpoints, so one user or script drains the credit balance; when credits run out, AI features fail for every user with no message.
Lovable AI limits are per workspace, not per user, and return 402 when credits run out; app AI features then fail with an error and Lovable shows no message for failed calls. Third-party write-ups describe the overnight loop-script bill pattern for AI-built apps.
Secrets and credentials hardcoded in the project instead of Secrets.
April 2026: a Lovable API BOLA flaw (open 48 days after a March 3 report) let a free account read other users' source code and hardcoded Supabase credentials in projects created before November 2025. Escape.tech's scan of 5,600 vibe-coded apps (mostly Lovable) found 400+ exposed secrets.
Questions
How do AI calls work in a Lovable app with OpenRouter?
Lovable apps call OpenRouter with your own API key, from server code, so OpenRouter's own limits are your safety net.
Can Lovable cap AI spending per user?
Partly. Usage limits & alerts can pause AI for a whole project, not one user, so ask Lovable: 'Create a Cloud table ai_usage (user_id, day, credits_used) and, in the edge function that calls Lovable AI, sum today's credits for the signed-in user and return a daily-limit error before calling the model when it's over the cap.'
Where should the OpenRouter key live in Lovable?
Handled. With Lovable AI the LOVABLE_API_KEY lives only in the backend function; if you add your own OpenAI, OpenRouter or fal key, paste it into More → Secrets, keep the call in an edge function, and run a Deep scan for leaked secrets.
How do I stop one user running up my OpenRouter bill?
Add a per-user daily cap in your own code, checked before every AI call. Then set a limit at OpenRouter as a backstop: Key dialog → 'Key limit' → 'Credit limit', reset interval and 'Include BYOK usage in limit' (toggle appears only with BYOK keys configured). API: PATCH https://openrouter.ai/api/v1/keys/{key_hash} with limit (USD), limit_reset (daily, weekly, monthly; unset = lifetime; resets at midnight UTC) and include_byok_in_limit (default false).