How does RunPod pricing work for Pods and Serverless?

Pod pricing and GPU hourly rates

When you launch an on-demand Pod, resources are dedicated to your instance and cannot be displaced by anyone else. RunPod bills on-demand compute on a pay-as-you-go model by the second. To start an on-demand Pod, your account needs to hold at least one hour's worth of credits for the hardware configuration you picked.

You choose between Secure Cloud and Community Cloud. Secure Cloud hosts instances in vetted data centers, while Community Cloud runs on decentralized host machines at lower hourly rates.

If you see references in older tutorials to RunPod Savings plans, keep in mind that Savings plans are deprecated, non-refundable, and can no longer be purchased. If you bought one prior to deprecation, it remains active until its expiration date, covering GPU compute costs only for matching GPU types while storage is still charged at standard rates.

The table below shows the per-hour rates for common GPUs across both cloud tiers, all billed per second with zero commitments:

You aren't charged if the underlying host machine is unavailable.

How storage billing works on Pods

The biggest pricing catch for developers using Pods is disk storage. People often assume stopping a Pod stops all billing, but that depends entirely on the type of disk you attached. You can read our detailed breakdown on Does a stopped RunPod pod still cost money? for the deeper mechanics, but the core pricing rules come down to three storage tiers:

Container disk

Container disks provide temporary root storage for your running instance. They cost $0.10/GB/month while your Pod is running, billed per second. When you stop the Pod, this storage is not charged at all. The tradeoff? The entire container disk is erased immediately when the Pod stops.

Volume disk

Volume disks provide persistent local storage that survives stops and restarts. A volume disk costs $0.10/GB/month while your Pod is running. When you stop the Pod, that rate doubles: RunPod bills $0.20/GB/month for volume disk storage while the Pod is stopped. This cost continues to tick away every second until you delete the Pod.

Network volume

Network volumes act as shared, permanent storage that you can detach and move between Pods. Unlike local disks, network volumes bill hourly rather than per second. For volumes under 1TB, the rate is $0.07/GB/month. For volumes over 1TB, the rate drops to $0.05/GB/month. You pay this exact same rate whether the Pods attached to it are running or stopped.

Serverless billing: Flex vs Active workers

RunPod Serverless handles on-demand API inference without upfront commitments. Billing runs from the exact moment a worker starts until it fully stops, rounded up to the nearest second.

When setting up a Serverless endpoint, you pick between two worker modes:

• Flex workers: These scale all the way down to zero when your endpoint isn't receiving requests. You pay the standard per-second compute rate only when workers spin up and run.
• Active workers: These stay running 24/7 so that your endpoint never hits cold starts. Active workers are billed continuously, though RunPod offers discounts for them if you reach out through a sales inquiry.

Serverless endpoints also charge for worker storage. Container disk storage on Serverless workers is billed in 5-minute intervals at roughly $0.10/GB/month. If your endpoint mounts a shared persistent network volume, that volume bills at $0.07/GB/month for allocations under 1TB, and $0.05/GB/month for volumes larger than 1TB.

The Serverless request lifecycle and what gets billed

Because Serverless billing rounds up to the nearest second, understanding what counts as billable worker time helps you design your container handlers efficiently:

1. Pulling images and model caching: Pulling your container image and downloading cached models normally happens while the worker is scaled down. RunPod does not bill for this stage.
2. Cold start: You are billed for compute during cold starts. The clock starts ticking the moment the worker launches and continues until your handler signals that it is ready to accept traffic. In practice, this window is mostly spent loading model weights into GPU memory.
3. Execution time: You are billed standard compute rates for the time your handler spends actively processing requests. You can set execution timeouts on your endpoint to prevent runaway jobs from running up compute charges.
4. Waiting (idle timeout): After finishing a job, a worker doesn't immediately shut down. It stays active and waits for new requests for the duration of the endpoint's idle timeout. RunPod defaults this idle timeout to 5 seconds, though you can adjust it in your endpoint settings. You are billed for compute during this waiting period.
5. Idle (scaled down): Once the idle timeout expires without a new request, the worker scales down. It shows up as "Idle" in the RunPod console and incurs no compute charges.

If you believe an endpoint billed you incorrectly, you can open a ticket with RunPod support. Your ticket must include three details: your Endpoint ID, the Request ID (if applicable), and the approximate time the issue occurred.

Account balance, zero credits, and the spend limit

RunPod protects users from unbounded runaway charges with a default spend limit of $80/hour across all your active resources. If your workload requires higher throughput, you have to contact support to request an increase.

Account balance handling is strict. When your account balance hits $0, RunPod stops all your running Pods automatically. What happens to your files after that depends on your storage setup:

• Pods with a network volume: The Pod is stopped, but your data is preserved inside the network volume.
• Pods without a network volume: The Pod is terminated immediately, and its data cannot be recovered.

If you don't keep an eye on your remaining prepaid balance, a stopped Pod's volume disk will eventually drain the last pennies of your credits, triggering a termination that wipes your work. If you're comparing provider billing styles, check out How does Vast.ai billing work, and do stopped instances still cost money? to see how alternate platforms handle instance displacement and stopping.

Monitoring RunPod spend with Costbrake

If you want an extra layer of visibility across your RunPod bills, you can connect your account to Costbrake. Costbrake checks your provider spend regularly, sending alerts for sudden spikes, budget thresholds (at 50%, 80%, and 100%), month-end budget forecasts, and new charges.

To track RunPod, generate an API key in your RunPod dashboard under User Credentials with Read Only permission. Costbrake uses that key to read your hourly billing data and account id, checking numbers every five minutes on paid tiers. If you want to use Costbrake's opt-in brake features to manually stop a runaway Pod or scale a Serverless endpoint to zero from your alerts, you can configure a separate key with All permission. For step-by-step guidance, point your AI assistant to agent setup or review Costbrake pricing.