ZAMBO.

Direct answer

Budget the swarm per agent, or one looping worker spends for everyone.

A swarm's tool bill surprises people because it arrives as one number while the spending happened per agent, at very different rates. One worker idles at 4 calls a day. Another, stuck in a retry loop nobody watched, burns through hundreds. Averaged across the swarm, the cost looks like a property of multi-agent work. Accounted per agent, it is usually one agent, one job design, or one duplicated step, repeated. The budget method on this page is built on how the allowance actually works: the free tier is per agent, not per account. Each agent on its own caller handle gets 20 calls and 1 wrap-up free every day, picking up handovers is always free, and the memory tools are free with no quota. So a swarm's free capacity is the sum of its agents' allowances, and paid capacity should be bought the same way, per agent, only for the agent that runs heavy, never as a blanket upgrade for a swarm where most agents never leave the free tier. Here is the accounting, the caps, and the worked numbers.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup.

Updated November 9, 2026. First published November 9, 2026. The records quoted below are real and public, read back from the live service on November 9, 2026.

Step 1. Put every agent on its own identity, or there is no budget to keep

Per-agent budgeting starts with per-agent identity. Each agent connects under its own caller handle, works under that handle, and labels its steps with it. Two consequences follow. The allowance is real: a four agent swarm holds four daily allowances, 80 free calls and 4 free wrap-ups a day between them, because the meter runs per agent. And the accounting is honest: when a job's record shows which agent ran which step, spend can be read off the same record, agent by agent, step by step. Run the swarm through one shared login instead and both consequences invert. One allowance serves everyone, the swarm hits the wall four times sooner than it should, and the record shows a single anonymous pile of steps that no budget conversation can be had about. Identity is not bookkeeping decoration here. It is the unit the entire budget is denominated in.

Step 2. Count what is free before pricing anything

Three parts of swarm work never need a paid call at all, and a budget that misses them overstates the swarm's cost from the first line. Pickup is free: an agent accepting a handover, reading a worker's saved steps and receipts, costs nothing, however many handovers the coordinator picks up in a day. Memory is free with no quota: saving a finding with memory_remember and recalling it with memory_recall do not consume the metered allowance, so the swarm's learning loop is not a budget item. And each agent's own daily free tier covers ordinary work outright: 20 metered calls plus 1 wrap-up, every day, per agent. The real run quoted below spent 2 counted calls per worker, a price check plus its work steps, and ended the day with most of each allowance untouched. Many swarms that feel expensive are, on inspection, swarms whose free capacity was never counted because the agents were sharing one identity.

Step 3. Read a real swarm day as a budget

The run below is a real three-worker market scan, read back from the live service today. The record format is AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26), and each step carries a verifiable receipt: a receipt proves the saved result was not changed since it was saved.

The swarm run: three workers, one shared record

As a budget, that record reads: three agents, 2 counted calls each, 6 calls against a combined free daily capacity of 60 calls and 3 wrap-ups for a three agent swarm, plus free pickups when the coordinator gathered the work and free memory saves inside each contribution. The same job run badly, agents sharing one identity, steps duplicated because nobody read the record first, a coordinator re-running checks it could have picked up free, costs three to five times the calls and lands on one allowance instead of three. The gap between those two numbers is not a pricing negotiation. It is job design, and the record is what lets you see it, per agent, per step, with receipts.

Step 4. Cap each agent, so a loop bills one allowance, not the swarm

Budgeting is incomplete until something enforces it while you are not watching. Set a spend limit per agent or per job with the spend limit tools, which are themselves free with no quota. At the line, the next paid call is refused, and the refusal is recorded with its own verifiable receipt, so the cap firing is an event on the record the coordinator reads, not a silent failure or a surprise invoice. Handle a firing as a decision, in writing: the agent found real work past its budget and the job grows by a named amount, the agent is looping and gets fixed or stopped, or the job is rescoped to fit. What never happens again after caps are set is the founding horror story of swarm budgets: one worker, one bad night, one bill for the whole swarm's month, discovered from the invoice instead of from the record.

Step 5. Buy paid capacity per agent, at the moment an agent earns it

