Research-backed calculator guide

Replicate Pricing by Model: Per-Second Hardware, Output Units and Idle Time

Compare Replicate per-second hardware billing with output-unit pricing, private-model idle time, and deployment costs using dated formulas and a worked example.

Replicate does not have one universal price meter. The right estimate depends first on what the model bills and second on which runtime state is chargeable. A public model may charge only for active processing seconds. A model priced by output may charge per image, token, or second of generated media. A private model or deployment can charge for the whole time an instance is online, including setup and idle time.

The four billing questions to answer first

1. What is the model's billing unit?

Read the model's Run time and cost or pricing section before doing arithmetic. Replicate's catalog contains models billed by hardware time and models billed by input or output. Its pricing page gives examples such as image prices, token prices, and generated-video prices alongside hardware rates. ^[1]

A per-second rate is a resource meter. It tells you the price of one second on a specified CPU or GPU configuration. It does not tell you how many seconds a request will take, how many retries you will make, or how many instances your traffic will keep online.

An output rate is a result meter. It can be easier to budget when every accepted image or video second has a known unit price. It still requires care: “per image,” “per token,” and “per second of output video” are different units. A video model charging per second of generated video is not the same as a model charging per second of GPU execution.

2. Is the model public, private, or a deployment?

Public-model economics are usually burst-friendly because the shared service absorbs setup and idle periods for billing purposes. Replicate documents public models as charging only for active processing time, with setup and idle time free. ^[2]

Most private models use dedicated hardware. Replicate says those models charge for the time instances are online: setting up, waiting idle, and actively processing. A deployment has the same online-time principle, even when it is based on a public model. ^{[1] [2]}

This distinction matters more than a small difference between two GPU rates. A low-volume private deployment with one always-on GPU can spend most of its monthly budget waiting. A public model can have cold starts or queueing, but those free setup and idle seconds should not be silently added to a public active-time estimate.

3. What does “idle” mean for your configuration?

Replicate describes an instance lifecycle as offline, setting up, active, and idle. Deployments can scale from zero, or maintain a minimum number of warm instances. The minimum is a cost-control choice: a higher minimum can reduce cold-start exposure but increases the amount of online hardware time in the estimate. ^{[2] [3]}

For a deployment, model the calendar window, not only the sum of prediction durations. If one A100 instance remains online for eight hours per day across 22 business days, the online-time input is 633,600 seconds even if the model processes only a small fraction of that time. The instance may be “idle” from the application's perspective while still chargeable under the deployment meter.

4. Which events are excluded or charged separately?

Include retries, downstream model calls, and unsuccessful work in a realistic estimate. Replicate notes that a model calling other models is billed for the root model and downstream models. Its billing documentation also distinguishes a failed run from time consumed by private-model or deployment instances. ^[2]

Do not assume that a completed output is the only billable event. A public prediction that is canceled can still be charged for the time it ran, while a private or deployed instance can continue to incur normal online-time charges. Record prediction IDs, status, active duration, hardware, output count, and retry reason so the estimate can be reconciled to the invoice later.

Replicate hardware rates versus output rates

The following vendor figures were observed on Replicate's pricing page on November 2, 2026. They are list rates at that date, not a promise that a particular model selects that hardware. Replicate displayed A100 at $0.001400/sec ($5.04/hour), H100 at $0.001525/sec ($5.49/hour), L40S at $0.000975/sec ($3.51/hour), and T4 at $0.000225/sec ($0.81/hour). The hourly conversions use 3,600 seconds per hour and are arithmetic checks of the displayed rates. ^[1]

The same page displayed examples of output billing, including $0.04 per output image for FLUX 1.1 Pro, $0.025 per output image for FLUX Dev, and $0.09 per second of output video for one listed video model. It also showed a token-priced example. These examples are model-specific and can change, so date every spreadsheet or budget snapshot and re-check the model page before committing spend. ^[1]

A useful comparison is not “which headline rate is smaller?” It is “which meter matches the workload?” If the output rate is $0.04 per image and a hardware-billed run takes 18 seconds on an A100, the hardware-only equivalent is $0.0252 per run (18 × $0.0014). The hardware option is lower in that narrow public-model scenario. If the same run takes 30 seconds, it becomes $0.042 per run and the output-priced option is lower. The break-even active duration is:

$0.04 ÷ $0.0014/sec = 28.57 active seconds

That is an estimate, not a performance claim. It excludes retries, setup, idle time, downstream calls, storage, network charges, taxes, and any account-specific discount or credit.

Worked cost example: 1,200 image requests

Assume a team wants to process 1,200 requests in a month. It expects one accepted image per request and has measured 18 active processing seconds per run on an A100 for a public hardware-billed model. It also wants to compare a model listed at $0.04 per output image. The following table is an original estimate using those inputs.

The private/deployment row is intentionally a different scenario, not an extra fee to add to the public result. It assumes one A100 instance is online for the full eight-hour window and that the online seconds are billable. The active work still accounts for only 21,600 seconds, or $30.24 at the A100 rate, so the implied setup-and-idle portion is $856.80 under these assumptions. A scale-to-zero deployment, a lower minimum instance count, more concurrency, or a different hardware choice would change that estimate. Replicate describes minimum instances and online deployment time as configuration-dependent, so measure the actual instance timeline instead of copying this illustrative result. ^{[2] [3]}

