Billing and credits

A workspace pays for its requests from a prepaid balance of credit in US dollars. Each request is charged at the price bound when it was accepted, and the charge is taken from the balance; nothing is billed afterwards. The Billing screen in the Console holds the plan, the balance, top-ups, budgets and alerts, receipts and the balance's history. The API writes every amount in micro-dollars, millionths of a dollar.

Owners, admins and billing members change the plan, top up, and set budgets and alerts. Developers read Billing; its controls say so beside them. While a card dispute freezes the workspace, billing changes wait until it is decided.

The request-data policy also applies to requests against customer-owned models. Customer-owned model weights will never be used to train other models on any plan.

The paid plans' monthly prices and the credits each includes are on the Pricing page. Included credits are used at the same token prices as other credits and expire at the end of each monthly period. Credits you top up separately are not affected.

• Choose a plan in Billing: a paid plan opens Stripe Checkout and returns to the Console, and the plan starts when Stripe confirms the payment.
• Cancel at the period's end on the Billing screen, under Plan: the subscription stops renewing and the plan holds until then. Resume, in the same place, undoes it before the period ends.
• Manage card and invoices opens Stripe's billing page once a card has paid in the workspace. That page changes the card on file and shows the invoices; a plan is never canceled or changed there, only on the Billing screen.
• A lapsed subscription to the higher paid plan pauses the workspace: requests are refused with 403 plan_lapsed until an owner pays, or acknowledges the free plan's request-data policy, and the policies hold meanwhile.

On Free, Billing shows Free, Pro and Business side by side at the top, billed monthly or yearly: each plan's fee, its weekly pool of included credit with an example of what it buys of one model's output, its models, the Router, Guardrails, Knowledge and deploying your own models, all read from the plans' published fees and terms. Choose Pro or Choose Business opens Stripe Checkout; a plan that cannot be bought yet says why beside its button.

• While a workspace is on Free, a line under the Console's header says what a plan adds. Owners and admins see Choose a plan, which opens Billing's plans; other members see that an owner or admin can choose. It can be hidden until you next sign in, and it is gone once the workspace is on a paid plan.
• The first time an owner or admin opens a workspace on Free, the Console shows the same plans in a dialog, with Continue on Free as a choice equal to the others. It is shown once per workspace in that browser, and closing it leaves the Console as it was.
• A model or feature the workspace's plan does not include says so beside it: "Choose a plan to use this model" beside a model in Models, and "Needs the Pro plan" (or the plan that includes it) beside each control the plan holds on the Router, Guardrails and Knowledge screens, with Choose a plan at the top of the page. Below the plan, guardrails keep enforcing as they are and Knowledge bases stay readable and can be exported and deleted. A request that names a model or feature the plan leaves out is refused with 403 model_not_on_plan (Errors).
• On Pro and Business, Billing shows this week's included credit: what is used and left of the weekly pool, when it refreshes, an example of what it buys, and that it does not roll over. At 75% of the week's pool, and when it is spent, Billing says so; once spent, it names the three ways on: wait for the refresh, carry on from credit you top up with auto reload, or a larger plan. The out-of-credit dialog says when the next pool starts.

On the lower paid plan and the higher paid plan, request-data training is off by default and an owner or admin may switch it on; the change is recorded and shown before any request. A plan's lapse never changes the policy. What the policies mean is on Data handling.

Credit is drawn soonest-expiring first, so included credits are used before credit you paid for. The owner and every billing member are told before purchased credit expires. A charge is a ledger entry against the credit, and a correction is a new entry, never an edit; Billing shows each UTC day's closing balance with what was added and spent that day.

Top up opens Stripe Checkout for the amount you choose, in whole cents, within the least and most the Billing screen shows. Stripe computes the tax at Checkout, and a business may give its tax number there. Credit is added only once Stripe confirms the payment, never on the way back from Checkout alone, and a receipt is made with it. A press that is repeated opens Checkout once.

Cards are the payment method on every plan. Which methods a workspace may use is decided by the workspace's own country: a business's country of registration, or for a consumer's workspace its owner's Country.

A request whose workspace has no credit left is refused with 402 insufficient_credit, and Billing says the balance ran out. A top-up lifts it at once, and so does a payment of auto reload. The error carries auto_reload, the workspace's auto reload, so a client knows whether credit is on its way:

00000000000000000000000000000000000000001{2  "error": {3    "message": "The workspace has no credit left. Its auto reload is adding credit from the card on file; retry in a minute.",4    "type": "insufficient_credit",5    "param": null,6    "code": "insufficient_credit",7    "auto_reload": "on"8  }9}

