Affiliate disclosure: HostFleet may earn a commission through labeled signup links on this page. That does not change the analysis. Read our methodology and affiliate policy.
Source-backed pricing guide; calculated costs are estimates, not measured bills. We checked RunPod’s public rate card and official billing, worker, endpoint and Pod documentation on November 2, 2026. We did not rent a GPU, obtain an authenticated quote, confirm capacity, inspect an invoice or benchmark performance.
Rates verified: November 2, 2026 — all 42 Community/Secure Pod prices and 13 Serverless Flex tiers
Billing and configuration documentation checked: November 2, 2026
Currency and assumptions: public USD list prices before tax; one GPU; 720 allocated hours for compute comparisons; 730 hours only for illustrative storage-month conversion
Dataset scope: this article’s RunPod checks do not advance the dataset-wide September 24 verification date.
RunPod pricing 2026: higher Flex rates, Pods and billing boundaries
RunPod pricing depends first on what stays allocated: a Pod charges while its infrastructure is allocated; Serverless Flex charges while workers run; retained storage can bill after compute stops. A successful request is not the end of the worker’s billable lifetime.
The November 2 check changes the buying math:
- Seven of 13 Flex rates are higher than our October 17 observation. The 24 GB pooled L4-class tier is $0.75/hour, RTX 4090 Pro $1.34/hour, H100 Pro $5.39/hour and B200 $10.79/hour. The largest observed increase is B200 at 24.88%. These are observation-to-observation differences, not a claim that prices changed today.
- All 42 Pod list prices are unchanged from October 17. L4 Secure remains $0.59/hour; A100 PCIe $1.79/hour; H100 PCIe $2.89/hour. More expensive Flex lowers the worker-hours at which an always-on Pod becomes cheaper on compute alone.
- Configuration defaults depend on how you deploy. Current endpoint docs say the console uses a five-second idle timeout while REST v2 uses ten seconds. The same five-second example cannot stand in for both.
- The B300 Flex memory label is now 288 GB, matching the Pod page’s label; the October 17 capture showed 280 GB for Flex. Matching labels still do not prove matching host resources or throughput.
All current GPU figures above come from the official pricing page, checked November 2, 2026. Its structured metadata says dateModified: 2026-10-28; that is a page-level marker, not proof of when any individual rate changed.
Which RunPod product fits the workload?
| Workload | Surface to evaluate first | Budget boundary |
|---|---|---|
| Sustained job; you manage the container | On-demand Pod | Running allocation, storage and the exact Community/Secure configuration |
| Bursty API with meaningful idle gaps | Serverless Flex | Worker cold start, execution, waiting timeout, retries and all parallel workers |
| Endpoint that must remain warm | Active Serverless or a running Pod | Active workers keep billing without requests; get an Active-rate quote |
| Short pause with local data to retain | Stopped Pod | GPU released; local volume remains billable; restart capacity not reserved |
| Disposable environment after export | Terminated Pod | Pod-local data deleted; separately created network storage survives |
| Weights/checkpoints that must outlive compute | Network volume | Its storage lifecycle is independent of the Pod |
Community and Secure Cloud are different supply surfaces, not interchangeable performance promises. Before comparing rates, record exact GPU variant, GPU count, host resources, region and capacity. See our RunPod deployment review for product fit beyond pricing.
Every public Pod price: Community versus Secure
Verified November 2, 2026. All 21 pairs on the public rate card match the October 17 article baseline. Explicit Community/Secure price attributes agree with the matching structured offers; the visible default price is Secure. These are on-demand list inputs, not an authenticated account quote or commitment discount.
| GPU product | Community/hr | Secure/hr | Secure premium/hr | Premium over 720 hours | Premium vs Community |
|---|---|---|---|---|---|
| RTX A5000 | $0.16 | $0.27 | $0.11 | $79.20 | 68.8% |
| RTX 3090 | $0.22 | $0.50 | $0.28 | $201.60 | 127.3% |
| A40 | $0.35 | $0.59 | $0.24 | $172.80 | 68.6% |
| L4 | $0.44 | $0.59 | $0.15 | $108.00 | 34.1% |
| RTX A6000 | $0.33 | $0.59 | $0.26 | $187.20 | 78.8% |
| Pro 6000 MIG 24GB | $0.50 | $0.69 | $0.19 | $136.80 | 38.0% |
| RTX 4090 | $0.34 | $0.89 | $0.55 | $396.00 | 161.8% |
| RTX 6000 Ada | $0.74 | $0.99 | $0.25 | $180.00 | 33.8% |
| L40 | $0.69 | $0.82 | $0.13 | $93.60 | 18.8% |
| RTX 5090 | $0.69 | $1.19 | $0.50 | $360.00 | 72.5% |
| L40S | $0.79 | $1.09 | $0.30 | $216.00 | 38.0% |
| Pro 6000 MIG 48GB | $1.00 | $1.29 | $0.29 | $208.80 | 29.0% |
| A100 PCIe | $1.19 | $1.79 | $0.60 | $432.00 | 50.4% |
| A100 SXM | $1.39 | $1.79 | $0.40 | $288.00 | 28.8% |
| RTX Pro 6000 | $1.69 | $2.49 | $0.80 | $576.00 | 47.3% |
| H100 PCIe | $1.99 | $2.89 | $0.90 | $648.00 | 45.2% |
| H100 NVL | $2.59 | $3.19 | $0.60 | $432.00 | 23.2% |
| H100 SXM | $2.69 | $3.99 | $1.30 | $936.00 | 48.3% |
| H200 | $3.59 | $5.29 | $1.70 | $1,224.00 | 47.4% |
| B200 | $5.98 | $7.99 | $2.01 | $1,447.20 | 33.6% |
| B300 | $6.94 | $8.99 | $2.05 | $1,476.00 | 29.5% |
Estimate assumptions: one listed GPU stays allocated for all 720 hours, excluding tax, storage, credits, negotiated discounts and other charges. Percentages divide the difference by Community price. Equal GPU names do not establish equal host resources, stock or throughput.
For example, A100 PCIe Secure compute is $1.79 × 720 = $1,288.80, compared with $1.19 × 720 = $856.80 on the Community list input: a $432.00 difference before other costs. The largest dollar premium in this table is B300 at $1,476.00 over 720 hours; the largest percentage premium is RTX 4090 at 161.8%. Percentages and total dollars answer different questions.
Compare exact variants and other providers in the A100 rental guide and H100 rental guide. Those pages have their own verification dates; this article does not reverify their other providers.
Every public Serverless Flex tier
Current rates and memory labels verified November 2, 2026, on the official pricing page. These are Flex rates, not Active-worker discounts. RunPod’s Serverless pricing docs, also checked November 2, describe billing by the second, rounded up. The hourly card is the consistent input here; dividing it by 3,600 is arithmetic, not an independently quoted per-second tariff.
| Public Flex tier | Current memory label | October 17/hr | November 2/hr | Observed change |
|---|---|---|---|---|
| A4000, A4500, RTX 4000, RTX 2000 | 16 GB | $0.58 | $0.58 | Unchanged |
| L4, A5000, 3090, MIG 24GB | 24 GB | $0.69 | $0.75 | +8.70% |
| RTX 4090 Pro | 24 GB | $1.10 | $1.34 | +21.82% |
| RTX PRO 4500 Blackwell | 32 GB | $1.15 | $1.15 | Unchanged |
| RTX 5090 Pro | 32 GB | $1.58 | $1.79 | +13.29% |
| A6000, A40 | 48 GB | $1.22 | $1.22 | Unchanged |
| L40 / L40S / 6000 Ada / MIG 48GB | 48 GB | $1.75 | $1.75 | Unchanged |
| A100 | 80 GB | $2.72 | $2.72 | Unchanged |
| H100 Pro | 80 GB | $4.79 | $5.39 | +12.53% |
| RTX 6000 Pro | 96 GB | $3.49 | $3.49 | Unchanged |
| H200 | 141 GB | $5.93 | $6.99 | +17.88% |
| B200 | 180 GB | $8.64 | $10.79 | +24.88% |
| B300 | 288 GB | $10.65 | $11.99 | +12.58% |
The seven increases range from 8.70% for the L4-class tier to 24.88% for B200. Six exceed 10%. Historical columns are HostFleet’s October 17 observations, not announced vendor effective dates; no cause for the changes is inferred.
A pooled label is not an exact-card reservation. The 24 GB L4/A5000/3090/MIG tier does not promise an L4 on every request. The endpoint settings, checked November 2, allow up to three GPU selections in priority order and describe distribution across priorities with five or more workers. Record the actual GPU before drawing performance conclusions.
The B300 row now says 288 GB, rather than the October baseline’s 280 GB. This is a source-label correction, not evidence of a hardware upgrade. Check the available GPU and memory in the account quote rather than inferring capacity from a catalog label.
These tables extend the selected RunPod rows in HostFleet’s gpu-pricing.json baseline to the complete current card. The dataset’s selected Flex raw prices agree with this check; its global date remains September 24. They are dated source snapshots, not automatic account-price lookups. Use the live GPU pricing table and serverless GPU pricing matrix for the wider catalog, respecting each provider’s verification date.
Pod versus Flex: updated break-even math
How many aggregate Flex worker-hours equal one Secure Pod allocated for 720 hours? This is compute-only accounting, not a comparison of throughput, successful requests or total deployment cost.
Pod compute = Secure Pod rate × 720
Flex break-even worker-hours = Pod compute ÷ Flex rate
Share of 720 hours = Secure Pod rate ÷ Flex rateInputs: official public rate card, verified November 2, 2026.
| Capacity point | Secure Pod/hr | Flex/hr | Pod for 720 hours | Flex compute-only break-even |
|---|---|---|---|---|
| L4 / pooled 24 GB | $0.59 | $0.75 | $424.80 | 566.4 hours (78.7%) |
| RTX 4090 / 24 GB | $0.89 | $1.34 | $640.80 | 478.2 hours (66.4%) |
| RTX 5090 / 32 GB | $1.19 | $1.79 | $856.80 | 478.7 hours (66.5%) |
| A40 / pooled 48 GB | $0.59 | $1.22 | $424.80 | 348.2 hours (48.4%) |
| L40S / pooled 48 GB | $1.09 | $1.75 | $784.80 | 448.5 hours (62.3%) |
| RTX Pro 6000 / 96 GB | $2.49 | $3.49 | $1,792.80 | 513.7 hours (71.3%) |
| A100 PCIe / 80 GB | $1.79 | $2.72 | $1,288.80 | 473.8 hours (65.8%) |
| H100 PCIe / 80 GB | $2.89 | $5.39 | $2,080.80 | 386.0 hours (53.6%) |
| H200 / 141 GB | $5.29 | $6.99 | $3,808.80 | 544.9 hours (75.7%) |
| B200 / 180 GB | $7.99 | $10.79 | $5,752.80 | 533.2 hours (74.1%) |
| B300 / 288 GB | $8.99 | $11.99 | $6,472.80 | 539.8 hours (75.0%) |
Assumptions: one GPU per worker, no storage, tax, credits, discounts or extra charges, and no assertion of performance equivalence between a pooled Flex tier and a Pod. Hours aggregate across all workers: ten simultaneous workers consume ten worker-hours in one elapsed hour. Warm Active workers require their own quote.
For L4-class capacity, the crossover falls from the October 17 estimate of 615.7 to 566.4 aggregate worker-hours because Flex rises from $0.69 to $0.75/hour while the Pod stays $0.59/hour. At 100 billable Flex worker-hours, compute is $75.00, compared with $424.80 for a Secure Pod held for 720 hours. Release the Pod after the same 100 allocated hours and its compute would instead be $59.00. The apparent Flex saving depends on avoiding unnecessary allocation, not simply using “serverless.”
For B200, the corresponding crossover falls from 665.8 to 533.2 worker-hours. At 100 worker-hours, the public Flex input gives $1,079.00, versus $864.00 using October 17’s rate: $215.00 more with identical billable time assumptions.
Use the GPU cloud cost calculator to replace 720 with expected useful work, startup, idle tails, retries, teardown lag and retained resources. Request response time is not total worker lifetime.
Startup billing: Initializing is not model loading
The Serverless pricing guide and worker lifecycle guide, checked November 2, describe the same boundary: compute bills while a worker is running. This is a documented lifecycle boundary, not a measured invoice cutoff.
| Worker phase or console state | Documented compute treatment | Practical meaning |
|---|---|---|
| Initializing | Scaled down; not billed | Host normally pulls image or downloads cached models before container startup |
| Cold start within Running | Billed | Container starts; handler loads its model and becomes ready |
| Processing within Running | Billed | Worker executes requests |
| Waiting within Running | Billed | Worker waits for another job during idle timeout |
| Idle | Already scaled down; not billed | Not the same as waiting during the timeout |
| Active worker with no job | Keeps running and billing | An empty queue does not make an Active worker free |
Important exception: image pulls are normally outside running compute, but the worker guide says a pull is billed if the worker starts before the image is present on its host. Do not promise universally free image downloads. Loading model weights inside the running handler is also not the same as downloading cached weights while scaled down.
A separate rate-table discrepancy remains
Clearer lifecycle language does not resolve every pricing source. The endpoint-settings per-second table, checked November 2, still differs from the public hourly card. Its H100 figure of $0.00116/second converts to $4.176/hour, versus public Flex $5.39/hour. Its L40/L40S/6000 Ada figure of $0.00053/second converts to $1.908/hour, versus public $1.75/hour.
This guide consistently uses the public hourly card because the Serverless pricing documentation points there for compute prices. For the L4-class row, the docs’ $0.00019/second yields $0.684/hour rather than the public card’s $0.75/hour. Confirm the effective quote for the exact account and endpoint before reconstructing charges. Do not combine one page’s per-second input with another page’s hourly rate as though they were identical tariffs.
Idle tails: console and REST v2 defaults differ
The endpoint-settings guide, checked November 2, 2026, now distinguishes these creation defaults:
| Setting | Console default | REST v2 default documented in the guide |
|---|---|---|
| Idle timeout | 5 seconds | workers.idleTimeout: 10 seconds |
| Execution timeout | 600 seconds | timeout: 300000 milliseconds (5 minutes) |
| FlashBoot | Enabled | flashboot: OFF; set FLASHBOOT to enable |
The console also lists zero Active workers, three maximum workers and one GPU per worker. Do not treat a console default as the configuration of an API-created endpoint: inspect the actual returned settings. The guide says REST v2 requires type and scaling, and has no endpoint-level job TTL field.
A waiting worker remains Running and billed. At the November 2 public Flex inputs, isolated tails cost:
| Flex tier | One five-second tail | 1,440 five-second tails | 1,440 ten-second tails |
|---|---|---|---|
| L4-class at $0.75/hr | $0.001042 | $1.50 | $3.00 |
| A100 at $2.72/hr | $0.003778 | $5.44 | $10.88 |
| H100 Pro at $5.39/hr | $0.007486 | $10.78 | $21.56 |
| B300 at $11.99/hr | $0.016653 | $23.98 | $47.96 |
Derived assumptions: hourly rate × timeout seconds / 3,600; 1,440 independent, nonoverlapping worker tails. This excludes cold start, execution, retries, rounding effects, storage and discounts. Requests can share a running worker’s tail; multiple workers can create multiple tails. It is not a fixed fee applied to each request. Under this scenario, doubling the configured timeout doubles the waiting component, not necessarily the full bill.
Queue-based endpoints advertise automatic retries. Turning off client retries does not prove a single provider execution. Capture request/job ID, attempt count, worker ID and process identity when measuring. The worker guide also mentions extra workers during spikes; do not treat a nominal maximum as a verified small-experiment spend cap without checking its effective behavior.
A $0.25 L4 smoke test is a plan, not a hard cap
Using the November 2 public L4-class Flex rate of $0.75/hour, ten cumulative billable worker-minutes cost:
$0.75 × 10/60 = $0.125 of compute
$0.125 + $0.10 assumed other-cost reserve = $0.225
$0.25 planning target − $0.225 = $0.025 headroomThe $0.10 reserve is an unmeasured assumption for all other charges, storage and cleanup. It is not a quoted fee or a proven upper bound. This envelope only holds if aggregate running time really stays within ten worker-minutes on a supported one-running-worker configuration. Ten wall-clock minutes with two concurrent workers can mean twenty worker-minutes. A nominal max-workers setting alone is not proof of that bound; the worker docs also describe extra workers during spikes.
Before any paid smoke test, confirm the account quote, endpoint/GPU identity, actual concurrency controls, all retry paths, supported shutdown action and attributable billing precision. Include handler/model startup and idle waiting in the time allowance; stop when a gate cannot be established. RunPod’s documented default $80/hour account-wide limit is not a $0.25 per-run cap. Execution timeout limits a job, not the endpoint’s entire spend.
We designed this example; we did not execute it, validate the reserve or verify a watchdog cutoff. The billing overview, checked November 2, says credits are non-refundable and evaluation can start with $10. A sub-dollar usage estimate is not a promise of a sub-dollar deposit.
Stopping a Pod: GPU released, storage retained
The Pod management guide, rechecked November 2, says stopping releases the GPU, clears the container disk and preserves the local volume normally mounted at /workspace. Restart depends on available capacity and can return zero GPUs. Stop is not a reservation.
Termination deletes the Pod and its local data. A separately created network volume survives both stop and termination; if /workspace is backed by that network volume rather than local volume, follow the network-volume lifecycle instead.
Storage prices and granularity: Pods pricing, verified November 2, 2026.
| Resource | Running Pod | Stopped Pod | After Pod termination |
|---|---|---|---|
| GPU compute | Per-second compute | Released | No Pod compute |
| Container disk | $0.10/GB-month; per second | Cleared; not charged | Deleted |
| Local volume disk | $0.10/GB-month; per second | $0.20/GB-month; per second | Deleted |
| Standard network volume below 1 TB | $0.07/GB-month; hourly | Persists independently | Persists independently |
The public documentation lists standard network storage above 1 TB at $0.05/GB-month. Its “under”/“over” wording does not establish the exact 1 TB boundary. The product-specific page and billing summary distinguish hourly network-volume billing from the billing overview’s broad per-second statement; use the specific storage rule rather than applying compute granularity universally.
For 100 GB retained for a full nominal month, the cited rates imply $10 running local, $20 stopped local, or $7 network storage below 1 TB. For a 160-hour pause, an illustrative 730-hour conversion gives:
stopped local: 100 × $0.20 × 160/730 = $4.38
network: 100 × $0.07 × 160/730 = $1.53These are capacity-rate estimates excluding compute, tax, credits and other charges, not measured bills or storage-performance comparisons. A 730-hour divisor is an exposed planning assumption, not a newly verified provider proration rule. Back up critical data externally: RunPod’s storage guidance, checked November 2, says it is not designed for long-term cloud storage.
For Serverless, the separate pricing guide, checked November 2, describes container disk at approximately $0.10/GB-month in five-minute intervals, plus independently persistent network volumes. Zero running compute is not proof of a zero endpoint/storage bill.
Reconcile endpoint cost without inventing billed seconds
A useful first audit answers “what did this endpoint cost?” before trying to assign dollars to cold start, execution and waiting. RunPod documents two Serverless billing contracts, checked November 2; they are not interchangeable schemas.
| API contract | Endpoint scope | Documented output | Limit |
|---|---|---|---|
v1 endpoint billing: GET https://rest.runpod.io/v1/billing/endpoints | endpointId, grouping=endpointId, explicit UTC dates, bucketSize=hour | Array of grouped records with endpointId, time, amount; timeBilledMs and diskSpaceBilledGb documented for applicable resources | Billed milliseconds do not apply to every resource; verify actual field presence and scope |
v2 Serverless billing: GET https://api.runpod.io/v2/billing/serverless | serverlessId, explicit UTC dates, bucketSize=hour | records with endpoint ID, bucket start/end and GPU/CPU/disk/total USD; metadata query, totals and counts | No documented timeBilledMs field; amount-only output cannot directly measure billed lifetime |
Use this workflow for one dedicated endpoint:
- Capture the quote and identity. Record endpoint ID, account/team scope, actual GPU selection, GPU count, Active/max workers, idle timeout, FlashBoot and storage. Map v1
endpointIdto v2serverlessIdbefore comparing records. - Take a baseline, then isolate the work. Keep exact UTC request and worker events, all attempts and cleanup evidence. A job result’s
delayTime + executionTimeis not documented as total billed worker lifetime. - Fetch every intersecting hourly bucket. v2 rounds start down and end up to bucket boundaries. Read
metadata.queryfor the resolved window and match every returnedserverlessId. Its buckets are half-open[startTime, endTime). Do not mixlastNwith explicit start/end; it can include an unfinished bucket. - Reconcile all categories. Preserve GPU, CPU, disk and total amounts, plus credits, discounts and the original payload. Check record counts and category sums against metadata. v2
feeAmountis deprecated and always zero: platform charges are already included in GPU/CPU amounts, not another fee to add. - Keep the time claim separate. Dividing dollars by a matching effective rate yields derived rate-equivalent seconds. It does not independently measure lifetime or split startup from waiting. Even a populated v1 billed-time field needs independent lifecycle evidence for phase attribution.
- Confirm finality and cleanup. Documentation does not promise settlement delay; repeated unchanged records alone are not proof of invoice-final amounts. The endpoint delete contract documents HTTP 204 success, not an immediate billing cutoff. Verify endpoint absence and workers stopped; cancellation or queue purge alone does not establish teardown.
Preserve returned number precision, for example with decimal parsing rather than binary floating-point arithmetic. Do not sum v1 and v2 amounts as independent charges for the same work. If attribution or reconciliation fails, report latency separately and mark cost decomposition unresolved; do not label the remainder “cold-start cost.” These are documented contracts and a proposed audit method, not account responses or an experiment we ran.
For Pods, use the separate Pod billing history filtered by podId. Network volumes have their own billing history. Hourly cost buckets can reconcile categories but cannot establish a second-exact release cutoff.
Prepaid balance and dormant endpoints are operational limits
The billing overview, checked November 2, describes prepaid credit, a minimum balance of one hour of the selected Pod configuration before deployment, billing runs every five minutes and auto-pay attempts limited to once per hour. That balance requirement is not a one-hour minimum usage charge.
The documented default spend limit is $80/hour across all resources, not a cumulative experiment budget. At zero balance, Pods with a network volume stop; those without one terminate and lose their data. Network-volume storage can continue charging and may eventually be deleted if unfunded. Set balance alerts and maintain payment headroom; an alert is not a substitute for teardown.
The worker guide, checked November 2, lists a default combined limit of five Flex and Active workers. Balance-based limits are account ceilings, not capacity guarantees. Check the actual account rather than planning production around a default.
Dormancy is separate from the configured worker idle timeout. The endpoint guide, checked November 2, says three days without requests reduces max workers to two and seven days sets it to zero. You must raise that value yourself before reuse. Test recovery endpoints instead of assuming the next request restores capacity.
Verdict: choose allocation first, then verify the bill
Pods suit sustained allocation when the exact configuration fits. Flex suits real gaps between running workers. Active workers trade a billable warm floor for readiness. None of those is a benchmark ranking.
The November 2 public card keeps all 42 Pod prices unchanged but raises seven Flex inputs. For the illustrated capacity points, compute-only crossover against a 720-hour Secure Pod now spans 348.2 to 566.4 aggregate Flex worker-hours. Those are planning comparisons with the hardware and pooling caveats above, not measured savings.
Check how the endpoint was created: console and REST v2 idle defaults differ. Count running startup, execution, waiting and every worker; check retained storage after compute stops. Before buying, capture the available configuration and quote, then reconcile one isolated run and verify cleanup. A cheap headline rate, a completed job and a small prepaid balance each answer a different question.
Choose the next RunPod decision
- You need an allocated GPU for sustained work: read the RunPod deployment review for the Pods-versus-Serverless operating split, warm-capacity risk, and workload fit.
- You need to compare an endpoint with other serverless options: use the serverless GPU pricing matrix to compare rate shape, scale-down behavior, and bill-verification limits before choosing a platform.
- You have a workload shape and need a planning number: use the GPU cloud cost calculator to model active time, idle tails, retained resources, and teardown rather than multiplying a headline hourly rate by a month.
Choose the next RunPod decision
- You need an allocated GPU for sustained work: read the RunPod deployment review for the Pods-versus-Serverless operating split, warm-capacity risk, and workload fit.
- You need to compare an endpoint with other serverless options: use the serverless GPU pricing matrix to compare rate shape, scale-down behavior, and bill-verification limits before choosing a platform.
- You have a workload shape and need a planning number: use the GPU cloud cost calculator to model active time, idle tails, retained resources, and teardown rather than multiplying a headline hourly rate by a month.
Sources and verification notes
All official sources linked below were retrieved successfully on November 2, 2026. These are public sources, not authenticated account responses or measured invoices.
- Public rate card: all 42 Pod prices, Community/Secure structured offers, all 13 Flex prices and current memory labels. Its metadata says October 28; the comparison baseline is HostFleet’s October 17 article, not an inferred effective date.
- Pods pricing, management and storage: compute/storage granularity, stopped local storage, restart risk and persistence.
- Serverless pricing, worker lifecycle and endpoint settings: running versus scaled-down billing, image-pull exception, retries, console/API defaults and separate per-second rate discrepancy.
- Operation reference, v1 billing, v2 billing and deletion: job/API boundaries and proposed cost reconciliation.
- Billing overview, Pod billing history and network-volume billing history: prepaid behavior, non-refundable credits and separate resource-level cost records.
HostFleet’s gpu-pricing.json supplies the selected-product baseline, including today’s selected Flex updates. The complete RunPod-card check does not advance its September 24 dataset-wide date. Cross-provider guides retain their own dated inputs. All amounts beyond directly published prices are arithmetic with assumptions stated; no stock, throughput, exact bill cutoff or settled invoice is implied.
Need a self-managed GPU Pod? This labeled affiliate link supports HostFleet’s research: RunPod signup (affiliate). Verify the exact account-visible quote and available configuration before purchase. Source citations remain direct and non-affiliate.