Platform FinOps and Unit Economics

Quantum operations fail quietly when nobody can explain what a useful result costs. The scarce resource is not merely money. It is QPU reservation time, calibrated device time, staff attention, simulator capacity, review bandwidth, and the opportunity cost of tying a fragile target to a low-value workload.

IBM documents workload usage for Qiskit Runtime and distinguishes job, batch, and session modes; Amazon Braket prices QPU use using per-shot and per-task components or hourly reservations; Azure Quantum exposes provider-specific quotas and cost-reporting workflows [R134]. The details differ by vendor. The operating principle is stable: every experiment needs a cost envelope before execution and a cost attribution record after execution.

75.1 The quantum cost stack

flowchart TB
    Cost[Quantum platform cost] --> QPU[QPU access]
    Cost --> Shots[Shots and tasks]
    Cost --> Reservation[Dedicated reservation]
    Cost --> Classical[Classical CPU and GPU compute]
    Cost --> Storage[Artifact and evidence storage]
    Cost --> People[Operator and reviewer time]
    Cost --> Rework[Rework caused by drift]
    Cost --> Risk[Risk and continuity reserves]

Classical cost models tend to price compute as a commodity. Quantum cost models must price fragility. A failed quantum job may cost little if it fails before device lock, or it may consume scarce locked time, depending on execution mode and provider policy [R134].

75.2 Unit economics

flowchart LR
    Shot[Cost per shot] --> Task[Cost per task]
    Task --> Run[Cost per run]
    Run --> Evidence[Cost per evidence package]
    Evidence --> Claim[Cost per validated claim]
    Claim --> Decision[Cost per supported decision]

The useful business unit is rarely “cost per shot.” It is usually one of these:

75.3 Cost envelope before execution

sequenceDiagram
    participant User as Workload owner
    participant Planner as Cost planner
    participant Router as Platform router
    participant Budget as Budget policy
    participant Runtime as Runtime provider
    User->>Planner: submit workload contract
    Planner->>Router: request target and mode estimate
    Router->>Budget: check cost envelope
    Budget-->>Router: approve, cap, or reject
    Router->>Runtime: submit within approved envelope
    Runtime-->>Planner: usage and cost signal
    Planner-->>User: cost report linked to evidence

Cost approval should be machine-readable. Human review is reserved for unusual spending, high-impact claims, and workloads whose scientific value is unclear.

A basic cost envelope should include:

• maximum shots
• maximum tasks
• maximum active session or reservation time
• maximum simulator spend
• maximum mitigation overhead
• maximum retry count
• maximum reviewer hours
• required stopping rule

75.4 Spend classes

stateDiagram-v2
    [*] --> Sandbox
    Sandbox --> Exploratory: approved project
    Exploratory --> Benchmark: recurring measurement
    Benchmark --> Production: customer or governance dependency
    Production --> Strategic: board or public claim dependency
    Exploratory --> Retired: no signal
    Benchmark --> Retired: obsolete target

Spend class determines approval. A small run can be expensive if it creates misleading evidence. A large reservation can be reasonable if it replaces months of queue uncertainty and supports a high-value milestone.

75.5 Chargeback without punishing exploration

flowchart TB
    Ledger[Cost ledger] --> Team[Team chargeback]
    Ledger --> Product[Product allocation]
    Ledger --> Research[Research portfolio]
    Ledger --> Vendor[Vendor comparison]
    Ledger --> Waste[Waste analysis]

Chargeback should not make scientists hide exploratory runs. It should make hidden rework visible.

Good chargeback fields:

• project
• workload family
• target
• provider
• execution mode
• approval policy
• expected cost
• realized cost
• cancellation reason
• retry reason
• evidence package ID

75.6 Capacity and reservation economics

Dedicated reservations change the denominator: charges depend on the provider’s reservation terms rather than only the work completed [R134]. A reservation can reduce queue uncertainty, improve batch continuity, or enable approved characterization. It does not guarantee stable calibration; monitor drift and define interruption and recalibration handling with the provider.

flowchart LR
    Reservation[Reservation] --> QueueRisk[Reduced queue risk]
    Reservation --> Throughput[Higher batch throughput]
    Reservation --> Calibration[Opportunity to monitor calibration continuity]
    Reservation --> IdleRisk[Idle-time risk]
    Reservation --> Prep[Requires prepared workload queue]

Before a reservation, require a prepared queue:

flowchart TB
    Ready[Reservation readiness] --> Workloads[Workloads staged]
    Ready --> Fallbacks[Fallback tasks prepared]
    Ready --> Operators[Operators scheduled]
    Ready --> Monitoring[Live cost monitoring]
    Ready --> StopRules[Stop rules approved]

75.7 Waste taxonomy

flowchart TB
    Waste[Quantum waste] --> Invalid[Invalid workload]
    Waste --> Drift[Target drift ignored]
    Waste --> OverShots[Overshot sampling]
    Waste --> Queue[Queue and idle loss]
    Waste --> Recompile[Unnecessary recompilation]
    Waste --> NoEvidence[No reusable evidence]
    Waste --> VendorLock[Non-portable artifact]

The worst waste is not a failed experiment. It is a run that cannot be interpreted later.

75.8 Operating rule

A quantum platform is not economically mature until it can answer three questions for every result:

1. What did this result cost?
2. What would it cost to reproduce?
3. What would it cost to improve the confidence interval?

flowchart LR
    Result[Result] --> Cost[Observed cost]
    Result --> Reproduce[Reproduction cost]
    Result --> Improve[Marginal confidence cost]
    Cost --> Decision[Investment decision]
    Reproduce --> Decision
    Improve --> Decision

Additional technical sources: [R24].