The token allowance

Running a build costs money, because it calls a large language model and models are billed by the token. Bookbag gives you two ways to cover that:

1. Let us run the models. They run on the platform's provider key and count against your token allowance — one allowance per Bookbag account, shared with Openbook and Madebook.
2. Bring the organization's own provider key. Every build in that organization runs on that key, the provider bills it directly, and nothing is metered or capped at all. See AI configuration.

The allowance exists for people who would rather not hold a key. It is not the only way in.

If you are here looking for credits, they are gone and your balance was not. See What happened to credits.

The allowance caps what the platform pays for

This is the sentence everything else follows from, and it is not the same as "what you are allowed to use".

	Managed by us	Self hosted
Whose key runs the build	The platform's	The organization's own
Who pays the provider	The platform	You, directly
Counted against the allowance	Yes	Recorded, but as zero
Can be refused for being over it	Yes	Never

A self-hosted organization costs the platform nothing, so there is nothing for the platform to cap. Its builds are still recorded — you can see exactly what they used — but no figure they reach will stop them. A managed organization runs on the platform's key, and the allowance is how much of that the platform will carry.

Every build run also records which of the two it was, as a metered flag, because "whose bill was this" is a question asked of a run months later.

One allowance per account, shared across every product

The allowance belongs to an account — one person's Bookbag login — and a build is charged to the owner of the organization the project is filed under.

• Every organization that account owns draws on the same number.
• Bookbag, Openbook and Madebook draw on the same number. A mission run in Madebook moves the bar on Bookbag's AI page.
• It is the same arrangement as storage: one pile, one account, every product.

The default is 1,000,000 tokens per window unless a platform admin has changed it, or has set a different figure for that one account.

This is a change from credits. A credit balance was yours and travelled with you: building in a colleague's organization spent your credits. The token allowance belongs to the organization's owner, so building in a colleague's organization now spends theirs. The same person can be on the platform's meter in one organization and entirely unmetered in another, on the same afternoon — that part has not changed.

What counts as a token

For a build in a managed organization, everything the run actually consumed:

• fresh input — the part of the prompt the provider processed from scratch,
• output — what the model wrote back,
• cached input — counted in full, not at a tenth.

Cached input counting in full is a decision, not an oversight. The allowance is a budget of work, and someone watching the bar should not have to understand a provider's cache pricing to predict it. The three figures are stored separately on every run, so the rule can change later without rewriting what already happened.

This is stricter than credits were. Bookbag's credit formula discounted cached input to a tenth. The allowance does not. Against that, credits rounded every single run up to a whole credit, taking slightly more than they should on every short turn. The two differences point in opposite directions.

A generated image counts as a flat number of tokens — 10,000 by default, set by a platform admin. An image is not made of tokens, so that is a conversion rate rather than a measurement. When a window contains any, the bar says so: "3 generated images counted as 10,000 tokens each."

A build in a self hosted organization is recorded with zero billed tokens; its real counts are kept and reported separately.

There is no per-model rate any more. What a build costs in detail is in What a build costs.

Windows, not a monthly top-up

Nothing resets and nothing is topped up. Usage is the sum of what was recorded since the current window began, and the window is computed from the period every time anyone asks.

• Monthly means the UTC calendar month — the 1st, because that is what "monthly" means to a person reading an invoice.
• Weekly means seven-day blocks from a fixed anchor, set to the most recent UTC Monday when an admin chooses weekly.

Two consequences:

• Last window's figure is still readable. Nothing was zeroed, so "what did I use last month" stays answerable, and the bar shows it.
• Changing the period changes only what the window means from then on. Every run keeps the window it actually fell in.

A balance that could go negative, and a top-up that levelled it back up, are both gone with the credit system. There is nothing to go negative: there is a ceiling and a sum.

The bar on the AI page

Organization → AI self hosted, directly under the mode switch. In managed mode:

