# Pricing

> How credits work, where to read prices, how to estimate your own request and what a job is charged.

Every task is paid in **credits** of one credit type (`credit_type`). Prices can change, so read
them live.

- **What every task costs, per option:** `GET /v1/pricing` (any valid key; no scope needed).
  `GET /v1/pricing?task=image.generate` answers one task.
- **What YOUR request costs:** `POST /v1/tasks/{name}/estimate` with the body you would submit.
  It holds nothing, and answers the most that request can cost (`ceiling`).

## What sets a price

A task's price is adjusted by the options you choose:

- **Options.** Some option values change the price (for example a higher `resolution`). Each
  `GET /v1/pricing` entry lists the options that do in `prices[]` (`{options, credits,
  credit_type}`), and the ones that do not in `unchanged`.
- **Counts.** A task that makes several outputs (`image_count`) is priced per output: the entry's
  `per` names the count, and each `prices[]` row is the price of one.
- **List lengths.** A task priced by how many items you send (`images` of a moodboard) lists the
  price at each length in `sizes`.
- **The input.** Which image or record you send does not change a price, with three exceptions the
  entry states in `rule` (and prices its `example` request): a shoot is priced per photo it plans
  (products × looks × models × views), an edit can cost differently depending on where the image
  you send was made, and a task that reads a record (a fabric's colours, a range plan's looks) is
  priced by what the record holds. For these, `/estimate` is the price of your request.
- **Tasks without a charge** answer `credits: 0` and no credit type: `credit_type` is `null` (in `/v1/pricing`,
  `/estimate` and `/v1/account/usage` alike).

## Credits

A task is paid in one credit type (`credit_type` — it is in every
`GET /v1/pricing` row and in every `/estimate` answer). The values and what each is spent on:
`GET /v1/vocab/credit_type`.

Your balance, one entry per credit type: `GET /v1/account/balance`. Each entry's `remaining` is
what you can spend now (a job asking for more is refused), and `expiring` lists when your credits
run out, one entry per batch in the order they are spent:

```json
{ "balances": [
    { "credit_type": "<credit type>", "remaining": <credits>,
      "expiring": [ { "credits": <credits>, "at": "2026-10-31T23:59:59Z" } ] } ],
  "as_of": "2026-10-05T12:00:00Z" }
```

Every credit type (`GET /v1/vocab/credit_type`) is listed, with `remaining` `0` when you have none. On a team, `remaining` also
respects your own share of the team's credits, so the `expiring` entries need not add up to it.

- A plan's credits renew each billing period and are used within it.
- A credit pack's credits end on the pack's own date.
- Credits are spent in this order: your own credits before your team's, a plan's credits before a
  pack's, and among those the ones that run out soonest first.

## What is charged

- Submitting a job **holds** the estimate (a ceiling): the response's `X-Refabric-Credits` header is
  the amount held and `X-Refabric-Credit-Type` its credit type ([Jobs](https://docs.refabric.com/task-apis/calling-tasks/asynchronous-jobs#credits)).
- Only what is delivered is charged; the rest of the hold comes back when the job ends, whether it
  succeeded, failed or was cancelled.
- What you spent, per task and per key: `GET /v1/account/usage` ([Usage](https://docs.refabric.com/api-reference/platform/tasks/read-your-usage)).
- A price change shows in `GET /v1/pricing` and `/estimate` at once. A changed price is listed in
  the [changelog](https://docs.refabric.com/changelog).