When an agent does outgrow its free day, the paid shapes are per agent too, and they reward precision. A Day Pass makes one agent unlimited for 24 hours for $0.99, which is the right buy for the one heavy worker on delivery day, and the wrong buy applied to five idle agents out of habit. The Zambo Pass covers an agent for 30 days at $29 a month, $19 a month for $ZAMBO holders, and Lifetime at $250 one time ends the question for a permanent member of the swarm. Sequence the buys by the record: the agent whose steps show daily heavy use gets covered first, specialists who run twice a week stay on the free tier indefinitely, and the coordinator, whose day is mostly free pickups and reads, is usually the last agent that ever needs a pass. Budget reviews then run off the job records you already have: allowances used per agent, cap firings, duplicated steps found and removed. The budget gets better every week because its evidence is the work itself.

What a record does not settle

Per-agent accounting shows where calls went; it does not judge whether they were worth going. A step can be inside budget, faithfully receipted, and still be the wrong tool or a check nobody needed, and a verifiable receipt proves the saved result was not changed since it was saved, not that the call earned its cost. Budgets also only govern work routed through the one connection: calls an agent makes in other tools or accounts spend elsewhere and appear in no allowance here. Finally, free allowances reset daily; a swarm designed to need more than its combined free capacity every day is a paid swarm with a free subsidy, and the honest plan prices it that way from the record, not from hope.

Frequently asked questions

Running a swarm of agents gets expensive in tool calls. How do I budget free and paid calls across many agents?

Budget per agent, because the meter runs per agent. Put each agent on its own caller handle so each holds its own free daily allowance: 20 calls and 1 wrap-up free every day per agent, so four agents hold 80 free calls a day between them. Count the structurally free work first: picking up handovers is always free, and memory_remember and memory_recall are free with no quota, so coordination and learning are not budget lines. Read spend off the job record per agent, set a spend limit per agent or per job so a looping worker is refused at its own line with the refusal receipted, and remove duplicated steps, which bill at full price and buy nothing. Then buy paid capacity per agent, only where the record shows daily heavy use: a Day Pass makes one agent unlimited for 24 hours for $0.99, the Zambo Pass covers one agent for 30 days, and Lifetime covers a permanent agent once, for $250.

Why does my swarm hit the usage wall so fast when each agent barely works?

The usual cause is one shared identity. If every agent connects through the same login or caller handle, the service sees one agent doing the whole swarm's work, and the whole swarm shares a single daily allowance of 20 calls and 1 wrap-up. Four lightly working agents at 8 calls each are 32 calls against one allowance of 20, so the wall arrives before lunch and looks like a swarm problem. On separate handles the same work is 8 calls against four separate allowances of 20, with room to spare and pickups still free. Check the record before the pricing page: if the steps on your jobs carry one producer label for work you know four agents did, identity is the bug, and it costs nothing to fix but reconnecting each agent under its own handle.

What does a coordinator agent's day actually cost?

Less than any worker's, by design. A coordinator's heavy operations are pickups, and pickup is always free: accepting each worker's handover and reading its saved steps and receipts costs no metered calls, however large the swarm. Its memory recalls are free with no quota. What a coordinator spends metered calls on is its own execution: any tool work it does itself instead of delegating, and its final wrap-up, 1 per job, which its free daily wrap-up covers on an ordinary day. So in a sane budget the coordinator is the last agent to need a paid pass, and a coordinator that is somehow your most expensive agent is a finding in itself: it is doing worker work, re-running checks it could verify from receipts, or both, and the record will show which.

How do spend limits work when several agents share one job?

Set the limit where the risk lives. A per-agent cap stops that agent's paid calls at its line, which is the loop protection: one worker can burn to its cap and stop while its siblings keep working inside their own allowances. A per-job view comes from the record: every step carries its agent's label and receipt, so the job's total spend and each agent's share of it can be read at any moment, and a cap firing appears on the record as a receipted refusal, visible to the coordinator the same run. When a cap fires, treat it as a written decision point: grow that agent's budget by a named amount for named work, fix or stop the loop, or rescope the job. The limit tools themselves, spend_limit_set and spend_limit_status, are free with no quota, so checking the swarm's spend position never spends it.

How do I budget my swarm's next heavy day?

Count the free capacity first, assign the heavy agent its pass, and let the record from the last run set both numbers. When the work runs through Zambo, each agent connects to https://zambo.dev/mcp under its own caller handle, holds 20 calls and 1 wrap-up free every day, picks handovers up free, and every step carries a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26. New users get 20 calls and 1 wrap-up free every day per agent, and picking up work in another AI is always free. For $0.99, put the one agent that will run heavy on a Day Pass, unlimited for 24 hours, and leave the rest of the swarm on its free allowances: get the Day Pass. No subscription. Ongoing cover is the Zambo Pass at $29 a month, $19 a month for $ZAMBO holders, or Lifetime at $250 one time.

Related