When people see a high token bill in a WhatsApp bot system, the first reaction is almost always the same: “we need a cheaper model.” That sounds reasonable, but in many cases it is not the real problem. The real leak is usually the way the system is operated.
I saw this clearly while reviewing OpenClaw in real use. It was an ecosystem with WhatsApp, heartbeats, scheduled jobs, long-running sessions, logs, tools, automations, and multiple workflows mixed into the same thread.
The first mistake: one session for everything
If you use the same session for chatting, debugging, checking email, coordinating publications, running automations, and replying to WhatsApp, context turns into a bag full of rocks.
Heartbeats and cron jobs: the silent killers
Another major problem is turning routine checks into full conversations. If periodic tasks wake a heavy context and leave clutter behind, cumulative cost rises fast.
Giant tool outputs cost money too
You do not only pay for what you write. You also pay for what the model has to read from tools.
Heavy bootstrap is permanent debt
A bloated bootstrap becomes a permanent tax if it loads on every task.
What works better
- Split sessions by task or domain.
- Isolate routine checks from the main session.
- Use compaction when a thread grows too large.
- Keep tool outputs as small as possible.
- Avoid reading huge files when only one fact is needed.
- Use prompt caching where available.
- Reserve the expensive model for high-value work.
So which model should you use?
Model choice matters after you clean up operations.
The uncomfortable point
Token cost often reveals disorder, not just expense. If you are building WhatsApp bots with memory, tools, and automation, the right question is not “which model is cheaper?” but “does my architecture deserve the model I am paying for?”