#Balance and prices

#The balance

The API balance is credits in a separate wallet. It cannot be spent on the 6io site, and it is topped up with site credits. Amounts in answers are decimal strings with twelve digits after the point, for example "0.013272000000".

curl https://api.6io.io/v1/balance -H "Authorization: Bearer sixio_sk_..."

{
  "currency": "credits",
  "balance": "9.986728000000",
  "reserved": "0.000000000000",
  "available": "9.986728000000"
}

• balance is how many credits are on the account;
• reserved is how much is set aside now for running requests;
• available is how much can be spent on new requests (balance minus reserved).

#How to top up

Only with site credits: in the console, on the Overview tab, enter how many credits to transfer. Credits are bought on the 6io site. One site credit gives one API credit.

• The transfer is available after the first payment on the site. Bonus credits from registration cannot be transferred by themselves: before a payment the console answers payment_required.
• The transfer is one operation: the credits are taken and added together, or nothing happens.
• The amount is not returned to site credits.

#How the price is calculated

The price in credits = the cost at the provider in dollars × a multiplier (credits per dollar) × (1 + the group markup). 6io sets the multiplier and the markup, they are not shown separately: the catalog's pricing already includes both. The amount is rounded once, at the end, to twelve digits, not for every token.

For the sixio group the price of a model is the 6io price for your input (length, resolution, number of images) with the group markup.

The multiplier and the markup are remembered at the moment a request is accepted. If we change them later, requests already accepted are not recalculated.

#How a paid request goes

1. The reserve. Before sending to the provider, 6io sets aside an estimate: the size of your request plus max_tokens (a default value is taken if it is not set). If the available funds are not enough, the answer is 402 insufficient_funds, and the request never reaches the provider.
2. A charge by the actual cost. After the answer the reserve is replaced by the real amount: what the request actually cost at the provider. The difference goes back to the balance.

An example. You sent a chat request. The reserve is 0.5 credits. The answer is short and cost 0.013272 credits. The balance dropped by 0.013272, and the other 0.486728 is available again.

For fal models the final amount comes from fal's data on the units actually billed (they appear a few minutes later), for sixio exactly the reserve is charged.

#If the money was not enough

The actual cost is sometimes higher than the reserve, for example with a very long answer. Then the whole actual cost is charged, and the balance may go negative. While it is negative, new paid requests are closed (402 insufficient_funds). Requests already sent to the provider keep running and are accounted for. Top up the balance to continue.

#The state of a request

GET /v1/requests/{id} shows the state of a request and its money. Take the ID from the X-Sixio-Request-Id header or from the id field of the answer: it is a string like req_…, not a number.

#What happens to the money if a request fails

If the amount of a request could not be confirmed automatically within a day, it goes to manual review. The reserve stays meanwhile, and an administrator decides. What to do in such cases is in Retries and failures.