hostfleet /v2
ai-hosting

Replicate for AI inference APIs and jobs (July 2026): fast to ship, expensive once you buy warm control

By Alex Harmon ·

Affiliate disclosure: HostFleet may earn a commission if you sign up through links on this page. That never changes the recommendation. Read the live HostFleet about page for methodology and affiliate-policy context. This article is mostly source-backed on Replicate’s current pricing, billing behavior, deployment controls, retention rules, and rate limits, with a narrow estimate layer for what continuously warm deployment capacity really costs over a full month.

Last updated: July 12, 2026

Replicate for AI inference APIs and jobs

If you are evaluating Replicate for AI hosting, the real question is not whether Replicate can run inference. It can. The real question is which Replicate product shape you are actually buying: an always-warm official model, a shared-queue community model, or a deployment where you now own warm capacity and idle spend.

This is a mixed, mostly source-backed HostFleet review built from Replicate’s current pricing and docs plus HostFleet’s provider note. The sourced layer is what buyers can verify directly: hardware-runtime rates, public-vs-deployment billing behavior, deployment scaling defaults, API rate limits, runtime timeouts, retention windows, and prepaid-credit rules. The estimate layer is narrower and explicit: what a continuously warm deployment roughly costs over a full month if you stop treating Replicate like a scale-to-zero shared pool and start holding instances online.

The scope is narrow on purpose:

  • this is about AI inference APIs, jobs, and deployment-backed model hosting on Replicate
  • this is not a benchmark post pretending fresh throughput numbers exist here
  • this is not flattening official-model pricing into the same bucket as deployment hosting
  • this is not a model-subscription or token-pricing roundup

If you need the broader market map first, start with Every serverless GPU host compared. If your immediate decision is Replicate versus other small-endpoint platforms, pair this with RunPod vs Modal vs Replicate for shipping a small inference API. If you want the adjacent single-provider reviews, keep Modal for AI inference APIs and jobs and RunPod for AI inference APIs and jobs open beside this. And if you are still deciding between managed inference and owning GPU capacity directly, Cloudflare Workers AI vs self-hosted GPU is the right companion read.

The short answer

What you actually needBest Replicate fitHonest cost shapeWhy it fitsMain catch
One official model endpoint with predictable output pricingOfficial modelsClean and predictableOfficial models are always warm, stable, and priced by outputs or tokens rather than raw hardware secondsThis is a different product shape from custom model hosting
Community model with low duty cyclePublic or community modelGood when bursts are intermittentPublic models bill only active processing time, and setup plus idle time are freeYou share the queue and hardware pool, so cold boots and scaling delays still happen
Stable endpoint for a model you rely on heavilyDeploymentMore expensive than buyers expect once instances stay warmYou get your own hardware, scaling controls, and a stable endpointDeployments bill setup, idle, and active time
Long-lived production service that must keep state, routes, and serving behavior under tighter app controlUsually not Replicate firstWrong abstraction if service shape matters more than model deliveryReplicate is strongest when prediction-style workflows are acceptableA custom-service platform is usually a better fit
Durable audit trail inside the platformWeak fit by defaultYou need your own persistence layerWebhooks and polling are straightforwardAPI-created inputs, outputs, files, and logs are deleted after one hour by default

My practical verdict is simple: Replicate is excellent when a prediction-first product shape is acceptable and costly when you try to turn it into a permanently warm custom serving platform without pricing that choice honestly.

What Replicate actually is

A lot of bad buying advice on Replicate starts by pretending it is one thing. It is not.

Replicate currently spans three distinct buyer experiences:

  • official models that are always warm, have stable APIs, and use predictable per-output or per-token pricing
  • community or public models that usually bill by hardware runtime and active processing time on shared pools
  • deployments that let you pin hardware and scaling policy for your own stable endpoint

That distinction matters more than the homepage copy.

Official models are the cleanest product if one of Replicate’s maintained models already does the job. The official-model docs say they are always on, expose a stable API, and are priced by predictable metrics like output images, video seconds, or token counts.

