How to not get surprised by the bill. For plan details, pricing, and what your subscription includes, the Zo docs are the source of truth (https://docs.zocomputer.com/billing.md). This guide is the practical layer: what actually drives spend, where it hides, and the habits that keep it boring.
The shape of the problem
AI spend rarely blows up because of one big thing. It blows up because of small things multiplied: a cheap run on an aggressive schedule, a capable model on a trivial task, a retry loop nobody watched, a metered third-party API behind a feature you forgot. None of them look scary on day one. All of them compound.
So the discipline is not frugality. It is knowing your multipliers.
Multiplier 1: schedules
A scheduled agent costs per run, and the schedule is a multiplier you chose once and then stopped seeing. Daily is ~30 runs a month. Hourly is ~720. Every five minutes is ~8,600. The question for any schedule is not "is one run cheap?" but "is this worth its monthly run count?"
The classic trap is polling: checking every few minutes whether something happened, paying full price each time to usually learn nothing. If the event can push to you (webhook into a service) instead of you repeatedly asking, that is the structural fix. If it cannot, run the check at the slowest cadence anyone actually acts on, which for most "monitoring" is daily, not every five minutes.
Two cheap wins on any schedule you keep: give the agent an early exit ("if nothing is new, stop immediately") so empty runs stay small, and keep the standing instructions lean, because the prompt is re-read on every single run.
Multiplier 2: model choice
Models differ in price by an order of magnitude or more, and most routine work does not need the top model. Summarizing, reformatting, classifying, extracting, routing: a smaller model does these fine, hundreds of times a month. Deep reasoning, gnarly debugging, high-stakes writing: that is what the expensive model is for.
The rule of thumb: match the model to the task, and be deliberate wherever a model choice is multiplied by a schedule or a loop. A flagship model on a one-off question costs pennies and is fine. A flagship model inside an hourly automation is a standing tax. When you build anything recurring, choosing the model explicitly is part of building it.
Multiplier 3: loops and retries
Anything that retries, recurses, or self-continues can multiply without you in the loop. The protections are structural, the same guardrail thinking we use everywhere else:
- Cap retries; never "retry until it works."
- Cap depth: agents that spawn agents need a hard limit. Ours cannot spawn sub-agents at all from inside a sub-agent, precisely because runaway delegation is how you wake up to a swarm.
- Make long-running work visible: a log line per run or per step, so volume anomalies show up as an obviously fat log instead of an end-of-month surprise.
Multiplier 4: third-party metered APIs
Your Zo bill is not the whole bill. Scraping services, data APIs, media generation, SMS gateways: anything metered that your builds call is spend that lives outside your Zo usage page, and it fails differently too: trials expire, plans cap, prices change.
Habits that keep this tame, all from our own production practice:
- Keep a one-page inventory of every external metered service you use: what depends on it, which plan, what the monthly ceiling is, when any trial ends. Five lines per service. The inventory is the difference between "we knew the trial ended this month" and a dead feature plus a mystery charge.
- Estimate the monthly burn when you build, not when the invoice lands. One of our scraping integrations consumes a known ~80 browser-hours a month against a known plan ceiling; we know there is headroom because we did that arithmetic on build day.
- Cache and deduplicate before calling. The cheapest API call is the one you skip: store results, write only on change, check local data first. One of our pipelines only writes a snapshot when the value actually changed, which cuts both API pressure and storage churn.
- Treat external sources as fallbacks, not foundations. If a metered API dies or triples in price, the feature should degrade, not vanish. This is a cost posture as much as a reliability one: dependency is what turns a price change into a hostage situation.
The habits, in order of value
1. A weekly two-minute usage glance. Open your usage view once a week and look for one thing only: does the shape match what you believe you are running? Most billing horror stories were visible for weeks in exactly this view. You are not auditing; you are noticing.
2. Know your standing spend. You should be able to list from memory what runs on a schedule and roughly what each costs a month. If you cannot, list your automations and services right now and prune. The forgotten daily job from an abandoned experiment is a cliché for a reason, and decommissioning is part of finishing any experiment.
3. Estimate before you ship anything recurring. Runs per month times rough cost per run, on a napkin. Thirty seconds. If the napkin number makes you hesitate, redesign before launch, not after the first bill.
4. Build kill switches into anything that spends. Any integration that costs money per use gets a flag that turns it off instantly, without a deploy or a redesign. We have flipped ours in production: when one outbound integration misbehaved, a single switch isolated it while everything else kept running. The day something runs away, you want a switch, not a refactor under pressure.
5. Fix the system, not the invoice. When a surprise does land, the response is the same loop we use for every failure: find the multiplier that caused it, change the structure (slower schedule, smaller model, cache, cap, kill switch), and write the lesson where future-you will see it.
The one-paragraph summary
Spend follows multipliers: schedule frequency, model tier, loop depth, and metered externals. Choose each one deliberately at build time, glance at usage weekly, keep an inventory of what runs and what it costs, and wire a kill switch into anything that spends on its own. Do that and cost stays what it should be: a boring, predictable line item under a system that earns far more time than it burns.