Free Message Limits for a Chatbot App: Keep LLM Fees Under Revenue

Why one message doesn't have one fixed cost

LLM providers charge per token. A token is a small chunk of text, usually part of a word. You pay for the tokens you send to the model (input) and the tokens it writes back (output). The catch is the input. A chat app sends more than the user's new message. On every turn it sends:

• 1. The system prompt. Your instructions to the model, sent again with every message.
• 2. The conversation history. All earlier messages, so the model remembers the chat.
• 3. Retrieved content. Passages from your own docs, if the bot answers from them.
• 4. The new message.

How the history makes each message cost more

By default, the whole history goes back to the model on every turn. Message 20 carries the 19 before it. So in a long chat, each new message costs more than the one before. Here is an illustration with round token counts. Assume a system prompt of 400 tokens, user messages of 50 tokens and replies of 250 tokens.

• Turn 1. Input tokens sent: 450. Output tokens: 250.
• Turn 5. Input tokens sent: 1,650. Output tokens: 250.
• Turn 10. Input tokens sent: 3,150. Output tokens: 250.
• Turn 20. Input tokens sent: 6,150. Output tokens: 250.

Why the first decision is not the cap

The reply stays the same length, but by turn 20 the input is more than thirteen times bigger than at turn 1. Two free users who both send 20 messages a day can cost you very different amounts. One sends them in 20 short chats, the other in one long chat. That is why the first decision is not the cap. It is how much history you send.

Step 1: Calculate the cost of an average message

Cap the history first. Decide how many previous turns go back to the model. You can send the last few turns, or the last few turns plus a short summary of older ones. Once the history is capped, the input stops growing after a certain turn. That gives you a ceiling for the cost of one message.

Get real token counts

If you have a prototype, use its logs. Most LLM APIs return the input and output token counts in each response, so you can store them per message. If you don't have a prototype yet, write five realistic chats by hand and count them with your provider's tokenizer tool.

Apply the formula

Cost of one message = (input tokens × input price) + (output tokens × output price). Prices change often and differ by model. Take them from your provider's pricing page on the day you plan. Use the input size at your history cap, not at turn 1. That is the cost of a message deep in a chat, and it is the safe number to plan with.

Step 2: Fix the free daily cap

Monthly cost of one free user = cost of one message × daily cap × days they use the app per month. Then multiply by the number of free users you expect to be active. For days of use per month, take your analytics if you have them. If you don't, plan as if heavy users open the app every day. Those users are the ones who reach the cap. Now ask the real question: how much are you willing to spend each month to keep one free user? Treat it like an acquisition budget. Your daily cap is that budget divided by what one heavy user costs per day.

A message cap alone doesn't cap cost

A user can paste a very long text into one message. Three more limits close that gap. All of these must be checked on your server, not only in the app. A limit that lives only in the app can be bypassed by anyone who calls your API directly.

• Max length of a user message. What it stops: huge pasted texts. Where it lives: app and server.
• Max output length per reply. What it stops: very long, expensive answers. Where it lives: the API call.
• Daily token budget per user. What it stops: any mix of the above. Where it lives: your server, checked before each call.
• Messages per minute. What it stops: scripts and bots running up your bill. Where it lives: your server.

Make hitting the limit useful

When a free user reaches the cap, show a clear screen: they've hit today's free limit, when it resets, and a button to upgrade. That screen is where your paid conversions come from, so design it in v1. Halfway through your numbers and want to check them with someone who builds these apps? Book a call.

Step 3: Choose the price of the paid plan

The paid plan has to cover three things:

• 1. The paid user's own LLM cost. Run step 2 again with the paid user's higher cap, or with your fair use limit if the plan is "unlimited".
• 2. Their share of the free users. If you have many free users for every paying one, each paying user covers all of them.
• 3. Store and payment fees. Apple and Google take a commission on in-app subscriptions. Stripe takes a fee on web payments.

The paid plan worksheet

Net revenue per paid user > paid user LLM cost + (free user cost × free users per paid user) + other running costs per user. Use this worksheet to fill it in:

• Cost of one message. Where to find it: step 1.
• Free user monthly cost. Where to find it: step 2.
• Paid user monthly cost. Where to find it: step 2 with the paid cap.
• Free users per paying user. Where to find it: a cautious guess at launch, then your real data.
• Net price after store fees. Where to find it: our App Store fee calculator.
• Monthly revenue at a given number of subscribers. Where to find it: our app revenue and MRR calculator.

Revisit the cap and the price together

At launch you won't know how many free users each paying user will cover. Start with a cautious guess, then replace it with real numbers after your first weeks. Revisit the cap and the price together. They are one decision.

When the numbers don't work

If the paid plan would need a price nobody will pay, change the cost side before you change the price:

• Serve free users on a smaller model. Keep the larger one for paid users or hard questions.
• Send less history. Fewer turns, or a summary instead of full messages.
• Shorten the system prompt. It is paid on every single message.
• Use prompt caching where your provider offers it. Repeated input, like the system prompt, is billed at a lower rate.
• Cap reply length lower. Output tokens usually cost more than input tokens.
• Narrow the bot's job. A bot with one clear job gives shorter answers than a general assistant.

Give the bot a source of truth

Our AI chatbot MVP page puts the scoping rule plainly: "If you cannot point at a corpus, you are shipping a personality." A bot with a defined source of truth is easier to keep short, accurate and cheap. For the full cost breakdowns of AI products, from the LLM bill to evals and guardrails, see our feature cost guides.

Build the limits into v1

Usage limits are not a feature for later. In a consumer chatbot, they decide whether your first viral week is a good week or a big bill. A v1 needs a per user counter on the server, the token and length limits above, the upgrade screen and working payments. Our MVP Development package covers the base of the app: auth and onboarding, iOS, Android and the web, Stripe payments, the database, design and store submission help. It is Fixed at $3,460 and delivered in about 20 days, with progress shown every week. AI features like the LLM integration and usage limits are custom scope, and the quote is fixed and given before we start. The code is 100% yours, on your GitHub, with 2 weeks of fixes after launch. Already have a chatbot prototype from an AI builder? Our AI prototype to production service hardens it for a real launch.

How many free messages should a chatbot app give per day?

There is no standard number. It depends on the cost of one message in your app and how much you will spend per month to keep a free user. Calculate the cost of a message at your history cap, then divide your budget per free user by that cost and by the days they use the app.

Why does my LLM bill grow faster than my number of users?

Because a chat resends its history with every message. Long chats cost more per message, not just in total. Capping the history is the fix.

Should I limit messages or tokens?

Both. A message cap is easy for users to understand, so show that one. A daily token budget per user, checked on your server, is what actually caps your cost, because one long message can cost as much as many short ones.

Can I offer an unlimited paid plan?

You can call it unlimited, but set a fair use limit on the server. Without one, a single heavy user can cost more than their subscription brings in. Want these limits built into your chatbot app from day one? Book a call. It's a free 30 minute call.