Skip to main content
OneHot is prepaid. You buy credit, and all your work is paid from it: decisions, and Decision Lab work such as fine-tunes, prompt tuning, teacher labelling, evaluations, keep warm and dataset storage. Before work starts, OneHot holds credit for it. When the work ends, the hold is charged or released. Buy credit in Billing in the console.
This reads your balance and what holds credit. Use a full-access or read-only key from your personal workspace. In a shared organisation, a project key works as a developer and gets 403 role_forbidden. Use an admin key there. Pricing lists the standard prices. Metering says how a decision’s input is counted and priced.

​
Credit and holds

GET /v1/organization/wallet lists what holds credit under reservations. A released hold returns to the paid or promotional credit it came from. Promotional credit that has expired or been revoked stays gone after a release. A 402 insufficient_credit carries a credit detail. Its message says what the operation needs and how much is available.

​
Buy credit

Buy credit and set up automatic top-ups in Billing in the console. In a shared organisation, owners and billing members do this. An admin key can too. To buy credit, choose Top up, enter an amount, then choose Continue to checkout and pay on Stripe’s page. To set up automatic top-ups, choose Set up under Automatic top-ups and save a card:
  • Each top-up is at least the minimum_usd that /v1/organization/payments reports. It is in whole cents of USD, before tax.
  • Stripe adds any VAT or sales tax on top, from your billing address. A valid VAT number removes it where the reverse charge applies. Each purchase’s tax_usd is the tax its payment added.
  • Credit is posted only once the payment is verified. /v1/organization/payments lists your purchases. Invoices and receipts open from Billing in the console.
  • Each purchase’s amount_usd is the credit it bought, and origin is manual for a top-up you bought or automatic for an automatic top-up. Its status is credited, and credited_at set, once the credit is added.
  • Automatic top-ups need your explicit consent, a saved card, a settings revision and a monthly cap. Turning them off stops new charges. Charges already submitted are still reconciled.
  • Once they reach the monthly cap, before tax, automatic top-ups wait for the next calendar month, in UTC.
  • If an automatic top-up’s charge fails, or your bank asks to confirm it, automatic top-ups pause and we email the billing email. Billing shows them as Paused. Replace the card there to turn them on again. status on GET /v1/organization/automatic-topup gives the reason, such as card_declined.
Credit you buy and promotional credit expire after the periods in the terms. /v1/organization/payments gives each purchase’s expires_at. Once that has passed, it also gives the expired_usd the expiry removed. The same answer’s purchase_valid_days says how many days credit bought today lasts, counted from when it is added. It is null when such credit doesn’t expire. Promotional credit is spent first, the soonest to expire first, then the oldest purchase. While Credit reminders is on, we email a week before bought credit expires, and three days before starter credit expires, if some of it is left. Credit isn’t refunded, except as the terms say, for example when we charged you by mistake or more than once. Expired credit isn’t refunded. To ask for a refund, write to help@sqwish.ai from your account’s address. A waitlisted account holds no credit. Admission gives starter credit once per person and per email inbox, and its expiry counts from admission. Pricing gives the amount and how long it lasts.

​
Tier and limits

Your organisation’s tier sets its limits, and buying credit raises it (move up a tier). GET /v1/account returns tier, with its limits in effective_limits. All the account’s keys and browser sessions share those limits. next_tier names the next tier up and how much more credit reaches it. It is null when no purchase raises the tier. Tiers has the table of tiers, the credit that reaches each and the limits that grow with it.

​
Decision Lab costs

Read the pricing object from /v1/onehot before you submit work. A price of 0 charges nothing. Pricing lists the standard prices. A job’s charge reads reserved while its price is held, then charged or released. After training, a fine-tune’s new model is also scored on its dataset’s evaluation rows. That is charged as inference, unless training already answered every one.

​
Cap a price

Send the price you showed or agreed to, such as an estimate’s price_usd, as max_price_usd. It is a decimal string, like every USD amount you send. Work that would cost more is refused with 409 price_changed instead of being held. Its details give the new price and the most you agreed to pay.

​
Keep warm and storage

Keep warm is billed once per model, however many switches ask for it. Switching it on holds the first hour. Each hour keeps the price it was held at. At its end it is charged, and the next hour is held at the price in force. If an hour can’t be held, keep warm switches off on every switch that asks for that model. An email naming it goes to the billing email. A dataset of more than dataset_free_rows examples pays for storage. A day of storage is held when it is created or restored, or when added rows take it past that size. Without the credit, the dataset isn’t created, stays archived or takes no rows. storage_window shows the day held at present, at the price it was accepted at. Deleting the dataset stops the fee. A dataset whose next day can’t be held is archived. Its data is kept until you restore or delete it (rename, delete and restore). On a suspended account, keep warm switches off at once. Every dataset that pays for storage is archived at once, billing the minutes used. An account suspended for usage it owes keeps its work, so neither happens.

​
Low-balance alert

The low-balance alert is the available credit under which the billing email gets a reminder. Left empty, the platform’s default applies. Billing shows it under Spending, with what the account spent this calendar month, in UTC. Owners and billing members read and set it. The alert is a credit reminder. So it goes only while Credit reminders is on, in Account settings, or in Organisation settings for a shared organisation. When the available credit runs out completely, the billing email gets an email whatever that switch says. An account has no spending limit of its own. A shared organisation can give each of its projects a spending limit.

​
Referrals

Each person you refer can earn you one promotional reward of reward_usd. It comes with their qualifying purchase of at least minimum_purchase_usd. A referrer earns rewards for up to lifetime_limit people, for life. Share your referral link from Earn credits on the Billing page. It also shows the reward, the minimum purchase and how many rewards you have earned. Only a purchase in the referred person’s personal workspace counts, and the reward goes to your personal workspace. A purchase in a shared organisation never earns a reward. /v1/account reports all three under referrals. /v1/account/referrals shows the reward history. Each reward grant’s expires_at in /v1/organization/wallet says when it expires. Spent reward credit isn’t taken back from the referrer’s paid balance. A revoked reward still counts toward the lifetime limit.

​
USD amounts

Wallet balances, estimates, charge receipts and usage costs are exact USD decimal strings. Accounting amounts have nine places. Keep that precision: don’t convert money to binary floating point. USD amounts you send are decimal strings too, such as "2.500000000" for max_price_usd. A JSON number is refused with 422 invalid_request, whose details name the field. decision_price_nano is an exact integer string or null. Zero means free serving, and null means unpriced.