Billing

Introduction

This page explains how billing works on Pasqal Cloud:

• how your project’s credits are tracked,
• how a job’s cost is estimated at submission,
• how the real cost is consumed when the job completes,
• and how billing behaves under third-party cloud integrations (Google Cloud, Azure, OVHcloud, Scaleway).

There are two billing models:

• Credit pools for direct Pasqal Cloud access
• Pay-as-you-go for third-party integrations (Google Cloud, Azure, OVHcloud, Scaleway)

Credit Pool Model

Pasqal Cloud projects are billed through contracts, with separate pricing for QPU and emulator backends. Credits are added through credit pools, which may have an expiration date. The job lifecycle drives reservation and consumption.

Key concepts

Contract

A contract defines what a project can consume and under which rules: pricing, available credits, and expiration dates. Every project on Pasqal Cloud is attached to a contract.

Pricing per backend

Each contract has two independent pricing models:

• Emulator: applies to EMU_MPS, EMU_SV, EMU_TN
• QPU: applies to jobs running on a Quantum Processing Unit

Note

EMU_FREE is free and does not consume credits.

A pricing model is defined by:

Parameter	Description	Possible values
metric	The unit on which billing is based	hour or shot
price	Number of credits per metric unit	Numeric value

Examples:

• With metric = hour and price = 1, 1 credit buys 1 hour of execution on the selected backend (QPU or emulator).
• With metric = shot and price = 1, 1 credit buys 1 shot of execution on the selected backend (QPU or emulator).

Credit pools

Credits are added through credit pools. A pool has:

• an amount the number of credits the pool holds.
• an optional expiry_date after that date, remaining credits are not usable.

Whenever credits are added to your project, a new credit pool is created and credits become immediately available.

Tip

Remaining credits means: credits from valid (non-expired) pools, minus consumption from completed jobs, minus reserved estimated consumption from pending jobs.

Other terms

Term	Meaning
Metric	Unit used to measure billable usage (hour or shot).
ECRR	Effective Cycle Repetition Rate of the QPU, used for the 1 shot = 4 s estimation.
Soft reservation	Reservation for pending jobs computed dynamically, not stored as a hard lock.
Deficit	Portion of a completed job’s real cost that valid pools could not cover.
Pay-as-you-go	Billing mode for third-party cloud integrations where usage is reported to marketplaces and no credit checks are done on submission.

Credit operations

Adding credits to your project

Credits are added to a project at creation according to the signed contract and can be shot-based or time-based.

By default, added credits are available for one year unless specified otherwise in the contract.

If you have no remaining credits, if credits expired, or if you need additional credits, contact help@pasqal.com.

Job submission

Process

When you submit a job, the billing system:

1. Receives job details (creation time, requested shots, backend type, and others).
2. Estimates the job consumption.
3. Checks remaining credits for the selected backend type.
   • If estimate is below remaining credits, job is accepted.
   • Otherwise, job is rejected and no billing event is stored.

Estimation

Estimation is computed at submission time. It serves two purposes: deciding whether the job can be accepted, and accounting for “pending” consumption while the job runs.

When metric is hour

• QPU estimation

1 shot = 4 seconds

This comes from contractual QPU specification (ECRR = 0.25 Hz).

Note

This estimate is an upper bound. Real completion cost is usually lower.

• Emulator estimation

No estimation is currently performed for emulator jobs (estimation = 0), so credits are not reserved for pending emulator jobs.

When metric is shot (QPU only)

Estimation is simply the requested number of shots. In this case, estimation equals real cost.

Computing remaining credits

For a backend type (QPU or emulator), the remaining credits formula is:

remaining_credits = sum(valid credit pools)
                    - completed job consumption assigned to those pools
                    - estimated consumption of pending jobs

This value is what determines whether your next job submission will be accepted.

Example: 100 credits total, 30 consumed, 20 estimated pending -> 50 remaining.

Assigning completed jobs to pools

Once a job completes, its real consumption is assigned to credit pools in expiration order — the pool with the earliest expiry date is consumed first.

1. Pick the valid credit pool with the closest expiry date.
2. If that pool does not hold enough credits to cover the full cost, split the consumption across multiple pools:
   • Allocate the remaining credits of the current pool.
   • Continue to the next pool (next soonest expiry) until the full cost is covered.

Accepting or refusing a job

A job is accepted if based on an estimated cost used for soft reservation.

The real cost is only known when the job terminates, so the estimate may end up higher or lower than the final consumption (see “Job Completion” below.)

Job completion

Process

When a job completes successfully:

1. Billing receives real consumption (execution time or shots).
2. Credits are deducted from one or more pools.
3. The credits reserved at job submission are released.

Computing final cost

Job succeeded

• Over-estimation (estimate > real)

Only the real amount is consumed. The difference is released automatically, because the job is no longer counted in the “pending jobs” set used to compute remaining credits.

• Under-estimation (estimate < real)

All remaining valid pool credits are consumed in expiry order. If full real cost cannot be covered, uncovered remainder is recorded as a deficit.

Please reach out to help@pasqal.com if you need more credits and this happens.

Third-party integration billing

Pasqal Cloud is also available through cloud marketplaces (Google Cloud Marketplace, Azure Quantum, OVHcloud, Scaleway). These integrations use a pay-as-you-go model:

• no credit pools are managed for these projects,
• no credit checks are performed at submission,
• usage is reported periodically to the provider, which invoices the end customer directly.

Note

• QPU and emulators are billed in pay-as-you-go (EMU_FREE excluded),
• pricing details are available on each provider’s website.

See also Third-Party Cloud Providers for more details.