Pricing
Capacity-based pricing with reserve clearly separated
Customers see CPU, GHz, RAM, VRAM, availability and reserve logic in one quote before launch.
| Component | Unit | Billing note |
|---|---|---|
| CPU | Per core / hour | Billed per second while allocated |
| CPU GHz add-on | Per effective GHz / hour | Refines fit beyond core count |
| RAM | Per GB / hour | Charged only while allocated |
| VRAM | Per GB / hour | Used for GPU-backed inference lanes |
| Availability | Protected multiplier | Adds reserve and health commitment |
| Bandwidth | Per 100 Mbps / hour | Included in quote preview |
| Funding rail | Credit rule | Note |
|---|---|---|
| Card / Stripe | 1 USD -> 1 NLC | Primary customer rail for v1 |
| NLR funding | USD-equivalent -> 102% NLC | Adds token incentive without changing compute billing |
Quote preview
0.1756 NLC/hour
126.48 NLC/month estimate
Current burn0.000048 NLC/sec
Active allocation0.1756 NLC/hour
Protected reserve0.0000 NLC/hour
Placement policynear | inferred from ingress
No workload, no reserve, no variable spend.
FAQ
When does variable spend start?
Only when a workload is running or when you choose protected reserve. If nothing runs and nothing is reserved, variable compute spend is zero.
FAQ
Why do protected runtimes cost more?
Protected runtimes reserve failover capacity, enforce minimum replica policy and keep availability commitments even at low request volume.
FAQ
Why is pricing shown in NLC?
NLC is the stable compute billing unit. NLR remains the network asset and stays out of the critical execution path.
FAQ
What happens if a customer funds with NLR?
Confirmed NLR funding on Base credits the USD-equivalent value into NLC and adds a 2% NLC bonus so token funding is rewarded without changing runtime billing.