How to build a WhatsApp chatbot with a Rp50,000 token budget

WhatsApp chatbots for small businesses are among the most frequently requested projects, and among the ones that most often turn into cost drama. Not because the API is expensive, but because there are no brakes: one buggy loop or one group that keeps triggering replies can drain the balance overnight.

This article covers the correct architecture from the cost side: the inbound webhook, one API key with a budget limit, and a simple calculation of how many replies Rp50,000 buys.

The minimal correct architecture

WhatsApp -> WA gateway -> your server (webhook) -> AI API -> reply

Three components, one principle: every rupiah of usage passes through one control point.

WhatsApp gateway: the service connecting the WA number to the webhook (common examples: WPPConnect, Baileys, or a commercial gateway). This part is not an AI cost; keep it separate in your math.
Your webhook server: receives messages, builds the prompt, calls the AI API, sends the reply. One Node/Python file is enough.
AI API with a budget limit: the heart of the chatbot, and the only source of variable cost per reply.

Why the per-key budget limit is the heart of it

A chatbot runs unsupervised, that’s the point. But “unsupervised” also means nobody is pressing Ctrl+C when something weird happens. The patterns that blow up a balance usually look like this:

Two users replying to each other through the chatbot (a bot-to-bot loop).
A badly prepared prompt making the model produce very long answers to short messages.
A logic bug making the server call the API repeatedly for one message.

The structural fix is not “be careful”, but a key with a budget limit. At Giant Router, you set a usage limit on the chatbot’s key (say Rp50,000). When usage touches the limit, requests stop. The chatbot being offline for a while is not an emergency; a negative balance (if it happened) would be. We wrote the “balance will not go negative” contract in the Balance Guarantee.

And if you run chatbots for several clients, the correct pattern is one key per client, one budget per key; each client’s cost is separate and can be attached to an invoice. The full guide is at billing clients for AI API usage.

Worked example: how many replies from Rp50,000? (illustration)

Take the cheapest flash-class model in the reference catalog: glm-5.3-flash, reference price $0.015 per million input tokens and $0.25 per million output tokens (public demo catalog snapshot 2026-11-08).

Worked example: an illustration, not a real measurement.

Assume one chatbot reply uses on average 1,000 input tokens (short history + system instructions) and 200 output tokens (a normal answer):

Input: 1,000/1M x $0.015 = $0.000015
Output: 200/1M x $0.25 = $0.00005
Total per reply: $0.000065 ≈ Rp1 (display rate Rp16,500/USD)

A Rp50,000 budget ≈ $3.03. So:

Rp50,000 / Rp1 per reply ≈ 46,000 replies

Under those assumptions, Rp50,000 is enough for a chatbot with hundreds of conversations per day for months. Your reality will differ: longer history, longer answers, or a bigger model all shift the number. And that is exactly what the per-request report is for: after the first week you can replace the assumptions above with your chatbot’s real numbers.

What doesn’t change under any assumption: your worst case is Rp50,000. That is the entire point of the budget limit.

An economical (and polite) example system prompt

The two lines that save the most:

Limit answer length in the system prompt (“reply in at most 3 sentences, casual language”); output tokens are the expensive side.
Limit the history you resend (send the last 5 messages, not the whole conversation); input tokens dominate when the history isn’t trimmed.

When the budget is hit, what happens to the user?

This needs an answer at design time, because it’s the client question that comes up most: when usage touches the limit, API requests stop; your chatbot server receives an error from the gateway instead of a model reply. The pattern we recommend:

Catch that error in the webhook and answer the user with a service message: “the service is temporarily unavailable, please contact the owner”; don’t leave messages unanswered.
You (and the client, if needed) can see from the usage report when the limit was reached and because of which conversation.
The extra-budget decision becomes a calm conversation: “this month’s budget was used up within the limit we agreed on; continue with this amount or evaluate first?”, not a billing surprise.

With this pattern, the budget limit is not a system failure; it works exactly as designed: holding back the drama before it happens.

Summary

Architecture: WA gateway -> webhook -> AI API, one cost control point.
One key per client, one budget limit per key; Rp50,000 means the worst case is Rp50,000.
With a flash model and an economical prompt, Rp50,000 covers tens of thousands of replies (the illustration above; recompute with your real numbers).

Start with a Rp10,000-budget key →