Contract Billing and Resource Behavior
How resources under an active contract are billed and protected from credit-related interruptions.
Hyperstack separates billing for resources that are governed by active contracts. This ensures that workloads tied to contractual agreements are billed correctly and managed consistently across their lifecycle. Contracted resources are protected from credit-related interruptions and treated distinctly from on-demand resources.
Contracted resources do not consume on-demand credits, are excluded from hibernation triggers, and remain clearly visible in reporting. This guide outlines how Hyperstack enforces contract behavior across compute, storage, networking, and billing.
How Contract Billing Works
Billing Models
Hyperstack offers two distinct billing models for compute resources: on-demand and contract-based.
On-demand resources are charged hourly and directly reduce the account's credit balance. These resources are subject to credit depletion logic and may be hibernated if the available balance drops below a configured threshold.
Contracted resources, by contrast, are governed by prepaid or negotiated agreements. They do not draw down the credit balance and remain operational regardless of credit status. Contracted VMs are associated with a contract_id, and their billing views display a $0 on-demand charge for transparency.
Credit Enforcement Behavior
Contracted virtual machines are fully isolated from credit-based enforcement policies. They do not deduct from the credit balance, are exempt from low-balance hibernation, and can be launched or restored even if the account has zero credit, provided contract capacity is available.
These VMs still appear in billing reports, displaying usage and runtime metrics with a $0 charge. In environments that mix contracted and on-demand resources, Hyperstack treats them independently. On-demand VMs remain subject to standard enforcement, while contracted resources continue operating.
What Resources Are Covered
Virtual Machines
A VM is considered contracted when the GPU flavor, count, and region match a valid contract (or a multi-regional contract) and sufficient contract capacity exists. For example, a contract for 2× H100 PCIe GPUs covers one VM with that configuration. Deploying two such VMs results in one being covered and the other billed on-demand. Spot instances and mismatched GPU configurations are never eligible for contract treatment. If a VM is restored and contract capacity is unavailable, it will revert to on-demand billing.
Kubernetes Worker Nodes
The same contract rules apply to Kubernetes worker nodes. A node is considered contracted if it matches the contract-specified GPU type and quantity, and contract capacity is available. These nodes do not consume credits from the account’s balance. Instead, they are billed through the associated prepaid or premium postpaid contract agreement, just like standalone VMs.
Cluster operations continue as normal for contracted nodes. However, the Kubernetes cluster itself is not considered contract-covered and is subject to standard enforcement. If the account credit balance falls below the configured minimum threshold or becomes negative, the cluster may be deleted per cluster deletion rules.
Public IPs
When attached to a contracted VM, public IPs are treated as contract-covered and do not consume credits. If the VM exits contract coverage, for example when a VM is restored beyond quota, the IP immediately reverts to on-demand billing.
Volumes and Object Storage
Shared Storage Volumes (SSVs) and Object Storage are never considered contract-covered. They always bill against the on-demand credit balance, even if attached to a contracted VM.
VM Lifecycle Behavior
Launch and Restore
Launching a contracted VM bypasses on-demand credit checks. Hyperstack verifies contract capacity and region compatibility during deployment and displays whether the VM is fully, partially, or not at all covered. Restoring a previously contracted VM from hibernation is also allowed at zero credit as long as contract capacity remains. If no capacity is available, the restored VM runs as on-demand.
Hibernation Handling
When credits are exhausted, only on-demand VMs are affected. If all resources are on-demand, Hyperstack hibernates them. In mixed environments, only on-demand VMs are hibernated while contracted VMs continue running. Contracted VMs are never subject to balance-triggered hibernation. These rules also apply to start, stop, reboot, and snapshot operations. All of these actions are allowed for contracted VMs at any credit state.
Billing and Usage Reporting
Billing Views
Billing reports clearly differentiate between contract and on-demand usage. For contracted VMs, reports include runtime duration, theoretical cost for transparency, and show $0 actual charges.
Usage and Expiry
Usage reports list all VMs with a contract badge, GPU count, and recorded runtime. Theoretical pricing is retained even for contracted workloads. Volume and object storage usage is reported normally and continues deducting from the on-demand balance.
Contract expiry behavior follows the contract configuration. If set to Keep, resources convert to on-demand billing. If set to Delete, resources are removed when the contract ends.
Summary Table
| Operation | On-Demand VMs | Contracted VMs |
|---|---|---|
| Credit deduction | Yes | No |
| Hibernation | Yes (low balance) | No |
| Launch without credit | Blocked | Allowed (if capacity) |
| Restore without credit | Blocked | Allowed (if capacity) |
| Billing reports | Charged + visible | $0 charge + visible |
| Usage metrics | Recorded | Recorded |
| Public IP | Billed | $0 (if attached to contract VM) |
| Volumes | Billed | Billed |