Quota Killers in a Multi-Bot Setup

1. Why I'm writing this

I'm Hugozen. In my flagship post I said AI and infrastructure cost me roughly $1,000+ a month, as an order of magnitude. This post skips the general "how to save money" principles and asks one specific question: what is actually eating the quota?

My old assumption was that quota use scales with how much work gets done. After going through a usage export, I found that's wrong. In many sessions the first request already carries a large base, before the bot has done anything. That changed how I troubleshoot. Instead of asking "how hard is this task?", I now ask "how many sessions did I open today, and how many times?"

Below is the checklist and migration procedure I built from that. It deliberately doesn't overlap with the pitfalls section of the flagship post: that one is about workflow, this one is only about quota.

2. The base: what you pay before saying anything

This is my reading of the usage data, not an official statement from any provider.

When a bot opens a session, the first request carries more than your message: rules, role setup, memory, tool descriptions, history summaries. That chunk doesn't shrink with the task. Ask for a one-word "ack" and it still carries the whole base.

So consumption looks closer to this:

total ≈ number of session triggers × base size + the actual incremental work

In many cases the first term dwarfs the second. That explains why the three things below cost the most. They share one trait: many triggers, very little work per trigger.

3. Three quota killers

1. High-frequency routines. Say you have a bot check data, scan sites, or write a small report every so often. Each run looks cheap, but each is a fresh session that pays the base again. Multiply by frequency, then by number of bots, and the bill gets ugly. Worse, most of the time the output is "nothing changed": you paid the base and got filler back.

2. Group chats. Put several bots in one group and every incoming message can trigger each of them. Each carries its base, then decides "this isn't for me." More members and more fragmented messages mean more idle spinning. My mistake was adding bots to groups "for easy syncing," and the syncing itself became the biggest cost.

3. Bots waking each other. One bot's output triggers another, whose reply triggers the first. Every hop is a full first request. Without a round limit, two bots can politely chat away a lot of quota. Agent-to-agent review is the same pattern: with no cap on rounds, it just keeps reviewing.

Worth writing down: none of these produce work, only triggers.

4. The fix: move heavy work to subscription-based execution

In one sentence: the bot that faces me should not burn its own quota on analysis. Heavy work goes to scheduled jobs on the always-on machine at home, runs on a subscription model, and writes results back to notes.

My migration steps:

Step 1: Inventory. List every scheduled routine and event trigger. For each, note how often it fires, whether it really needs a conversational bot, and whether its output is "mostly unchanged."

Step 2: Classify. Analysis, summarizing and inspection jobs (read-only, repeatable, no instant reply needed) get moved out. Anything needing live conversation or a decision in chat stays, at lower frequency.

Step 3: Local scheduled jobs. Moved routines become built-in system scheduled jobs on the home machine that call a subscription CLI model. The script fixes the input (what to read), the output (where to write) and the red lines (what not to touch), the same idea as the brief in the flagship post.

Step 4: Write results to notes. Output goes into notes, not pushed to the bot through chat. The bot reads them when needed instead of being woken by every output. This is the key step: it separates "output" from "trigger."

Step 5: Kill broad event triggers. Rules like "wake on any new message" get narrowed to explicit conditions. Anything that can be "I ask when I want to look" becomes exactly that.

Step 6: Route by model. For personal projects, the main path is a monthly-subscription or off-peak model route. Cheap bulk work (checks, formatting, classification) goes through a low-cost channel such as a low-cost model path. Expensive models are kept for key judgment calls. I won't write plan names or prices; the routing principle matters more than the numbers.

After the move, the bot's role is cleaner: break down tasks, write the brief, dispatch, verify, report. It ends its turn once a complete brief is sent, and doesn't poll.

After the move, usage dropped noticeably. I won't give numbers; I'm only recording the direction.

5. A few small pitfalls

• Moved routines need a failure signal. If a local job fails silently, you won't know for a long time. At minimum, have it write an explicit record on failure.
• Subscription execution has limits too. It's not unlimited, just a different billing path. Batch work still needs boundaries and no infinite retries.
• New bots don't inherit these rules. When I add one, I have to push "don't idle in groups, don't take broad triggers" to it, or it repeats the mistakes from its defaults.

6. Checklist

1. List all scheduled routines and event triggers, with frequency and "usually changed or not."
2. Move analysis, summarizing and inspection routines to local scheduled jobs on a subscription model.
3. Write outputs to notes instead of pushing them to the bot; the bot reads on demand and isn't woken by output.
4. Narrow event triggers: drop "wake on any message," keep only explicit conditions.
5. Keep only the necessary bots in group chats; sync through notes, not the group.
6. Set round limits on bot-to-bot calls and mutual review.
7. Route models by difficulty: bulk work on low-cost, expensive models only for key judgment.
8. Check usage weekly for sessions with a large first request and many triggers; that's the next thing to migrate.

7. Wrap-up

This post expands the "cost control" principles from the flagship. For how the coordinator splits work and how tasks are dispatched and verified, see How I Run a Network of Indie Sites with a Crew of AI Bots.

The blog has three lines: Agent collaboration, SEO & going global, and monetization. You can follow along via RSS at /posts.