A 402 for a budget at its limit (budget_exceeded) carries no auto_reload: a payment never lifts a budget.

Auto reload adds credit from the card on file when the balance falls under a line you choose. It is off unless the workspace's owner turns it on in Billing; a saved card alone never turns it on. Its settings:

• The line: when the balance falls under it, a reload is made. Between $1.00 and $5,000.00, in whole cents.
• The amount each reload adds, within the top-up bounds, $5.00 to $5,000.00. The card is charged the amount plus tax, worked out as at Checkout for the workspace's billing address.
• A monthly limit: the most auto reload adds in a calendar month (UTC), at least one reload's amount. Left empty, it is the larger of the plan's monthly fee and one reload.

• It charges the card a top-up saved at Checkout, or the default card set in Manage card and invoices, so a workspace needs one paid top-up first.
• HIPS checks the balance every minute. A reload is booked as any purchase: a receipt of kind auto reload, sent to the owner, admins and billing members, and purchased credit that expires 12 months after the payment.
• A month that reaches its limit adds nothing more until the next month, and the owner, admins and billing members are told once. Raising the limit lets the next reload through at once.
• If a payment fails (the card is declined, the card asks its holder to confirm the payment, no card is on file), HIPS turns auto reload off and tells the owner, admins and billing members. It never tries the card again on its own; the owner turns it on again once the card is right.
• If the payment processor reports a payment that does not match what auto reload asked for, no credit is booked for it, auto reload is turned off the same way (its reason mismatch), and HIPS reviews that payment and books or refunds it. A second payment taken for a reload already paid is refunded in full at once, and auto reload is turned off with the same reason.
• A card dispute's freeze turns auto reload off too, and so does a transfer of the workspace's ownership: it charged the card under the former owner's choice, so the new owner turns it on again with their own.
• An owner, admin or billing member can turn it off at any time, a frozen workspace's included. Turning it on or changing it is the owner's.

For a consumer's workspace, turning auto reload on asks first, in an unticked box, that HIPS make the credits of each reload available at once, and for the acknowledgment that a withdrawal from a reload costs what HIPS supplied until then and that the right of withdrawal from a reload ends once all its credits are used (the Terms of Service, section 27.6). HIPS confirms the request by email when auto reload is turned on and with each reload's receipt; it stands while auto reload stays on, and is asked again each time it is turned on.

• A monthly spend budget for the workspace, with its action when reached. Notify: the recipients hear once per month and requests continue. Pause: once the month's spend reaches the budget, new requests are refused with 402 budget_exceeded until the next month (UTC) or a higher budget; spend is checked each minute.
• Alert thresholds: up to five whole percentages of the budget, from 1 to 100; each crossing is notified once per month.
• A low-balance alert line, with the default in place while it is empty; 0 turns it off.
• The recipients: the members who receive the notices.

The workspace budget is a budget guardrail now: the same limit, reset each month, its Pause action the guardrail's block (The settings you already had). Budget guardrails can also give a member, an API key or a tool its own budget, and What a client receives shows the 402 answer in full.

Every request is priced at the market today. No stable price is in force yet: a request that asks for pricing_mode: stable is refused with 400 stable_price_not_in_force, and Billing's market and stable comparison shows that no offer is published. A stable price, once offered, covers a stated period and workload at a rate fixed when it is accepted; it is a price, not a capacity guarantee.

• Each model has a published rate per unit and pool; a request pays that rate. The rates and their history are on the Pricing page and each model's page.
• The price binds when the request is accepted and holds for every attempt, retries included, so a price change during a request never changes what it pays. The answer names its quote in x-hips-quote and its cost in x-hips-cost-micros; a streamed answer carries its cost in the hips object of its final usage chunk.
• Cached input tokens have their own rate, by default 10% of the input rate, and only hits HIPS can verify are billed at it; the Prompt caching guide has the rule.
• A batch costs 50% less than the on-demand rate of the same model, pool and unit, the cached rate included.
• What an attempt that fails, is interrupted or is retried is charged is on the retries and billing outcomes page.

Stored models and a stopped deployment's weights cost $0.10 per GB-month while they are kept. Storage is counted by the hour, and each month's amount is taken from the balance once the month ends.

Receipts lists each payment with its number, date, amount, tax, total, method and status, the hosted invoice and the PDF, and refunds against their receipt, filtered by kind.

A card dispute freezes the workspace: requests are refused with 403 workspace_paused, billing changes and payments wait until the dispute is decided, and receipts stay readable. While the dispute is open, the disputed amount is taken out of the balance; it is given back if the dispute is won, and kept out if it is lost. HIPS lifts the freeze once the dispute is decided.