# Credits and pricing

> How Qsolve prices a run: the quote and hold formulas, how charges and returns are settled, spend limits and monthly budgets, with worked examples in credits.

Source: https://qsolve.omlabs.co/docs/use/credits-and-pricing
Updated: 2026-11-12

One credit is one US dollar. Before a run starts you see a **quote** (the expected cost). While it executes, Qsolve **holds** its worst-case price from your balance. When it ends you are **charged** for what it used and the rest is **returned**. A per-run **spend limit** and an optional **monthly budget** cap what you can spend.

```
balance 100.00
  quote ........ 5.46   expected cost, shown before anything happens
  hold ......... 8.20   taken from the balance when the run is queued
balance 91.80           while the run executes
  charge ....... 5.12   what the run actually used
  returned ..... 3.08   hold minus charge
balance 94.88           after the run settles
```

This is the single-circuit IBM example worked out below. A run whose hold is more than your balance fails before it starts, with nothing held.

## Free credits

Each new account receives 100 credits once its email is confirmed, one grant per person (Gmail dots and `+tags` do not create a new grant). The web app has no purchase screen. If you need more credits, ask the Qsolve team.

## How a quote is computed

Qsolve asks the workflow how many qubits, circuits and shots your input needs on the chosen target, then prices that. Rates can change, so treat the figures below as the current defaults and the quote on screen as the authority.

### Simulators

```
cost = per_run × complexity factor  +  per_million_shots × shots / 1,000,000
```

| Target | `per_run` | `per_million_shots` |
|---|---|---|
| CPU simulator | 0.01 | 0.05 |
| GPU simulator | 0.05 | 0.10 |

The **complexity factor** reflects how heavy the workflow's classical computation is, as the workflow declares it: 1 for low, 2 for medium, 5 for high. On simulators the hold equals the quote.

### IBM quantum computer

```
quantum seconds = 0.015 × circuits  +  0.00025 × shots
cost            = 3.84  +  1.60 × quantum seconds
```

Every quantum-computer job pays a fixed 3.84 credits (about 2.4 seconds of machine time), then 1.60 credits per quantum second. Seconds are estimated at 15 milliseconds per circuit and 0.25 milliseconds per shot. The hold is 1.5 times the quote, because the provider meters the real quantum time and it can differ from the estimate.

Quotes round up to six decimal places and are never below 0.0001 credits. The app shows small amounts rounded, for example 0.0102 as 0.01.

## Worked examples

These use the default rates and the circuits and shots shown. Your run's own estimate is on the run page under **Execution**.

| Run | Calculation | Quote | Hold |
|---|---|---|---|
| CPU simulator, low complexity, 1 circuit, 4,000 shots | 0.01 + 0.05 × 0.004 | 0.0102 | 0.0102 |
| IBM, 1 circuit, 4,000 shots | 3.84 + 1.60 × (0.015 + 0.00025 × 4,000 = 1.015 s) | 5.46 | 8.20 |

A successful simulator run is charged the quote. A quantum computer run is charged 3.84 plus 1.60 for each quantum second the provider reports. If the IBM run above used 0.8 quantum seconds, it costs 3.84 + 1.60 × 0.8 = 5.12 credits, and 8.20 − 5.12 = 3.08 credits return to you.

## Spend limit

The **Spend limit** on the run form is the most you will pay for one run, between 0.0001 and 1,000 credits. The form suggests ten times the workflow's typical cost. Qsolve compares it with the **hold**, not the quote:

- Hold within your limit: the credits are held and the run is queued.
- Hold above your limit: the run waits in **Needs your OK** with nothing held. Choose **Run for up to X credits** (the hold, rounded up to the cent) or **Cancel**. If you do nothing it expires after 15 minutes and nothing is charged.

With a limit of 5, the single-circuit IBM run above has a hold of 8.20, so it waits for your OK. The same run on the CPU simulator starts immediately.

## Other limits

| Limit | Value | What happens |
|---|---|---|
| Per-run cap | 150 credits | A run with a hold above it is refused: "This run is larger than the per-run limit." Nothing is held |
| Runs at once | 3 per account | A further run is refused until one finishes |
| Monthly budget | None until the account owner sets one | See below |

## Monthly budget

The account owner can set a **monthly cap** on **Usage** (**Set a monthly cap**, **Change cap**, **Remove**), from 0.01 to 1,000,000 credits per UTC calendar month. Other members cannot change it.

Spend in a month counts what finished runs were charged plus what active runs hold. A run counts in the month it was created. A run is refused if the month's spend has already reached the cap, or if spend plus its hold would pass it: "Monthly budget reached: 15 of 20 credits used this month; this run needs 8.20." Nothing is held.

## Hardware cases of a workflow

If you are the developer of a workflow that lists `hardware_cases`, the cases run from your own account. You see each price before anything starts, you confirm once, and the credits are held and settled like any quantum run. Your free credits can pay for the small cases; a larger case may need more credits than you have. The per-run cap also applies, so a case whose held amount would pass it cannot be run. See [Benchmarks](/docs/build/benchmarks).

## What you pay when a run does not succeed

| Outcome | Charged |
|---|---|
| Fails before it starts: invalid input, low balance, over a cap, device unavailable, platform error | Nothing |
| You press **Stop** before it starts | Nothing, and the hold is released |
| You press **Stop** while it executes | What it already used |
| Time limit, out of memory, or the workflow crashes | What it already used |
| Needs more than its hold ("budget exhausted") | What it used; the run is stopped at the hold |
| Integrity mismatch (it used more quantum work than its result accounts for) | What it used |

The charge never exceeds the hold. A run is metered while it executes and stopped once its cost would pass the hold.