Nobody buys one. Access is a cloud service, priced in ways that look nothing like renting a CPU, and the practical constraints on what you can run are set by circuit depth and queue time rather than by your budget.
All Quantum Computing →
Quantum results are statistical. A circuit is executed many times — each execution is a shot — and the distribution of outcomes is the answer. That single fact shapes every pricing model in the market, and it is why quantum billing does not resemble cloud compute billing at all.
Per-shot, used by AWS Braket, charges a task fee plus a fee for each execution. Cost scales directly with how many shots your statistics require, which for a noisy device can be a lot. It makes small experiments genuinely cheap and makes precision expensive.
Per-minute, used by IBM Quantum, charges for time on the processor, typically metered in seconds with substantially different rates across access tiers. It rewards efficient circuits and punishes idle connections. IBM has also offered a free open plan on real hardware, which is where most people should start — check current availability.
Per-program, used by Azure Quantum, varies by hardware provider within the marketplace; some meter per gate operation, which makes circuit structure directly visible in the bill.
Indicative figures move constantly and we would rather not publish numbers that are wrong within a quarter. As of September 2026 the shape is: free tiers on real hardware exist and are usable; pay-as-you-go experimentation runs from single-digit to low-hundreds of currency units for a meaningful experiment; and sustained serious use is a subscription negotiated in the thousands per month. Check the provider's own pricing page before budgeting anything.
The binding constraint is not qubit count. It is circuit depth — how many operations you can apply before decoherence and accumulated gate error make the result indistinguishable from noise. On current hardware that number is modest, which means the algorithms that actually complete are shallow ones: variational circuits, small simulations, benchmark problems, and demonstrations.
The second constraint is queue time. Shared hardware means your job waits. For interactive work this is the difference between an afternoon and a week, and simulators — classical machines pretending to be quantum ones, up to around thirty qubits — are where most development sensibly happens. You debug on a simulator and spend hardware time only on runs that matter.
The honest summary for a business evaluating this: you can learn on it, you can benchmark on it, you can build genuine internal capability on it. You cannot currently put it in a production path and get an advantage over a classical machine, and the pages that follow explain why for the two applications most often proposed.
At the time of writing, yes. IBM has offered a free open plan on real hardware — check current availability and confirm against the provider's current terms — and every major platform provides simulators at no or low cost. An afternoon on a simulator plus a small run on real hardware is enough to make quantum computing concrete for a technical team, and it is a better use of a learning budget than a vendor workshop.
IBM if the goal is learning, because in our view the free hardware tier and the documentation are the strongest. Braket if you want to compare hardware types through one interface. Azure if your governance and identity story has to match an existing Azure estate.
To run tutorials, no — the SDKs are approachable and a competent engineer can get results in a day. To design a circuit that does something novel and to know whether the result means anything, yes, and that is a research skill rather than an engineering one. Being clear about which of the two you are buying prevents a lot of disappointment.
It is a cloud service and the usual questions apply: jurisdiction, tenancy, retention, what the provider logs. What you send is a circuit rather than a corpus, so the sensitivity profile is generally low — but if the circuit itself encodes something proprietary, treat it as you would any other workload sent to a third party.
A free tier and an afternoon will teach your team more than any vendor session. We can point you at the right starting point.
30-minute technical call · no deck
What we built, what stage it is at, and a link to the live thing wherever there is one.
yourOS is an operating system with an AI at its heart. You talk to it like a person, out loud or typed. It makes your calls, plans your days and works on your projects with a crew of agents, on your own private server. Our own product, built from the first commit; the waitlist is open.
Website, backend and app assets for Sonora, a free AI sound-therapy app on iOS and Android published by Cognitive AI.
Brand, website, prototype, apps on five platforms, the AI backend and the algorithm-intelligence pipeline for Podswap, a social growth engine that runs without a human in the loop.
In closed beta: Roxy, a private AI assistant with permanent memory running on infrastructure the user owns. Brand, site, product, backend and conversational design.
Live at coherence.com: brand identity generated with AI agents we directed, the motion system and website for the group behind Sonora, AboutAI, WakeUp and MudShadows. Agent work remains in build.
Live at domainbooth.com for DomainBooth, a premium domain brokerage: a new animated mark, every page redesigned and rebuilt with designed mobile layouts, and a custom CMS for its sales record, featured names, press and enquiries.
Apps, platforms and campaigns for these teams, long before the AI work. Every one is written up on the work page — what we did, and where our part ended.
