Guide

Cap what your agent can spend while you are asleep.

An agent in a retry loop spends at machine speed, and nobody presses Stop at 3am. Three ceilings sit between a loop and your balance. The first one is not a setting — it is that there is no credit line to run up.

Base URLhttps://api.minirouter.sh/v1

Get a keyhttps://minirouter.sh/key

Get a key — no account

Ceiling one — the balance itself

Credits are prepaid. When they are gone the requests stop, and there is no invoice arriving afterwards for the part you did not notice.

This is the difference people actually come here for, and it is structural rather than a feature either of us configured. On a postpaid gateway a runaway keeps billing until somebody notices; the ceiling is whatever your card will take. Here the worst case is bounded by what you deposited, which you chose, in advance, knowing it was the worst case.

The corollary is worth stating in the same breath: there are no withdrawals. Credits buy inference and never convert back to coin. Keeping a small balance is the containment mechanism, not a cash position.

Ceiling two — per-key caps

Four limits are enforced at the edge, per key. Open reservations count against them the moment a request starts, so a burst of concurrent calls cannot slip past a cap that a serial one would have hit.

FieldrpmLimit
Capsrequests per minute
FieldtpmLimit
Capsestimated input and output tokens per minute
FielddailyLimitNano
Capsdaily spend cap in nano-USD
FieldmonthlyLimitNano
Capsmonthly spend cap in nano-USD

Defaults are lower for accountless keys and every one of them can be raised per key. When a request is refused the 429 carries Retry-After and names which limit was reached and where to raise it — see /docs/rate-limits.

What to actually set the cap to

Cost one turn, multiply by the turns you expect in a day, then set the cap somewhere above that and below what you would mind losing. The rates below are the current catalog rates; the token counts are an assumption about a workload, and yours will differ.

Assumed input per turn: 4K tokens
Assumed output per turn: 250 tokens
Assumed runaway: 480 turns

Cost of an 8-hour runaway, by model, at current catalog rates
Item	USD
Ministral 14B	$0.43
DeepSeek V3 0324	$0.69
Llama 3.3 70B Instruct	$1.54
GLM 5	$2.42

One turn costs $0.0009 on Ministral 14B and $0.0050 on GLM 5. The useful reading of that spread is not which model is cheaper — it is that the same cap protects you very differently depending on the model behind it, so set the cap after you have chosen the model, not before.

Round up, not down. A cap that trips during normal operation trains you to raise it without thinking, which is how caps stop working. Set it at several times your expected day so that hitting it is genuinely information.

Ceiling three — one key per agent

The only one of the three that is a habit rather than a mechanism, and the one that does the most work.

A cap on a key shared by four agents contains nothing useful: when it trips, all four stop, and you cannot tell which one was looping. A key per agent turns the same cap into a diagnosis — the key that tripped names the agent that misbehaved, and the other three keep working while you look at it. Keys are free and issuing one takes no account, so there is no reason to economise on them.

What hitting a ceiling looks like

Your agent's errors get read inside a chat app where we have no UI, so each one has to be self-contained.

the balance header on every response

curl https://api.minirouter.sh/v1/chat/completions \
  -H "Authorization: Bearer $MINIROUTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"meta/llama-3.3-70b","messages":[{"role":"user","content":"ping"}]}' \
  -D - -o /dev/null

# every response carries the balance, so an agent can warn you
# before it runs dry rather than after:
#   x-minirouter-balance-usd: 4.81
#   x-minirouter-cost-usd: 0.0004
#   x-minirouter-provider: together
#   x-minirouter-ttft-ms: 240