The output comparison also needs an output-quality assumption. “1,200 requests” is not automatically “1,200 billable images” if your application creates multiple candidates, retries rejected images, or asks one request to return several outputs. Replace the output count with the vendor-defined billable unit from the model page. For a token model, replace images with input and output token counts and use separate rates; for a video model, distinguish generated-output seconds from hardware execution seconds.

A practical estimate worksheet

Start with a row per model and record the source URL and date. Then fill in the following fields:

1. Billing unit: hardware seconds, input tokens, output tokens, images, output-video seconds, or another model-defined unit.
2. Vendor rate: keep the currency and unit exactly as displayed. Convert hourly rates to seconds only with hourly rate ÷ 3,600.
3. Workload volume: requests, accepted outputs, input tokens, output tokens, or generated media seconds.
4. Runtime distribution: use measured median and high-percentile durations when the meter is time-based. A single average can hide slow inputs and retries.
5. Runtime state: public active time, or private/deployment online time split into setup, active, and idle seconds.
6. Failure and retry policy: count paid work that does not become an accepted output, and identify downstream model calls.
7. Excluded costs: storage, bandwidth, application hosting, orchestration, human review, taxes, credits, discounts, and any provider feature not represented by the model rate.

For a monthly budget, keep the raw usage ledger rather than storing only a total. The AI API invoice reconciliation calculator can help map usage rows to invoice categories. For token-based Replicate models, use the AI token cost calculator to keep input and output units separate. For a broader provider comparison, use the LLM cost calculator and document where Replicate's model-specific meter does not map directly to token pricing.

Common estimation mistakes

Treating every Replicate model as per second. The pricing page explicitly contains both time-based and input/output-based examples. Always read the selected model's rate card. ^[1]

Adding free public idle time to the bill. Public setup and idle time are described as free. Do not import private-deployment idle assumptions into a public-model estimate. ^[2]

Ignoring private online time. A short prediction can still be attached to an instance that was online for a longer period. Use deployment minimum and maximum settings, instance counts, and observed lifecycle timestamps. ^[3]

Comparing output price with raw GPU price without a duration. A per-image quote and a per-second quote become comparable only after you supply output count or active duration.

Using a stale rate. Provider pricing and model catalogs change. This article's quoted figures are dated November 2, 2026; re-check the model page and record the observation date before using them in a purchase decision. ^[1]

FAQ

Is Replicate cheaper per second or per output?

Neither meter is universally cheaper. On the worked assumptions, 18 A100 active seconds cost $0.0252 per public-model run, below a $0.04 output-image price. At 30 active seconds, the same A100 rate reaches $0.042, above that output price. The break-even depends on hardware, duration, number of outputs, and whether setup or idle time is chargeable.

Does Replicate charge for idle time?

It depends on the execution mode. Replicate's billing documentation says public models charge for active processing and do not charge setup or idle time. Most private models and deployments charge for the time instances are online, including idle time. Fast-booting fine-tunes are an exception described by Replicate as active-processing-only. ^[2]

How do I estimate the cost of a private Replicate model?

Estimate online seconds rather than only prediction seconds: instance count × online seconds × hardware rate. Split the result into setup, active, and idle portions so you can see what utilization would need to improve. If the model scales horizontally, calculate each instance's online window and add them. Use actual deployment settings and logs for a production estimate; the worked table's eight-hour A100 window is only an example.

Are Replicate output units the same as model runtime seconds?

No. A model can charge per output image, token, or generated-media second, while another model charges for hardware execution seconds. A one-second video output could take much longer than one second of GPU time, and an image request could produce multiple billable outputs. Use the exact unit named on the selected model's pricing section.

Do failed or canceled predictions cost money?

The treatment depends on model and runtime state. Replicate documents that failed runs are not charged in general, but private models and deployments can still be billed for the time their instances were active; canceled official-model runs may be charged for the time they ran. Treat failures and cancellations as explicit ledger states and confirm the current billing documentation for your configuration. ^[2]

What should I record for an invoice reconciliation?

Record the model and version, billing unit, hardware, prediction ID, request and output counts, active duration, instance online duration where applicable, status, retry or downstream calls, and the pricing-page observation date. This makes a per-second estimate auditable and prevents an output-priced workload from being mistaken for a GPU-second workload.

Limitations and assumptions

This comparison uses vendor list rates observed on November 2, 2026 and arithmetic estimates for clearly stated hypothetical workloads. It does not estimate search volume, ranking, traffic, revenue, taxes, discounts, prepaid credits, storage, bandwidth, application hosting, queueing penalties, or a guaranteed model latency. Hardware availability and model behavior can change. The private/deployment example assumes one instance is online continuously during the stated work window; it is not a claim about the minimum cost of every deployment. Validate the selected model's current rate card, billing mode, and observed durations before approving spend.