Credits
Credits put a price on using models: what each model costs, how many credits each person has, and plans that renew them.
Turning it on
Credits are under Admin → Credits and off by default. A server that never turns them on behaves as if every model were free.
- The server has one currency, and a credit has a money value in it, set by the administrator.
- Administrators are unlimited.
- A model with no price is free, so local models stay free beside priced ones.
Prices
On each model’s page an administrator sets what it costs per million tokens of input, cached input, output and reasoning, and per reply. Where a provider reports cached input, it is charged at the cached price. A reply is charged when it ends, by what it really used.
Plans
- A plan gives credits every period and names the models it covers.
- It can cap how fast credits are spent over the last 5 hours, day, week and 30 days.
- At renewal, unused credits either expire (reset) or carry over up to a cap (add).
- New accounts can start with credits and a plan.
- Plans and renewals are set by administrators — in the interface or over the API.
When credits run out
A reply is refused before it starts when there are no credits left, when a spending window is used up (the message says when it frees up), or when the plan does not cover the model. A reply already running may overdraw a little rather than stop half way.
Seeing your balance
Your balance, plan and windows are under Settings → Account (when the administrator shows them), and the balance is in the chat header. The LLeMbas CLI shows it in its status bar and with /usage.
Who can grant credits
Administrators, and anyone with the Grant credits permission, can top up and adjust balances and choose people’s plans. Changing the credit settings and the plans themselves stays with administrators. Every change is in the audit log.
Over the API
| Call | Token scope | What |
|---|---|---|
GET /api/v1/me/credits | models | Your own balance and plan. |
GET /v1/usage | models | This month’s tokens and credits, plan and balance, and this token’s share. |
POST /api/v1/admin/credits/{user}/topup | admin:credits | Add credits (amount > 0, optional note). |
POST /api/v1/admin/credits/{user}/adjust | admin:credits | Correct either way; note required. |
PUT /api/v1/admin/credits/{user}/plan | admin:credits | Set the plan (plan_id, or null). |
GET /api/v1/admin/credits/{user} | admin:credits | Balance, plan, windows and the last 50 entries. |
GET /api/v1/admin/plans | admin:credits | The plans on the server. |
curl -s -X POST https://your-server/api/v1/admin/credits/$USER_ID/topup \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-H "Idempotency-Key: invoice-2026-10" \
-H "Content-Type: application/json" \
-d '{"amount": 50, "note": "October"}'Amounts are credits, as decimals. Send an Idempotency-Key: a repeated key from the same token is applied once, so a retried request never tops up twice.