Credits

There are two ways to pay for inference on Helmcode, and they work together rather than replacing each other.

A monthly plan buys a flat allowance on our own models: unlimited on the efficient ones, capped per month on the largest. Credit is a prepaid balance in euros, spent per token at the published rate for each model. You need credit for anything a plan does not cover, and the clearest case is the frontier models we resell from OpenAI, Anthropic and Google, which no plan covers at any tier.

The balance

One balance per organisation, in euros. It never expires and never resets: credit is spent, not renewed. Everything is in euros too: the balance, the statement, the price list and the invoices, so you never read your balance in a different unit from your invoice.

Three properties are worth knowing, because they are what make the number defensible:

The balance never goes negative. When a request costs more than what is left, we charge what was there and absorb the difference. Your statement shows both figures, what the request cost and what we actually took, so the gap is visible rather than unexplained.
Every movement is a row. Purchases, spend, automatic top-ups, refunds and adjustments are appended to a ledger that is never rewritten, and every charge references the request that produced it. That is what lets a question about one single request be answered months later.
Amounts are exact. The balance is held internally in whole micro-euros rather than as a floating point number, so a long run of small charges still adds up to the cent.

The Credits section of the Helmcode console: a prepaid balance in euros, the Add credits and Auto top-up buttons, and the How your usage is billed block comparing the plan allowance meter against the credit meter. — The Credits section of the console. The balance shown there is the live one, and the block underneath is the two meters side by side.

What credit pays for, and in what order

For any given request the order is fixed:

#	Situation	What pays
1	Your plan covers the model and the monthly allowance is not exhausted	The plan. Credit is untouched
2	Your plan covers the model but the monthly allowance is exhausted	Credit tops it up
3	The model is outside every plan, or you have no subscription at all	Credit
4	No allowance left and no credit	The request is refused with `402`

Two separate meters, then, never added together, and only one of them resets: the plan allowance is measured in tokens and resets on the 1st, credit is measured in euros and does not reset at all.

Two consequences of that order:

An organisation with credit and no subscription at all can use the whole platform, paying per token.
A subscribed organisation never pays credit for something its plan already covers. The plan allowance is always consumed first, so there is no double charging.

Buying credit

Purchases are one off, made from the Credits section of the console and paid through Stripe Checkout. The amount has to be between €5 and €5,000.

The ceiling is a fat finger guard rather than a policy: if you need more than €5,000 in one go, talk to us. The floor exists because of the fee.

The purchase dialog states the fee and the total before you pay, never after.

The purchase fee

The fee is max(5% of the amount, €0.80), charged on top of the credit you buy and shown before you pay. Buy €100 of credit and you are charged €105, of which €100 lands in the balance. Buy €10 and you are charged €10.80. Below roughly €16 the €0.80 floor is what binds; above it the 5% takes over.

Why a fee at purchase instead of a markup on inference: our published per-token price is exactly what gets debited, on our own models and on the resold ones alike. That is the property that lets you multiply quantities by rates and land on the amount we charged, and a markup buried in the per-token rate would destroy it. So the cost of taking a card payment is charged where it is incurred, at the purchase. Card processing carries a fixed cost per transaction, which is why the fee has a floor instead of being a flat percentage down to the cent.

A purchase produces an invoice carrying your organisation’s tax details, and the credit lands on the balance as soon as the payment succeeds.

Automatic top-up

Optional. Set a threshold and an amount, and when the balance falls below the threshold we buy that amount from the card on file.

Card only. Our Stripe account is Spanish, so the alternative would be SEPA Direct Debit, which settles in days, and a top-up that arrives three days after the balance hit zero is not a top-up. If your default payment method is not a card, the control is visible and disabled with the reason stated, never quietly missing.
A decline suspends it rather than retrying. We notify you, switch the feature off, and let the balance run down and refuse cleanly. Saving the setting again is the only way to re-arm it, deliberately: anything automatic there would be the retry loop we are avoiding.

Automatic top-up: a threshold, an amount, and a card. With no card on file the control stays visible and states why it is off.

When credit runs out

Before zero. Below your low balance threshold (€2 by default, and configurable) we send you an email.
At zero. A request that needs credit is refused with 402 and the code credits_exhausted, which is distinct from subscription_required and monthly_cap_reached so your client can tell the three apart and react to each differently.
What keeps working. Everything your plan covers. Only the credit funded part refuses, so a subscribed organisation that runs out of credit keeps full access to its flat tier.

Note: credits_exhausted on a frontier model while your own models keep answering is the designed behaviour, not a fault. One refusal on one model is not an outage. See Models.

Where you see the breakdown

The Credits section of the console has two tabs. The second one appears once credit is enabled for your organisation.

Balance. The balance, your thresholds, the top-up settings and the most recent movements. Each spend row carries the model, the amount charged, the balance after it, and the metered quantities: input tokens, cached input tokens, cache writes and output tokens. Purchase rows also carry the fee and the percentage it came from. Spend rows carry no fee at all, because there is no markup on consumption.

Private models. The live rate for each of the nine frontier models, which is the authoritative one, plus what each has cost you over a stated window. The window is echoed back so you read the period you actually got rather than the one you asked for, and it is computed from a daily rollup rather than from the last few movements. That matters as you grow: a fixed number of recent rows is a month for a quiet account and five minutes for a busy one, so a figure derived from them shrinks exactly as your traffic gets interesting. This view is your complete metered usage for the window, not a recent-activity sample, and it splits our own models from the resold ones.

The Private models tab of the Helmcode console: credit spent on resold models against credit spent on our own, the window stated as a number of charges between two dates, and a per-model breakdown with tokens, charges, share and cost. — Spend per model over a stated window, with our own models separated from the resold ones. The line above the table states the period and the number of charges in it.

Reconciling

Invoices and the statement answer different questions, and mixing them is the usual source of confusion.

An invoice is issued when you buy credit: the amount, the fee and tax. Consumption is never invoiced. It draws the balance down instead.
The statement is the record of that consumption. To check one charge, multiply each metered quantity by the published rate for its class and add the four together. That total is what was charged.

Two details make the arithmetic come out right:

All four token classes are listed, cache writes included. On Anthropic models a cache write is billed at its own rate, above the base input rate, so a check that ignores it lands under what we charged with nothing visible to explain the gap. See why Anthropic bills cache writes separately.
A charge belongs to the price version that produced it. When we re-price a model the old rate is closed and a successor opens, and historical charges are never recomputed at the new rate. A statement from two months ago still reconciles against the rate that was live then, while the rate that bills you today is always the one in the console.