Community models are much more hosting-shaped. The community-model docs say they are maintained by their creators, not by Replicate, and that they are priced by hardware usage and runtime. If you care about exact model versions, custom packaging, or community fine-tunes, that is usually the lane you are entering.

Deployments are what you buy when you want more control. Replicate’s deployment docs say deployments give you a stable endpoint, hardware flexibility, minimum and maximum instance controls, and autoscaling behavior that can keep instances warm.

That is why this review exists. For HostFleet readers, the real decision is usually not “Replicate or not?” It is “am I buying a prediction product, a shared model runtime, or dedicated warm capacity?”

The public pricing page is useful, but it only tells part of the cost story

As of July 12, 2026, Replicate’s public pricing page lists these baseline hardware rates for runtime-priced workloads:

  • CPU Small: $0.000025/second
  • CPU: $0.000100/second
  • Nvidia T4: $0.000225/second
  • Nvidia L40S: $0.000975/second
  • Nvidia A100 80 GB: $0.001400/second
  • Nvidia H100: $0.001525/second

Replicate also publicly lists higher multi-GPU variants such as 2x A100, 2x L40S, and 2x H100, with additional preview multi-GPU capacity available through committed-spend contracts.

Those prices are real, but they are not enough by themselves to tell you what you will actually pay, because Replicate bills different product shapes differently.

Public models are cheap to try because idle time is hidden from you

Replicate’s billing docs are very clear on the public-model path:

  • for public models, you only pay while the model is actively processing your request
  • setup time and idle time are free on public models
  • you are sharing a hardware pool and queue with other customers
  • shared pools can still expose cold boots and scaling limits

That is why Replicate feels so attractive at small scale. You can use serious hardware without explicitly paying to keep it warm all day.

But that convenience comes with tradeoffs:

  • you do not own the queue
  • you do not own the warm pool
  • you do not get predictable low-latency behavior just because the endpoint exists
  • community-model stability depends partly on the model author, not just on Replicate

For experiments, low-duty-cycle internal tools, and many bursty jobs, that tradeoff is totally reasonable.

Deployments are where Replicate turns into real hosting

The deployment path is the one most relevant to buyers who say they want “Replicate hosting” rather than just “Replicate access.”

Replicate’s billing docs say deployments are charged like private models:

  • you pay for the time deployment instances spend setting up
  • you pay for the time they spend idle
  • you pay for the time they spend actively processing

The deployment docs add the control knobs:

  • choose hardware such as T4, A100, H100, and other supported GPUs
  • set minimum instances and maximum instances
  • keep some instances warm with a nonzero minimum
  • auto-scale up and back down with demand
  • use a stable endpoint and zero-downtime rollouts

Replicate’s billing visualization also says models scale down to the minimum number of instances set, with 0 by default. That is the crucial detail. The cheap way to start is the same cheap way most serverless GPU platforms start: let the floor be zero and accept that requests can wait for setup.

The moment you push min_instances above zero to protect latency, you are no longer buying only execution time. You are buying continuous availability.

Estimate: what one continuously warm deployment costs

These are simple estimate examples, not vendor quotes. Assumptions:

  • 30-day month
  • one instance held online continuously
  • raw hardware cost only from the public pricing table
  • no extra overhead for retries, setup failures, or ancillary storage

Approximate one-instance monthly floor:

  • T4 at $0.000225/second: about $583/month
  • L40S at $0.000975/second: about $2,527/month
  • A100 80 GB at $0.001400/second: about $3,629/month
  • H100 at $0.001525/second: about $3,953/month

That is the main Replicate hosting lesson in one block: public-model pricing feels light because idle time is hidden, but deployments make warm capacity visible on the bill very quickly.

Rate limits and runtime limits are sane, but they define the product shape

Replicate’s API rate-limit docs say:

  • you can create predictions at 600 requests per minute
  • all other endpoints can be called at 3000 requests per minute
  • granted-credit accounts without a payment method are limited further to 1 request per second and 6 requests per minute

Those limits are fine for many products, but they matter if you are trying to fan out aggressively or run a gateway pattern through Replicate.

