Each capability publishes its `credits_per_request` cost. A capability whose price depends on its input publishes a range instead, shown as `N-M credits / request`; the price for the submitted input is what is charged. Check the applicable price before submitting a request.

A price can be a part of a credit, such as `0.25 credits / request`. Credits are bought and held in whole numbers; each part-credit request is charged exactly, and your balance shows what it has used, for example `9.75` after one `0.25` request from `10`. Whole credits come off the balance each time the parts add up to one. A completed job's `billing.credits_charged` and `billing.credits_per_unit` report the exact amounts, so they can be decimals.

## When credits are charged

Credits are charged once when a logical job completes successfully.

The completed response also reports `billing.settlement`. A zero charge with a
positive published rate is intentional when settlement is
`included_subscription` or `out_of_band_contract`; it is not evidence that the
capability is free. `zero_charge_requires_review` indicates an unexpected settlement state; contact Upscrape support if it appears in a response.

The following do not add another capability charge:

- a pending response;
- polling a job;
- automatic retries;
- a failed job;
- an idempotent replay of the same logical request.

Credit reservations prevent concurrent requests from overspending the same remaining balance. A zero balance blocks new execution.

## Cap the cost of a request

`POST /execute` accepts an optional `max_credits` body field or `X-Max-Credits` header. A job whose published price is higher is refused with `credit_limit_exceeded` before it is accepted, so nothing is charged. MCP tools accept the same ceiling as `max_credits`. The ceiling is a whole number; a part-credit price counts as the next whole credit for this check, so `max_credits: 1` accepts a `0.25`-credit request.

## Find the cost

The public platform page displays the credit cost next to every capability. The value comes from the same published capability contract used during execution, not from page-specific copy.

## Wait limits

REST accepts `Prefer: wait=N` with a maximum of 30 seconds. The wait is only a convenience for fast jobs; longer work continues durably and should be polled by job ID.

MCP waits for up to 55 seconds by default. Work that remains active returns a pending job ID for later retrieval.

## Capability timeouts

Each capability publishes a `timeout_ms` limit. That execution deadline is distinct from the HTTP wait window. Ending an HTTP wait does not mean the request timed out, and increasing `Prefer: wait` cannot extend the capability's published execution timeout.

## Requests at a time

A prepaid account runs up to 3 requests at a time. Buying a credit pack raises that for good: the $49 pack to 5, the $149 pack to 10 and the $499 pack to 20. Requests beyond the limit wait in line and start as earlier ones finish; with `Prefer: wait` they may come back as `202` with a `poll_url`. Custom plans set their own limit.

## Rate limits

Rate limits apply to authenticated API and MCP traffic, per key and across all of an account's keys together. An account holds at most 25 active API keys. A limited request returns HTTP `429` with both `Retry-After` and `retry_after_ms`. Respect the advertised delay rather than using a fixed aggressive retry interval.