Manage an event budget

As an organizer you pay for everything your events provision, and for any inference keys your account issues. This page is the practical routine: work out what a term of teaching costs, get that credit into the account, and check afterwards what it actually came to.

For the underlying model — one euro ledger, when charges land, what the sources mean — see Credits and billing.

1. Estimate in GPU-hours first

Published rates change; the arithmetic does not. Count GPU-hours, then multiply by the current rate once at the end.

blades       = ceil(participants / users_per_blade)
GPU-hours    = blades × session_hours
session_cost = GPU-hours × published_rate_for_that_GPU

A 40-person lab, one GPU each, running three hours:

blades    = ceil(40 / 1) = 40
GPU-hours = 40 × 3       = 120 GPU-hours per session

Twelve weekly sessions is 12 × 120 = 1,440 GPU-hours for the term. Look the rate up once — on the pricing page or with GET /v1/gpu-types/ — and multiply.

Tip

Setting Users per blade to 2 halves the number of blades, and therefore halves the cost, at the price of two people sharing one GPU’s memory and throughput. It is a reasonable trade for teaching exercises and a poor one for training runs.

2. Understand what the estimate is not

The estimate razorBridge shows when you create an event uses your Max participants value, not the number of people who have actually joined. It is a worst case, and deliberately so — it is what the balance is checked against.

The charge, by contrast, is for the blades that were really provisioned, for the time they really ran. An event capped at 40 that 25 people join bills for 25 blades. Expect the final cost to come in under the estimate.

3. Fund the account with headroom

Provisioning refuses to start if the balance cannot cover the padded estimate, and a failed provisioning means nobody gets a GPU — the failure mode organizers most regret. So:

• Request credit for the estimate, not for your expected attendance.
• Leave room for at least one extension (30, 60 or 120 minutes) if sessions tend to run over.
• Ask early: credit is granted by KlusAI on request, not bought self-serve. Email hello@razorbridge.eu with the GPU type, the number of participants, the session length and the number of sessions. University and volume arrangements, including invoicing, are handled the same way.

Check what you have before each session:

rb credits

4. Raise the account limits if you need to

A new account is capped at 2 concurrent self-serve blades, 8-hour sessions and €50 of spend per calendar month. Those defaults are sized for an individual trying the product, not for a course: the monthly cap in particular will stop a teaching term in its second week. Ask for them to be raised when you request credit.

The caps apply to your own self-serve sessions and monthly spend; event blades are gated by the balance check instead.

5. Track spend afterwards

Two views, and they should agree:

• Per event. The event’s detail page shows a cost card, labelled Estimated while the event is scheduled or running and Final cost once it has completed.
• Per account. rb credits, or Credits in the web app, lists every movement with its source: consumption for GPU runtime, inference for gate calls, grant for credit you were given. GPU runtime for an event arrives as a single debit after teardown, so nothing appears mid-session.

rb --json credits > spend.json

There is no cost-report export. The event page’s final cost and the ledger entries are the record; rb --json credits is the machine-readable form if you need to total it up for a department.

6. Keep inference spend contained

Gate keys belong to the account, so a key you hand to a class spends your credits, and usage shows up under the inference source with no per-student attribution. Practical measures:

• Issue one key per group or per exercise, so you can revoke a leak without disrupting everyone: rb gate keys create "Week 4 exercise", then rb gate keys revoke <KEY_ID>.
• Ask KlusAI to set a budget cap on a key if you want a hard euro ceiling; it is enforced but not yet self-serve.
• Restrict a key to specific models when you create it through the API, so nobody runs an expensive one by accident. See Inference gates.
• Watch it with rb gate usage.

Related pages

• Run an event — the scheduling and monitoring workflow.
• Credits and billing — the ledger model in detail.
• Inference gates — keys, scoping and usage.