How a build spends credits
The exact formula, when the charge happens, why cached input is cheaper, and why the same request can cost different amounts twice.
Bookbag charges for the tokens a build actually used. Nothing is estimated and nothing is charged up front.
When the charge happens
Once, when the run ends. Not per step, not per token, not per message.
Throughout the run Bookbag adds up three numbers from the model provider: input tokens, output tokens, and how many of the input tokens were served from the provider's cache. When the run finishes — successfully, with an error, or because you cancelled it — those three numbers are turned into a credit charge and written to your ledger.
A run that fails still costs credits, because the tokens it burned were really spent.
The charge is written with an idempotency key tied to the run, so a crash or a retry cannot bill you twice for the same run.
The formula
weighted = fresh input + (cached input × 0.1) + output
credits = ceil(weighted ÷ 1000 × rate) — minimum 1
Where:
- fresh input is input tokens that were not served from cache.
- cached input is billed at one tenth, because that is roughly what providers charge for it. A discount you earned is a discount you see.
- rate is the model's
credit_cost— credits per 1,000 weighted tokens. It is set per model by an administrator, defaults to 1, and can be anywhere from 1 to 100. - Any run that used tokens at all costs at least one credit.
A worked example
A real run used 2,800 input tokens of which 1,300 came from cache, and produced 440 output tokens. The model's rate is 1.
fresh = 2800 − 1300 = 1500
cached = 1300 × 0.1 = 130
output = 440
weighted = 2070
credits = ceil(2070 ÷ 1000 × 1) = ceil(2.07) = 3
Three credits.
Why the same request costs different amounts
Several things move the number, and none of them is arbitrary:
How big your app is. The builder is given a list of every file in the project, and it reads the files it needs. A change to a twelve-file app sends far fewer tokens than the same change to a sixty-file one.
How long the conversation is. The whole history of the project is replayed on every run. The tenth change to a project costs more than the first, all else being equal.
How many steps it took. A change the builder gets right on the first try is cheap. One where it reads four files, makes an edit that does not match, reads again and retries costs several times as much.
Whether the provider served cache hits. Repeated context is often cached by the provider, and cached input is billed at a tenth. This is why a rapid series of small changes can be surprisingly cheap.
The model's rate. A model priced at 3 credits per 1,000 tokens costs three times what one priced at 1 does for identical usage.
Rough expectations
Bookbag does not publish a price list, and giving you one here would be inventing numbers. What the mechanics imply:
- A small change to a small app — one file read, one edited — is a handful of credits.
- A first build is the most expensive thing you will do on a project, because the builder writes several files from nothing.
- A run that goes in circles and hits the loop detector or the 60-step ceiling is the expensive failure mode. That is one reason both limits exist.
The honest way to find your own numbers is the ledger: every run appears there with the exact credits it cost. See The credit ledger.
What is not charged
| Charged? | |
|---|---|
| A build run, including a failed or cancelled one | Yes |
| The security check | No — it reads files and calls no model |
| Applying the security check's fixes | Yes — it is an ordinary build run |
| "Get me unstuck" | Yes — an ordinary build run |
| Restoring a version | No |
| Publishing | No |
| Downloading the source | No |
| Browsing files, reading history, opening a project | No |
| Renaming the project with AI after you create it | No — it is charged to nobody |
The step ceiling as a cost cap
A run can take at most 60 steps. Combined with the model's per-turn output limit, that is the hard ceiling on what one message can cost you. A run that reaches it ends politely:
The run used all 60 steps. Send a follow-up message to continue.
The loop detector is the other guard: a builder repeating itself is stopped rather than left to spend your balance.
Runs on your own key cost nothing
If you have an active model of your own with a working provider key, the run is marked unmetered:
- The credit check before the run is skipped.
- The mid-run check is skipped.
- Nothing is settled at the end, and the run records zero credits charged.
Your provider bills you directly for exactly the same tokens. See Your own AI key.