Billing & credit
Prepaid. Every request is priced at the moment it runs from the model's list price per million tokens, metered per request, and settled into an append-only ledger every minute.
Checking payment availability…
What is billed
Input tokens, cached input tokens (at the lower cached rate), and output tokens, each at the model's price per million. Failed requests that never reached the model cost nothing; interrupted streams cost only the tokens delivered. usage.cost in every response is the exact amount in USD.
usage.cost_details splits the charge by unit (input_tokens, output_tokens, reasoning_tokens …). A request never costs more than it reserved from max_tokens: when the model writes past it (reasoning models can), usage.platform_discount is the part we do not charge, so usage.cost = tokens × price − platform_discount. All three are numbers in USD.
Failures, interruptions and rounding
Rejected before the model runs — bad key, no balance, a blocking budget, a rate limit, an unsupported parameter — and the request costs nothing; it appears in the logs marked not billable. A platform-side failure after the model ran is absorbed by us, not charged to you.
An interrupted stream is charged for what was delivered: the input you sent plus the output tokens that actually reached your client before the connection ended. Such a request is recorded with status partial and the same per-line billing detail as a successful one, so you can see exactly which tokens were charged. Cancelling a stream yourself works the same way.
Prices are computed in nano-dollars (10⁻⁹ USD) and the ledger is kept in micro-dollars (10⁻⁶ USD). The sub-micro remainder from each settlement is carried forward to the next one rather than discarded, so a long run of very small requests is charged the same total as one large request for the same tokens.
Trace each charge
Open a request log and select Billing to see the usage source, quantities, rates, context tiers and exact line amounts. Expand a price row to inspect its effective period and change note, even after the price expires. Estimated usage is marked explicitly; historical records without a price link still retain their charged quantities and amounts.
Context pricing
Some models publish different rates by input context length. Fresh and cached input tokens together choose one interval; all usage units use the applicable rates for that interval. The lower bound is included and the upper bound is excluded: 32,000 tokens belongs to [32,000, 128,000). See the model detail page for every published rate. Browse models
Balance and credit buckets
available = ledger − pending usage − reserved deduction order: credit expiring soonest → promotional / trial → paid
Subscription purchase and limits
Only paid wallet credit can purchase a plan. Unpaid checkouts can be cancelled and expire after 24 hours. For a plan with overflow=block, allowed models use subscription quota even if wallet-first is selected. Quota checks use settled usage. Before asynchronous settlement catches up (normally about two minutes), additional requests may be accepted. Their excess cost becomes debt, reduces available balance, and is repaid from your next top-up. This is not a hard spending cap.
When the balance reaches zero
New requests return 402 insufficient_balance; in-flight requests finish. Top up from Billing by card, Alipay or WeChat Pay, charged in US dollars: credit is added the moment the payment is confirmed and blocked requests resume within five seconds. Receipts are available for every payment, and the whole ledger exports as CSV.
Debt and reconciliation
If in-flight usage exceeds your credit, the uncovered amount accumulates as debt across settlement runs. Your next top-up pays off that debt first. Reconciliation uses UTC hourly boundaries and waits for unfinished settlement before reporting an hourly difference.
Seeing where money goes
Usage in the console (and GET /projects/{id}/usage) breaks spend down by model, key and day, and agrees to the cent with the request log and the ledger: the three are reconciled daily.
Owners, admins, billing admins and auditors can switch Usage from this project to the whole company, grouped by project, member (whoever created the key), key, model, tag or end user, and export it as CSV (GET /orgs/{id}/usage with groupBy=project, member, key, model, user or tag:<key>). Billing shows this month’s spend by project, and monthly statements list usage by project and by model, ready to allocate to teams. The ledger page merges usage per hour, project and model; its CSV export does the same, and a detailed export lists every entry.
Bank transfer and contract credit
A company that pays by bank transfer under a contract is credited by GridPort as contract credit, carrying the contract or transfer reference; the ledger and the statement show it as a contract prepayment with that reference. The contract can also set the organization’s rate-limit tier. Billing is prepaid: invoices and postpaid terms are not offered yet. Receipts and monthly statements carry the company name, address and tax ID from the billing profile.
Finance roles
Billing admins top up and redeem codes, edit the billing profile and automatic top-up, set the organization’s and projects’ monthly budgets and the balance alert lines, read the whole company’s usage and the statements, and create and download billing evidence. They cannot create API keys or read request logs.
Auditors read usage (the whole company’s too), billing, statements, request logs and the audit log, and create and download billing evidence. Admins set project budgets, read the whole company’s usage and export evidence, but do not top up or change the organization budget or the alert lines. Billing evidence lists request metadata — time, project, key, model, tokens, price and amount — never prompts or outputs. Members, roles and project access
Who is told
Each person is told once per notice, in the console and by email, as their own notification settings allow; security and account messages always go out. A budget notice is sent once per budget (organization, project or key), period and threshold.
Subscriptions and funding order
Buy a fixed-term plan with checkout or wallet credit. Each purchase keeps its own price, quota, model restrictions and reset schedule. Subscription quota is used first by default; organization settings can choose wallet first. Subscription quota cannot pay for another subscription.
Daily resets use midnight UTC, weekly resets Monday, monthly resets the first day of the month. Period/never plans receive one grant for the purchased term. Unused quota expires on reset or term end. Cancellation takes effect immediately without a refund; purchases do not auto-renew.
Request billing details identify every subscription or wallet bucket used. The wallet overflow policy uses wallet credit after quota runs out; the block policy returns subscription_exhausted when applicable quota is exhausted, even if the wallet has credit. Quota is only available for the plan’s allowed models.
Project webhooks
In project Settings → Webhooks, register a public HTTPS endpoint and select the events to receive. Copy the signing secret when creating or rotating it; it is not shown again.
From code: POST /projects/{id}/webhooks with an access token that has projects:write (GET, PATCH with rotate_secret, DELETE alike). POST /projects/{id}/webhooks/{webhook_id}/test sends a signed webhook.test event, and GET …/deliveries lists every attempt with its status. While developing, expose the receiver on your machine through an HTTPS tunnel (for example ngrok or cloudflared) and register that address. Subscribing to payment, credit, statement and balance events also needs billing:read on the token (or a role that reads billing).
payment.succeeded, credit.added, statement.ready and the balance.* events carry amounts. Adding them to a webhook, or changing the URL of a webhook that receives them, needs billing:read on the token (or a role that reads billing); in GET …/deliveries their data shows as { "redacted": true } to callers without it.
Payloads contain id, type, created_at, project_id and data. The x-tf-signature header reads t=<unix seconds>,v1=<hex signature>: verify the signature as HMAC-SHA256 of timestamp + "." + the raw request body, using your secret. Accept only recent timestamps and deduplicate IDs; deliveries are at least once. x-tf-event identifies the event type.
Delivery runs every ten seconds, with at most five attempts. Consecutive failures disable a webhook after twenty attempts. Each budget event is sent once per budget, period and threshold; model health at most once per fifteen minutes, and only when no healthy route is left for a model you used in the last day. Redirects and private addresses are rejected.