Spend and models

Your keys, your bill

Runs use model connections you add: your own Claude or OpenRouter credentials. The model provider bills you directly. Zero Human does not resell model usage, and a cheap model is not a budget: caps are.

What counts as spend

Spend is the cost of model calls: every step of a run, and every chat reply. Tool calls are not spend. Each call is priced once, and the same figure is used by every cap, by the run's Cost, by today's total on Spend, and by an execution's total.

The seat's plan comes from Anthropic, or you set it on the connection (Seat plan and Monthly price (USD)).

A run's Cost is at the top right of its page. Hover it for the split between API and seat usage and the tokens in, out and cached.

Caps

Settings → Spend holds your caps. A cap sits on one layer: the enterprise, a team, a member, a role, or a task. Amounts are in US dollars.

A run is held by every cap that applies to it: the enterprise's, and those on its team, its member, its task and its member's roles. The tightest one wins.

Today's spend and today's runs are counted for the whole enterprise. A day cap on a team or a task is compared with everything the enterprise spent today, not only that team's or task's share; the Spend page says so on each row.

A new enterprise has no caps until you add one.

When a cap is reached

The caps are checked when a run is about to start, before its first model call. If today's spend (with room for the next call) is at a day cap, or today's runs are past a Runs / day cap, the run does not start. It is parked as paused_spend:

• It keeps its place: its task and its member stay busy, so later starts of that task wait or are skipped.
• It appears on Blockers under Paused spend, with Raise cap.
• A run already under way is not stopped by a day cap. It carries on to the end.

Paused runs start again when you raise a Day $ cap to a higher amount (every paused run in the enterprise is queued again and checks the caps afresh) or turn spend limits Off. Changing Runs / day or Run $ does not queue them again, and nothing restarts them at midnight: raise a day cap, turn limits off, or cancel them. Once spend reaches 80% of the tightest day cap, Spend and Enterprise warn you and Spend in the sidebar shows a badge.

Chat replies count toward today's spend too. Before each reply, the day caps on the enterprise and on that member are checked; at a cap the member says so and does not reply. See Chat and plans.

Per-run budgets

A task's Spend USD / run, and Run $ on a cap, set what one run should cost at most; the tighter of the two applies. It is only partly enforced today. On an OpenRouter connection, each model reply is kept short enough for the run to stay within it, and a reply that the limit cuts off fails the run (llm_max_tokens). On a Claude connection it is not enforced during a run.

Turning spend limits off

The switch at the top of Spend turns spend limits On or Off for your enterprise. Off ignores every money cap, every run-count cap, the caps' model tiers and the tasks' per-run budgets, for runs and chat alike, and queues any paused runs again. Spend is still recorded, and a task's own highest tier still applies. With limits off, the rest of the Spend page and the Paused spend section on Blockers are hidden.

Model tiers

A tier names a class of model, so a task can ask for "a cheap one" without naming it:

Each tier stands for one model on each provider. The cap form shows which model a tier means on your connection.

Which model a run uses

A task's Model field decides:

• An exact model, picked from your providers' directories, is the model the run uses. A tier cap does not block it; money caps still apply.
• Default uses a tier: the tightest of the tiers on the caps that apply and the task's own highest tier, or economical when neither sets one.

Every cap carries a Max model tier, mid unless you choose otherwise. So adding a cap also sets the tier your Default runs use.

Chat has its own setting, Chat model on Enterprise, economical unless you raise it, and tightened by caps like a run.

Model connections

Settings → Agents lists every model connection in the enterprise, whose it is, and whether it can be read. Keys are never displayed. Add Agent adds one:

A connection belongs to the enterprise, shared by everyone, or to one member, used for that member's runs and chats. A run tries them in this order:

1. The member's own Claude connection.
2. The enterprise's Claude connection.
3. The member's own OpenRouter connection.
4. The enterprise's OpenRouter connection.

When a task names an exact model and both providers are connected, the provider that offers that model is tried first. The OS's own tasks have no member, so they use the enterprise's connections.

When a connection cannot be used

A run never fails for want of a model. It is blocked, says why, and resumes when the cause clears:

The OS also checks every ten minutes that each tier's model still exists on your connection. A model the provider says is gone is listed on Blockers under Models unavailable, before a run meets it. See Runs.

Plans

Your plan sets how long run history is kept (see Isolation and retention), and what your enterprise includes: members, runs, runner minutes, concurrent runs, schedules and storage. See pricing.

Over the API