Credits administration
Platform defaults, everybody's balances, per-user allowances and hand adjustments — each one landing in a ledger with your name on it.
/admin/credits:
Builds are billed in credits from measured tokens, at each model's rate (set on the Platform AI page). Every change lands in an immutable ledger.
The rate a model charges is not on this page — it is Credits/1k on Platform AI. This page is about who has how many.
Platform defaults
Applied to every user without a personal override.
Two numbers:
Monthly allowance — default 500. Every user's balance is topped up to this number once per calendar month. It is a top-up, not an addition: a user sitting on 120 receives 380; one sitting on 620 receives nothing, and keeps the 620.
Signup grant — default 300. This is the number of credits a new account is meant to receive on creation.
In the current build no code path awards the signup grant. The setting is stored and shown here, and has no effect. New accounts get their first credits from the monthly allowance instead, which arrives within a few minutes of their first visit or at their first build attempt. Set the monthly allowance to the number you actually want new users to start with.
Press Save defaults. Either field must be 0 or more; the refusals are literally monthlyAllowance must be 0 or more. and signupGrant must be 0 or more.
Changing the monthly allowance affects the next month's top-up, not anyone's current balance. To change a balance now, use Adjust.
Balances
A table of every user on the installation, with a search box filtering on name and email.
| Column | What it is |
|---|---|
| User | Name, with the email below. A user with no name shows —. |
| Balance | Current balance. Red when it is at or below zero, which means their builds are paused. |
| Allowance | Their personal allowance, or the word default when the platform default applies. |
| Total spent | The sum of credits charged across every build run they have ever started. |
Three buttons per row: Ledger, Allowance, Adjust.
The quickest health check on an installation is to sort your eye down the Balance column: a row of red is either an allowance set too low, or a model priced too high on the Platform AI page.
Adjust — changing a balance by hand
Adjust credits for
<email>Positive grants, negative removes. The change lands in the ledger with your name on it.
Two fields: Credits (e.g. 500 or -200), which must be a non-zero number, and Reason (shown in the ledger).
Press Apply. The toast reports the new balance.
Fill in the reason. It is what the user sees in their own ledger, and what you will see in six months when you are wondering why a balance is what it is. Leaving it blank records "Admin adjustment by <your email>", which says who but not why.
Two things to know:
- Negative adjustments have no floor. You can push a balance below zero.
- Adjustments are permanent ledger rows. There is no undo. Correcting a mistaken adjustment means making a second one in the opposite direction — both stay visible, which is the point of an immutable ledger.
Allowance — a personal override
Monthly allowance for
<email>The balance tops up to this every month. 0 clears the override so the platform default applies.
One field, pre-filled with the current value. It must be 0 or more.
Zero is not "no credits". Zero means no override — the platform default applies again. To actually stop someone building, adjust their balance to zero and set their allowance to a small number, or set the allowance to something you are content for them to have each month.
An override takes effect at the next month's top-up.
Ledger — reading a user's history
Ledger —
<email>Balance<n>· tops up to<n>monthly. Newest first; struck-through rows are refused charges, kept for audit.
The 50 most recent entries: a date and time, the description with a badge — Grant, Build, Adjustment or Purchase — and the change in credits, green with a + when positive.
Struck-through, faded rows are charges that were attempted and refused, kept deliberately rather than deleted. The reason is in brackets: insufficient_credits or account_not_found.
Purchase is a defined entry type that nothing in the product writes. There is no way to buy credits.
What this page cannot do
- It cannot create or delete users. Accounts live at the Bookbag account service.
- It cannot set per-organization budgets. Credits are per person, always.
- It cannot sell credits. There is no payment flow anywhere in the product.
- It cannot change model pricing. That is Platform AI.
Users who bring their own key
They appear in the table like everyone else, with a balance and an allowance that simply go unused. Their builds are unmetered and charge nothing, so their Total spent stops growing.
If your installation wants people to bring their own keys, this is how you tell who has: a long-standing user whose total spent has stopped moving.