Cost control

Memtro picks a model for every routed request by how hard the request is, and each pick has a cheaper second and third choice behind it. Cost control puts a number of tokens a month against each of those choices. When one runs out the choice behind it answers instead; when all three for a level are spent, the request is refused and says which level and which month ran out, rather than quietly costing more.

Nothing is capped until somebody types a number, so an organisation that never opens the page is unaffected.

The grid

Organisation → Cost & usage opens with the same shape as the routing ladder, because it caps the same cells: five difficulty levels down, three choices across, under separate General and Coding tabs. Each box takes a number of tokens a month — input and output counted together — with the unit written beside the field, because a grid of bare numbers reads as pounds or requests just as easily.

• Empty is no limit. That is where every organisation starts.
• 0 means that choice never answers: work goes straight to the one behind it.
• A coding box left empty takes the general figure for the same choice, the same way a coding model falls back to the general one.

Beside every box is what that choice has cost this month, and above the grid is the month's total with the number of routed requests behind it. That figure is the point of the page: "500,000 a month for level 4" is only a decision you can make if you know what level 4 actually costs you. Usage is recorded for every routed request whether or not anything is capped, so the numbers are there before you set the first limit.

What happens when a choice runs out

Falling to the next choice rather than stopping is the whole design. A budget that halts work on the 20th is a worse answer than one that finishes the month on a cheaper model — and the requests that get cheaper are the expensive ones, since the level is chosen by difficulty.

When a level's three choices are all capped and all spent, the request is refused with HTTP 429 and a message naming the level, the month, and where the allowance is set. A level with nothing capped is never refused.

Two honest limits:

• Only routed requests are capped. A request that names its own model never climbed the ladder, so it is neither counted nor capped. That is why model choice is locked to auto for every organisation: a named model is answered as memtro instead, so everything climbs the ladder. An administrator can open it on the Routing page, and is warned there that allowances stop applying to anyone who names a model.
• A month can overshoot by one request. Tokens are only known once an answer exists, so the charge lands afterwards. The alternative is charging for work before it is done.

Setting an allowance mid-month counts what has already been spent: "500,000 a month" means the month, not "from when I typed it".

Teams, and what a blank box inherits

A team can have its own allowances on Team → Cost & usage, and they win for its members. A box left empty there takes the team above it in the tree, and the organisation's only where that one is empty too — the same inheritance as model routing, decided in one place. A lead who caps level 5 for Engineering has capped it for Platform and Mobile as well, without repeating the number.

Where a team shows a figure it has inherited, the usage beside it is the owning scope's month rather than the team's own, because that is the month that decides when the choice runs out.

Setting a team's allowances needs the Control cost for their teams permission, which is granted per team like any other. It is deliberately separate from the routing permissions: choosing which model answers and choosing how much a team may spend are different decisions, and the lead who should hold the second often should not hold the first. It covers the teams they manage and the teams below them. Administrators can set any team's.

Where the figures come from

Every routed request is credited to each scope that could cap it — the organisation, and each team in the caller's line — against the exact choice that answered it. The pot a request is charged to and the pot that caps it are therefore the same row by construction, rather than two definitions of "the team's usage" that can drift apart.

Months are calendar months in UTC. A month's counters are its own: nothing carries over, and an allowance starts again on the first.

A worked month

An organisation reads its first month and finds level 4 accounts for most of the spend: a few thousand requests, a strong model, and a bill that is mostly a handful of people asking hard questions.

It caps level 4's primary at 2,000,000 tokens a month and leaves the secondary and tertiary empty. For three weeks nothing changes — the primary answers, as it always did. On the 23rd the allowance runs out, and level 4 starts being answered by its secondary: a cheaper model, a slightly worse answer to a hard question, and no interruption to anybody's work. Levels 1 to 3, which are most of the traffic, never notice.

The month turns over and the primary answers again from the 1st.

Cap the secondary and tertiary too and the month ends differently: once all three are spent, level 4 is refused with an HTTP 429 naming the level, the month and where the allowance is set. Everything below level 4 carries on, because an allowance is per level.

What it does not do

It does not price anything in money. Memtro does not know what your provider charges you per token, and inventing a figure would be worse than leaving it out; the allowance is in tokens, which is what Memtro can count exactly. Your provider's own dashboard remains the place to read a bill.

It also does not cap the nightly passes that read your memory (commitments, contradictions, jargon) or the embeddings behind search: those pick a fixed rung rather than climbing the ladder. Switching a feature off under Organisation → General is how you stop that work.

Also worth reading

• Model routing — the ladder these allowances cap, cell for cell.
• Usage statistics — where the figures come from, by user, team, model and day.
• Teams and permissions — who may set a team's allowances.
• Billing, seats and leaving — what Memtro itself charges, which is not this.