• Tokens used this month (or this week) against the allowance, with a bar that turns amber past 80% and red when you are over.
• When it turns over — the day the window ends.
• The image note, when any were generated in the window.
• Which product spent it — a row per product, tokens and run count each, so a bar that moved without anyone building here is explainable.
• On your own key — tagged not counted — what this organization's own key ran, shown beside the total and never added into it.
• Previous month (or week) — the window before this one.

In self-hosted mode there is no bar. A trough with no ceiling is a picture of a limit that does not exist. The text says plainly that there is no cap and your provider bills you directly, and the breakdown below still shows what ran, so the two modes can be compared.

One oddity worth knowing. In self-hosted mode the headline figure is still the account's managed total, labelled "on the platform's key" — so it can be non-zero because of work done in another organization, or earlier in the window before the switch. What this organization's own key ran is the On your own key row underneath. Read the label, not just the number.

Any member of the organization can read the page. Changing the mode takes an owner or an admin.

When a build runs out

The allowance is checked before any provider is called — the model is resolved from the account service's own tables, so nothing has been spent proving the point.

Before a run starts. The build does not start. The step list shows:

Out of tokens — the build did not start

Partway through a run. The run stops at the next step boundary, keeps everything already written to your app, and ends as done, not failed:

Out of tokens — stopping

Both carry the account service's own sentence, shown exactly as it arrives:

Token allowance reached (1,020,500 of 1,000,000 tokens used this month). It turns over on 1 October 2026. An organization running on its own provider key (self-hosted mode) is not metered at all, or a platform admin can raise this account's allowance.

It names the figures, the date it turns over, and the two ways out. The browser shows it as a warning headed Out of tokens, not as a build failure — because it is not one. Nothing broke, and there is nothing to retry: the second attempt would read the same tables and give the same answer.

Mid-run, the summary adds "What was built so far is saved."

What still works when you are out

Almost everything. Running out blocks metered build runs and nothing else. You can still:

• open, read and download every project,
• browse the source and the version history,
• restore a version,
• run the security check,
• publish, republish and take a site offline,
• switch the organization to self hosted, add its own AI key, and start building again immediately with nothing metered.

The two ways out

1. Move the organization to its own provider key. Switch AI self hosted to self hosted, add a key and a model, and nothing in that organization is metered or capped again. An owner or an admin can do it without asking anyone.
2. Ask a platform admin to raise the account's allowance. They set it per account, at the account service, not in Bookbag.

Waiting also works: the window turns over on the date the sentence names.

One run can cross the line. The check asks whether the allowance is already spent, not whether the run you are starting will fit — nobody knows what a build will cost before it runs, and guessing would refuse work that would have fitted. So one run may finish slightly over, and the row recording it is exactly what refuses the next one.

A retried request is charged once

Every run is recorded under a key, so a retried request re-asks the model but is charged once. A genuinely new step gets a new key, so this is not a way to make repeated work free.

Where a platform admin changes it

At the Bookbag account service, on its AI tokens page. From Bookbag's own /admin, the sidebar's AI tokens ↗ is the door out to it — it sits where the old Credits page used to be.

There a platform admin sets:

• The default allowance — the most one account may use per window, across every organization it owns and every product it uses.
• Whether it turns over monthly or weekly. Monthly means the 1st, in UTC. Weekly means seven-day blocks from the most recent Monday, re-anchored the moment weekly is chosen. Changing it changes what the window means from then on; nothing already recorded moves.
• What a generated image costs in tokens.
• A per-account exception, found by the email the person signs in with, with a note saying why. Clearing it puts the account back on the default.

The same page shows the window's totals and the ledger: one row per run, never edited and never deleted, with a refusal kept as a void row so "why did my build stop at 4pm" stays answerable. See The token allowance, for administrators.

Where to go next

• What a build costs — what moves the number, and what is not counted at all.
• Where your usage is recorded — the bar, the breakdown and the ledger behind them.
• AI configuration — the switch that decides whether a build is metered at all.
• What happened to credits — if you had a balance.