Prijzen & facturering
Al het API-gebruik wordt betaald uit één GeraiPoints-saldo (GP). Geen abonnement of maandquotum — je betaalt alleen voor de tokens die je echt gebruikt.
GeraiPoints
- Waardeer je saldo op via de pagina Opwaarderen. Het saldo verloopt niet.
- De gebruiksgeschiedenis per request en per key vind je in het Dashboard.
Hoe de kosten worden berekend
De kosten van elke request worden berekend uit de usage die het model rapporteert, tegen het tarief per 1 miljoen tokens van dat model, en naar boven afgerond op hele GP.
biaya = ceil(
input_tokens / 1000000 × tarif_input
+ output_tokens / 1000000 × tarif_output
+ cache_read_tokens / 1000000 × tarif_cache_read
+ cache_write_tokens / 1000000 × tarif_cache_write
)
tagihan = max(biaya, minimum_per_request)Voorbeeld met het huidige tarief van claude-sonnet-5:
| Onderdeel | Waarde |
|---|---|
| Inputtarief | 2.300 GP / 1M token |
| Outputtarief | 11.600 GP / 1M token |
| Minimum per request | 50 GP |
| Gebruik (voorbeeld) | 20.000 input + 1.000 output |
| Gefactureerd | 58 GP |
De bedragen komen uit de actuele catalogus en kunnen veranderen; het officiële tarief per model staat op de prijzenpagina.
Per token of per request?
Alle modellen worden per token gefactureerd, met een klein minimum per request. De uitzondering is wanneer er een actie met vast tarief loopt: modellen met een actielabel worden dan per request tegen een vast bedrag gefactureerd, gelijk aan hun minimum, ongeacht het aantal tokens.
Cacheprijzen
Modellen die prompt caching ondersteunen, hebben een apart tarief voor tokens die uit de cache worden gelezen (cache read) en, bij sommige modellen, voor tokens die naar de cache worden geschreven (cache write). Cache-read-tokens zijn veel goedkoper dan gewone input, dus het gelijk houden van het begin van je prompt (systeemprompt, bestandsinhoud) bespaart kosten. Het cachetarief per model staat op de prijzenpagina.
Minimum per request & saldocontrole
Elk model heeft een minimum per request (bodem). Kleine requests waarvan de tokenkosten onder die bodem liggen, worden gefactureerd voor het bodembedrag — dit komt niet bovenop de tokenkosten.
- Voordat de request wordt doorgestuurd, controleert de server je saldo en reserveert hij de geschatte kosten. Bij onvoldoende saldo volgt 402
insufficient_quota, zonder kosten. - De definitieve afschrijving wordt na het volledig versturen van het antwoord berekend, op basis van het werkelijke gebruik.
Geannuleerde requests
Verzoeken die aan de kant van de koper worden geannuleerd (time-out van de app, stopknop, verbroken verbinding) voordat het antwoord komt, worden in rekening gebracht op basis van de kosten die de AI-server werkelijk rekent, tegen de geldende tarieven van het model; ze worden niet in rekening gebracht als de AI-server niets rekent. De eerste afschrijving kan hoger zijn, het verschil komt automatisch terug op het saldo. Lege uitvoer wordt alleen gecompenseerd bij storingen aan onze kant (leeg antwoord/fout van de server, of ≥60 seconden geen uitvoer). Geldt vanaf 1 november 2026.
Wil je niet betalen voor afgebroken requests, stel dan een timeout van minstens 300 seconden in en zet stream aan. Handleidingen per tool staan in Instellingen agentic tools.
Wanneer wel en niet gefactureerd
| Situatie | Gefactureerd? |
|---|---|
| Antwoord voltooid | Ja — volgens gebruik |
| Fout op onze server voordat er een antwoord is (502/503) | Nee |
| Geweigerd vóór verwerking (400/401/402/403/404) | Nee |
| Door jou afgebroken (timeout in je app, stopknop, verbroken verbinding) | Ja — het gebruik tot dat moment |
| Automatische nieuwe pogingen (retry) | Ja — elke poging is een nieuwe request |