---
title: "How to Add an AI Chatbot to a Lovable App"
description: "Add an AI chatbot to a Lovable app: built-in AI or your own key, where the key lives, a system prompt, a per-user usage cap and a worked monthly cost estimate."
canonical_url: "https://builderscamp.com/guides/tools/add-an-ai-feature-to-a-vibe-coded-app"
date_published: "2026-10-26"
date_modified: "2026-10-26"
author: "Ricardo Luiz"
publisher: "Builders Camp"
guide_class: "tools"
---

# How to add an AI chatbot feature to an app built with Lovable

**TL;DR:** You can add an AI chatbot to a Lovable app with one prompt in the project chat: the built-in AI connector writes the backend function, manages the API key and bills your workspace credits, with no provider account. Bring your own provider key in an edge function only when you want the provider to bill you or need a model Lovable does not offer. Either way, write the system prompt first, cap usage per user, and check the monthly cost before you publish.

Adding an AI chatbot to a Lovable app takes one prompt in the project chat, because Lovable's [built-in AI connector](https://docs.lovable.dev/features/ai) writes the backend function, manages the project's API key and sets up streaming replies. Lovable's documentation says the connector "adds AI features to your app without a provider account, API keys, billing setup, or model code of your own".

The prompt is the easy part. What decides whether the feature survives real users is what you put around it: the instructions the model follows, a cap on how much one person can use it, and a cost check before you publish. Lovable bills these calls as AI gateway usage, and its [AI features docs](https://docs.lovable.dev/features/ai) describe a temporary offering in which "Free, Pro, and Business workspaces receive a 4-credit monthly AI grant" before requests draw from general credits.

This guide builds one feature end to end: a help assistant inside a small class-booking app for a pilates studio, where signed-in members keep asking the same questions about cancelling and class credits. The app and its numbers are an illustration, not a real product.

## Should you use Lovable's built-in AI or your own API key?

Lovable's built-in AI connector is the right default for a first chatbot, because it removes the two jobs non-developers most often get wrong: creating a provider key and keeping it out of the browser. Lovable's [AI docs](https://docs.lovable.dev/features/ai) say the AI calls "run through a secure backend function that Lovable creates for you, which keeps your credentials and prompts server-side."

Your own key makes sense in two cases, and the [AI features FAQ](https://docs.lovable.dev/features/ai) names both. If the model you need is not offered, its FAQ says to "call that provider directly from a backend edge function using your own API key stored as a secret". If you want usage billed to your provider account instead of your workspace credits, the same page says that usage "is billed by the provider, and your app only consumes Cloud usage for running the function".

| Question | Built-in AI connector | Your own provider key |
|---|---|---|
| Who holds the key | Lovable generates and manages it per project | You create it with the provider and store it as a Lovable secret |
| Who bills the model calls | Your Lovable workspace, in credits | The provider, on your own account |
| Where you see each request | More, then AI, in the project | Lovable's edge function logs, plus whatever usage view your provider offers |
| Models available | The models in Lovable's chat model tables | Whatever the provider's API offers |
| Best for | A first chatbot, a prototype, a small app | A model Lovable lacks, or spend you want on one provider bill |

Pick the built-in route unless one of the two cases applies. Switching later means asking Lovable to call the provider from a backend edge function with your key stored as a secret, which the [AI features FAQ](https://docs.lovable.dev/features/ai) describes as the own-key route.

## What happens between a user's message and the model's reply?

Every chatbot message makes the same round trip: the browser sends the message to your backend function, the function adds your instructions and calls the model, and the reply streams back to the chat panel. Lovable's [edge functions docs](https://docs.lovable.dev/features/edge-functions) list "AI-powered features, such as AI summaries or AI chatbots" among the common uses for these functions, which run on Lovable's servers rather than in the user's browser.

The detail that changes your cost is memory, or rather the lack of it. Anthropic's [Messages API docs](https://platform.claude.com/docs/en/build-with-claude/working-with-messages) state that "The Messages API is stateless, which means that you always send the full conversational history to the API". The model does not remember the last message; your function resends the conversation each time. A ten-message chat therefore sends the system prompt and the earlier messages again on every turn, and input tokens grow with every reply.

Decide how much history to resend before you build. For a help assistant, the last six messages are usually enough context, and a fixed window keeps the cost of a long conversation predictable.

## Which model should a help assistant start on?

Name the model in your prompt, because Lovable's default for chat is a premium-priced model. Lovable's [chat model docs](https://docs.lovable.dev/features/ai-chat) list GPT-6 Astra as the default and describe it as "OpenAI's most capable model for complex reasoning, coding, research, and document creation" before adding that it is premium-priced.

A help assistant that answers from a short help text does not need that depth. Lovable's own [model guidance](https://docs.lovable.dev/features/ai) suggests switching to Gemini 3.8 Flash when "You want faster, lower-cost answers for everyday chat", and to Gemini 3.1 Flash Lite or GPT-6 Luna for high-volume, simple text tasks. Start the pilates app on Gemini 3.8 Flash, write ten test questions, and move up a tier only if the cheaper model gets them wrong.

Two constraints narrow the list. Lovable's [chat model docs](https://docs.lovable.dev/features/ai-chat) say the Claude models are only in newer apps (created from May 13, 2026, which use TanStack Start), so an older React + Vite project picks from the OpenAI and Google tables. Lovable's [AI features page](https://docs.lovable.dev/features/ai) also advises preferring a newer generation when you name a model, because "older generations are the first to reach a retirement date".

## How do you write the system prompt for an in-app assistant?

Write the system prompt before you open Lovable, because it is the part of the feature you own and the part the model follows on every call. The [system prompt glossary entry](https://builderscamp.com/guides/glossary/system-prompt) covers the term; here the job is to make it specific to your app.

Anthropic's [prompting best practices](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices) frame the first rule well: "Think of Claude as a brilliant but new employee who lacks context on your norms and workflows." The same page names the five techniques this prompt uses: be clear and direct, add context, use examples, give the model a role, and be specific about the output format and constraints you want. The advice is written for Claude, but each technique is plain instruction-writing that carries to other models.

```text
You are the help assistant inside Studio Book, a class-booking app for a small pilates studio.

Answer only questions about using Studio Book: booking, cancelling, class credits and account settings.
Use only the help text between the help tags. If the answer is not there, say you do not know and point the member to the studio email shown on the Contact page.

Your answers appear in a small chat panel on a phone, so keep each answer under 80 words, in plain sentences, with no tables.
Never promise a refund or an exception to the cancellation policy. A person at the studio decides those.

<examples>
Member: How do I cancel tomorrow's class?
Assistant: Open My bookings, tap the class, then tap Cancel booking. Cancellations more than 12 hours before the class return the credit to your account.

Member: Can you suggest a stretching routine?
Assistant: I can only help with using Studio Book. For training advice, ask your instructor at your next class.
</examples>

<help>
Paste the studio's help text here.
</help>
```

Each line maps to one technique. The first sentence sets the role, the second and third are clear and direct about scope, the phone-panel line gives context for the length rule, the refund line is a constraint, and the two examples show the model both a normal answer and a polite refusal. The 12-hour rule inside the example is the illustrative studio's policy, so replace it with your own.

## How do you ask Lovable to build the help assistant?

Paste one prompt that names the model, the instructions, the history window, who may call the feature and the usage cap. Lovable's [AI features docs](https://docs.lovable.dev/features/ai) say to "Describe the feature in the project chat, the same way you ask for any other change", and this works in an app you have already built.

```text
Add a help assistant to the app: a chat panel on every signed-in page that answers questions about using the app.
Use the built-in AI connector with Gemini 3.8 Flash and stream the replies.
Use the system prompt below as the assistant's instructions.
Send only the last 6 messages of the conversation with each request.
Only signed-in users can use the assistant. Check the user in the backend function, not in the browser.
Limit each user to 20 questions per day. Store the count in the database, check it in the backend function, and show a short message when the limit is reached.
Show a clear error message if the AI request fails or the workspace is out of credits.

[paste the system prompt here]
```

The sign-in check matters even though the call already runs on the server. Lovable's [security best practices](https://docs.lovable.dev/tips-tricks/security-best-practices) warn that "A function running on the server is still callable by a client, so server-side execution alone does not make the operation private." Without the check, anyone who finds the function's URL can spend your credits.

## How much will the chatbot cost per month?

Estimate the bill from requests, input tokens and output tokens before you publish, then compare it with what the AI dashboard shows after a week. The usage below is an assumption for the pilates app: 400 members use the assistant, each asks 15 questions a month, and each request sends 2,500 input tokens (the system prompt and help text, plus the question and the last six messages) and gets back 300 output tokens. That is 6,000 requests, 15 million input tokens and 1.8 million output tokens a month.

For the own-key route, Anthropic's [pricing page](https://platform.claude.com/docs/en/about-claude/pricing) lists Claude Haiku 4.5 at $1 per million input tokens and $5 per million output tokens, Claude Sonnet 5 at $2 and $10, and Claude Opus 5.5 at $4 and $20.

| Model | Input cost (15M tokens) | Output cost (1.8M tokens) | Monthly total |
|---|---|---|---|
| Claude Haiku 4.5 | $15 | $9 | $24 |
| Claude Sonnet 5 | $30 | $18 | $48 |
| Claude Opus 5.5 | $60 | $36 | $96 |

The spread is the point: the most capable model in this table costs four times the cheapest for the same help questions. The estimate has two limits. First, it counts tokens as if every model counted them the same way, and Anthropic's [pricing page](https://platform.claude.com/docs/en/about-claude/pricing) notes that Claude 4.7 and later models use a newer tokenizer that "produces approximately 30% more tokens for the same text". Second, it covers the own-key route only. On the built-in route, Lovable's [AI docs](https://docs.lovable.dev/features/ai) say "Credit usage depends on the model used and the amount of work performed" and that "AI gateway usage rates are based on the underlying provider model costs", so read the real figure from the More, then AI dashboard after your first week.

What the estimate still shows is where the money goes. Input is most of the bill, so a shorter help text and a fixed history window cut cost more than shorter answers do. The [LLM cost estimation guide](https://builderscamp.com/guides/other/how-to-estimate-llm-costs-for-a-feature) covers caching and model routing once the feature has real traffic.

## How do you stop one user from running up the bill?

A per-user daily cap is the control that matters, because Lovable's own limits apply to the whole workspace, not to each of your users. Lovable's [AI docs](https://docs.lovable.dev/features/ai) say "The built-in AI connector applies rate limits per workspace" and that requests over the limit get a `429 Too Many Requests` response, while a workspace out of credits gets `402 Payment Required`.

Run the numbers on one bad actor. A script that sends 10,000 requests at 2,500 input and 300 output tokens each would cost $80 on Claude Sonnet 5 at the prices above, more than the whole month for 400 honest members, and on the built-in route it would also burn the shared credits every other feature depends on. A cap of 20 questions a day limits one account to about 600 requests a month, and the sign-in check stops anonymous calls entirely.

Three controls belong in every chatbot you publish:

- **A sign-in check inside the backend function**, so only your users can call it.
- **A daily question cap per user, counted in the database**, so one account cannot spend the month's budget.
- **A fixed history window**, so a long conversation does not resend an ever-growing transcript.

## Where should the API key live if you bring your own provider?

A provider key belongs in Lovable's Secrets, never in frontend code or a `VITE_` variable. Lovable's [Secrets docs](https://docs.lovable.dev/features/secrets) say secrets "are encrypted, injected into your Edge Functions automatically, and never reach the browser", and that anything prefixed with `VITE_` is a "build-time, browser-exposed" value. The [security best practices page](https://docs.lovable.dev/tips-tricks/security-best-practices) is blunt about the alternative: "Secrets stored in frontend code are visible to users and should be considered compromised."

Let Lovable ask for the key through its secure form instead of pasting it into a chat message:

```text
Switch the help assistant from the built-in AI connector to the Anthropic Messages API, called from a backend edge function, using Claude Haiku 4.5.
Ask me for the API key and store it as a secret named ANTHROPIC_API_KEY. Never put it in frontend code or in a VITE_ variable.
Keep the sign-in check, the 6-message history window and the 20-questions-per-day limit.
```

Secrets are write-only once saved, so Lovable shows the name but never the value again; if you lose a key, generate a new one with the provider. The [vibe coding security checklist](https://builderscamp.com/guides/tools/vibe-coding-security-checklist) covers how to check a published app's JavaScript for a leaked key.

## Should you call a provider directly or go through a router like OpenRouter?

A router earns its place when you bring your own key and want to compare providers without rewriting the edge function each time. [OpenRouter's FAQ](https://openrouter.ai/docs/faq) says it "provides a unified API to access all the major LLM models on the market", and on cost, "We pass through the pricing of the underlying providers; there is no markup on inference pricing", though it charges a fee when you purchase credits.

For a first chatbot in Lovable, skip the router. The built-in connector already lets you switch between OpenAI, Google and, in newer apps, Anthropic models with one prompt, which is the main job a router does. Reach for OpenRouter or a direct provider once usage is high enough that you want the bill on your own account, and see the [LLM API comparison](https://builderscamp.com/guides/tools/best-llm-apis-for-builders) for how the main providers differ.

## What should the first test of the chatbot prove?

The first test should prove the assistant refuses, caps and fails correctly, not only that it answers. Run these five checks on the preview before you publish:

1. Ask a question the help text answers, and confirm the reply matches the help text.
2. Ask something off-topic, and confirm the assistant declines in one or two sentences.
3. Ask the 21st question of the day from one account, and confirm the cap message appears.
4. Sign out and call the assistant, and confirm the backend function rejects the request.
5. Open More, then AI, and confirm each test request shows its status, model and cost.

Lovable's [AI docs](https://docs.lovable.dev/features/ai) note that "Lovable always records this summary for every AI request, even when the request content is not available", so the dashboard is a reliable place to check spend even with full request capture turned off. If a call fails, the [edge functions docs](https://docs.lovable.dev/features/edge-functions) say View logs opens the logs filtered to that function, with the error output for each failed invocation. Then publish, because the published app gets the feature only after you publish your changes. Turn the ten test questions into a small eval set you rerun after every prompt change; [writing evals for AI products](https://builderscamp.com/guides/tools/how-to-write-evals-for-ai-products) shows how.

## When is a chatbot the wrong AI feature for your app?

A chatbot is the wrong choice when the job is a decision your app should act on, not a conversation. If you want to tag incoming messages as urgent or route them to the right person, Lovable's [AI docs](https://docs.lovable.dev/features/ai) describe a typed decision model, Jev 1.13, that "returns a category, score, or yes/no probability instead of generated text", which your code can act on directly.

The honest limit of the built-in route is control. Your workspace credits, rate limits and model list are Lovable's, and per Lovable's [AI docs](https://docs.lovable.dev/features/ai) the AI app context setting keeps full requests and responses for 90 days by default on Free and Pro plans, so check that against what your users type before you launch. For a help assistant in a small app, those trade-offs are usually worth it; for a feature that handles sensitive data, decide on the setting first.

## Where can you practise wiring AI into an app you built?

[Using AI to Build Your First Product](https://builderscamp.com/bootcamps/using-ai-to-build-your-first-product) is a two-week Builders Camp bootcamp, with 4 live sessions and 9 self-paced microlessons, for designing, prototyping and shipping a real product with Claude Code and AI-assisted building tools, from idea to launched MVP. Its syllabus names Claude Code, Lovable, Replit, Databutton and Stripe among its tools, and it is part of the Vibe Coding Expert Track. If you want to go deeper on Lovable itself first, [Building with Lovable](https://builderscamp.com/bootcamps/building-with-lovable) is a two-week bootcamp, with a beginner-rated practical challenge, 3 live sessions and 9 microlessons, that takes you from idea to an interactive full-stack prototype with Lovable, Supabase and GitHub, with no coding required. For the payment side of the same app, see [adding Stripe to an AI-built app](https://builderscamp.com/guides/tools/add-stripe-payments-to-an-ai-built-app).

## Frequently asked questions

### Do I need an OpenAI or Google API key to add a chatbot to a Lovable app?

No. Lovable's built-in AI connector generates and manages a LOVABLE_API_KEY for each project, so you do not create a provider account, set up billing with a model provider or paste a key into your app. You need your own key only if you call a provider directly from an edge function.

### Which model does Lovable use for a chatbot if I do not name one?

Lovable's chat model docs list GPT-6 Astra as the default and describe it as premium-priced. For an everyday help assistant, name a cheaper model in your prompt: Lovable suggests Gemini 3.8 Flash for faster, lower-cost everyday chat, and Gemini 3.1 Flash Lite or GPT-6 Luna for high-volume, simple text tasks.

### Can a Lovable app use Claude models for its chatbot?

Yes, in newer apps. Lovable's docs say the Claude models are added to apps created from May 13, 2026, which use TanStack Start, and that older React + Vite apps use the other chat models. On Enterprise plans an admin first has to enable extended-retention models.

### What happens to my chatbot when the Lovable workspace runs out of credits?

AI requests return a 402 Payment Required status code and the chatbot stops answering until you add credits or turn on auto top-up in workspace settings. Requests above the workspace rate limit return 429 Too Many Requests. Build a friendly error message for both before you publish.

### Can I use my own API key so the chatbot does not use Lovable credits?

Not with the built-in AI connector, which always bills workspace credits. Ask Lovable to call the provider's API from a backend edge function with your key stored as a secret instead. The provider then bills the model usage, and your app only uses Cloud usage for running the function.

### Where can I see what each chatbot request cost?

Open More, then AI, in your project. The dashboard shows credits used, request count, success rate and average time, plus each request's status, model and cost. Free workspaces can view the last 24 hours of activity and paid plans the last 90 days.

### Does Lovable keep the messages my users send to the chatbot?

With the AI app context setting on, Lovable keeps the full request and response for each AI call for 90 days, with secrets removed automatically. The setting is on by default on Free and Pro plans and off by default on Business and Enterprise plans, and you can change it in project settings.

### Do Lovable chatbot replies stream word by word?

Yes. The built-in AI connector supports streaming with server-sent events, and Lovable sets up streaming for chatbot and assistant features so replies appear piece by piece as they are generated instead of all at once.

## Sources

- [Lovable Docs: AI features for your app](https://docs.lovable.dev/features/ai)
- [Lovable Docs: Add chatbots and text generation to your app](https://docs.lovable.dev/features/ai-chat)
- [Lovable Docs: Secrets](https://docs.lovable.dev/features/secrets)
- [Lovable Docs: Edge functions](https://docs.lovable.dev/features/edge-functions)
- [Lovable Docs: Security best practices for Lovable apps](https://docs.lovable.dev/tips-tricks/security-best-practices)
- [Anthropic Docs: Pricing](https://platform.claude.com/docs/en/about-claude/pricing)
- [Anthropic Docs: Using the Messages API](https://platform.claude.com/docs/en/build-with-claude/working-with-messages)
- [Anthropic Docs: Prompting best practices](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices)
- [OpenRouter Docs: FAQ](https://openrouter.ai/docs/faq)

## How this guide was made

Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.