Runtime limits matter too. Replicate’s prediction lifecycle docs say:

  • predictions time out after 30 minutes of runtime by default
  • you can set deadlines to abort or cancel a prediction earlier
  • if a deadline is exceeded before a prediction starts, it becomes aborted
  • if a deadline is exceeded after it starts, it becomes canceled

The create-prediction docs also keep the intended usage pattern obvious:

  • use webhooks when you want event-driven completion
  • use polling when you cannot expose a webhook handler
  • sync-mode wait duration is separate from overall prediction deadline

This is not a criticism. It is just the reality that Replicate is built around predictions that complete, not around a forever-running custom app surface.

Retention is one of the easiest production gotchas to miss

Replicate’s data-retention docs are one of the most important operational pages in the whole stack.

For predictions created through the API:

  • input parameters, output values, output files, and logs are automatically removed after one hour by default

For predictions created through the web interface:

  • data is kept indefinitely

That is a meaningful constraint for production apps.

If your product needs any of these, you should treat them as your responsibility:

  • durable job history
  • output replay
  • audit logs
  • debugging context after the fact
  • customer-visible result history

Replicate gives you webhooks and polling hooks. It does not, by default, give you long-lived API result retention.

Prepaid credit is another real operational edge

Replicate’s billing system is prepaid, and the sharp edges are clearly documented.

The prepaid-credit docs say:

  • you must buy credit upfront before using Replicate
  • auto reload is optional
  • the minimum auto-reload threshold is $5
  • the minimum reload balance is $15
  • when your balance hits $0, Replicate prevents new work from starting and shuts down infrastructure it is running for you

That last point matters for deployment-backed workloads in particular. A zero balance is not just an accounting issue. It is a runtime event.

If a team is used to postpaid cloud billing, this is one of the easiest ways to get surprised by a production incident that was actually a credit-management failure.

Where Replicate is strongest

Replicate is strongest when most of these are true:

  • the product can stay prediction-first rather than custom-service-first
  • one of Replicate’s official or community models already fits the use case
  • async jobs, polling, or webhooks are acceptable patterns
  • you want the fastest route from model to usable API
  • you do not need a durable in-platform result history

That includes practical use cases like:

  • image, video, and multimodal generation workflows
  • internal tools that call community models only when needed
  • public products that can tolerate shared-pool behavior at lower traffic levels
  • teams that want a stable official-model API without managing GPU runtime details

Where Replicate gets awkward fast

Replicate gets awkward when most of these are true:

  • you need a custom multi-route service, not just predictions
  • latency targets require continuously warm dedicated instances
  • you want to keep detailed outputs and logs without building your own persistence layer
  • your operators want infra-shaped control over workers and warm pools
  • your product team will be confused by three different pricing shapes under one vendor name

This is where the linked Modal for AI inference APIs and jobs and RunPod for AI inference APIs and jobs reviews become useful. Replicate is often the fastest path when you accept its product shape. It is often the wrong path when you are really looking for a custom serving platform and only happen to like its model catalog.

FAQ

Is Replicate good for AI hosting?

Yes, if AI hosting means prediction-style access to official or community models and not necessarily a custom long-running service stack.

Is Replicate cheap?

It can be cheap for bursty use of public or community models because setup and idle time are free there. It becomes much less cheap once you move to deployments and keep instances warm.

What is the biggest Replicate gotcha?

The biggest one is product-shape confusion: official models, public community models, and deployments do not bill the same way and should not be compared as if they do.

Does Replicate keep outputs and logs forever?

Not for API-created predictions. Replicate’s docs say those inputs, outputs, files, and logs are removed after one hour by default.

When should I use a deployment?

Use a deployment when you need your own stable endpoint, hardware choice, and scaling controls. Just price the warm-capacity floor honestly before you assume it is still the cheapest path.

Final verdict

If I had to compress the whole decision into one sentence, it would be this: Replicate is a great prediction product and a decent deployment platform, but the price and operational story changes completely once you stop sharing the pool and start paying to keep your own instances warm.

That is the honest July 12, 2026 answer to Replicate for AI inference APIs and jobs without pretending one vendor page explains three different product shapes equally well.

Sources