Hardware and capacity

Available hardware

Request	Machine	Memory	Typical use
l40	NVIDIA L40 or L40S	48 GB	Default for training, inference and most GPU work
a100	NVIDIA A100 80 GB	80 GB	Larger models, memory-bound workloads
h100	NVIDIA H100 80 GB	80 GB	Fastest option for large training runs
cpu-d3-4vcpu-16gb	AMD EPYC, 4 vCPU	16 GB	Small CPU jobs, builds, smoke tests
cpu-d3-96vcpu-384gb	AMD EPYC, 96 vCPU	384 GB	Large simulations, compilation, data processing
cpu-e2-4vcpu-16gb	Intel Ice Lake, 4 vCPU	16 GB	Small CPU jobs
cpu-e2-48vcpu-192gb	Intel Ice Lake, 48 vCPU	192 GB	Large CPU jobs

Prices and availability can change. Check current values:

c3 list            # classes with price range and availability
c3 list --all      # every profile with its provider and exact price

The same view is at cthree.cloud/status.

Choosing hardware

In .c3:

hardware: l40                 # a class: C3 picks the cheapest available machine in it
hardware: h100-80gb           # an exact profile, from c3 list --all
hardware: cpu-d3-96vcpu-384gb # CPU machines are always requested by exact profile
provider: nebius              # optional: only use this provider
regions: [eu-north1]          # optional: only these provider regions

Omit hardware entirely and C3 picks from the l40 class. c3 deploy -p <provider> pins a provider for one run. c3 deploy --dry-run shows the route, rate and availability without submitting.

CPU jobs

Request an exact CPU profile. hardware: cpu is rejected because cpu is a group, not a machine. CPU machines have no CUDA or NVIDIA drivers, so Docker images must declare requires_accelerator: none:

hardware: cpu-d3-96vcpu-384gb
docker:
  image: ubuntu:24.04
  requires_accelerator: none

CPU capacity is experimental: usable and billed normally, but the profiles and images may change. There is no multi-node MPI launcher; MPI runs within one machine.

Availability

c3 list shows HIGH, MEDIUM or LOW for each row. This is a coarse signal of capacity C3 can currently offer, not a stock count. LOW can mean capacity is unavailable, access is temporarily restricted, or pricing is stale. A current price may still be listed while capacity is unavailable. The CLI, status page and MCP hardware listing use the same public availability signal. Exact stock, provider regions and native machine names are not shown before a job is matched; after submission, c3 squeue <job-id> shows the provider, region and profile the job landed on.

How long before my job starts

If a compatible machine is already warm, your script starts within seconds of submission. Otherwise C3 provisions a new machine, which takes minutes and varies by provider and hardware. PENDING means C3 is waiting for a machine; SCHEDULING means one is assigned and being prepared. Neither state is billed.

When capacity is unavailable

If the selected provider reports it is out of stock, a waiting job stays PENDING. Existing provider paths report PROVISIONING_BLOCKED and retry the selected pool. Two fields control the capacity policy:

capacity:
  on_unavailable: wait     # wait (default) or fail
  max_wait_minutes: 60     # 1 to 360

• wait retries until the deadline, then fails the job with PROVIDER_CAPACITY_UNAVAILABLE.
• fail fails immediately instead, so you can resubmit with different hardware.

Separately, the queue has a six-hour maximum lifetime. When no compute ran, the reserved credit is refunded once any original allocation and cleanup are resolved. An uncertain provider response can delay that refund while C3 checks whether a machine was created.

The bounded capacity-attempt path being introduced for AWS keeps one original wait deadline across retries and restarts. A provider pin stays pinned. Before an unpinned job is assigned or consumes a native allocation, C3 may choose another matching offering within the original hardware/region constraints at an equal or lower price. Suitable warm machines come first, followed by ordinary fresh-positive provider stock; an AWS cold attempt requires fresh zero-capacity estimates from every matching alternative provider. AWS remains gated during onboarding.

On that path, pending feedback distinguishes an attempt, waiting for capacity, machine startup and reconciliation of an uncertain original allocation. C3 recovers the original allocation before considering a replacement. A finished job on that path is not retried; submit a new job to start a new wait window. Legacy submissions retain their selected-pool behavior.

Routing details

• A pinned provider goes through the same stock, inventory and spend checks as auto-routing, so a pin can be rejected while auto-routing succeeds elsewhere.
• On existing provider paths, submitting to an out-of-stock pool is only allowed when both provider and hardware are set; other requests are rejected at submit time with GPU_OUT_OF_STOCK.
• On existing provider paths, ambiguous responses and repeated provisioning failures can remain blocked until max_wait_minutes even with on_unavailable: fail. On the bounded AWS path, an explicit capacity refusal fails promptly for fail; uncertainty requires recovery of the original request rather than another launch.