Tenvor documentation

Reservations and receipts

An estimate helps you choose a workload. A reservation holds funds for admitted work. The authenticated result and receipt explain the final outcome and charge.

Content checked . Live limits and prices can change.

Before sending: estimate and reserve

Check your available balance in Console and the current rates and request minimums in Pricing. The published calculator is an estimate; the server captures the request's applicable price when admitting it.

Admission reserves for the request's bounded input and maximum output under the applicable minimum and tariff. It cannot assume a future cache hit. A reservation is a hold, not proof that the request completed or that the whole amount is the final charge.

After completion: inspect the receipt

  1. Match the request's time window and selected model to Console Activity.
  2. Inspect the completed outcome, usage, actual assurance tier and charged amount. Successful API results include standard usage and Tenvor billing metadata.
  3. Distinguish full input, cached input and output usage where reported. Read the receipt's estimation indicators; a token field is not by itself a promise of exact tokenizer measurement.
  4. Check that any pending reservation has reached the state indicated by the authenticated outcome. If it remains unresolved, follow recovery instead of assuming success or submitting again.

Current prices and the actual receipt govern the monetary amounts. This guide introduces no new charge, supplier penalty, refund guarantee or Fast-service multiplier.

On timeout or interruption: reconcile first

A disconnect, HTTP 503 or HTTP 504 alone does not establish whether work was admitted or whether a charge is due. Keep the request reference privately, check the authenticated result and account activity, and reconcile accepted work before retrying. Do not turn a partial answer into a successful completion.

A cancellation proven to be still pending can release its reservation. Accepted execution can retain recovery authority after the original connection ends. A client timeout is therefore not evidence that the server canceled the work.

Keep the request reference private and use the authenticated recovery steps. A second POST without an idempotency key creates another request. For unresolved billing, use the current service-credit policy and provide only the minimum private account evidence through its support process.