Replicate AI

Verified against Replicate's live pricing and documentation on November 5, 2026. The evaluation uses documented behavior and calculated example bills.

What Is Replicate AI?

Replicate runs a model, a packaged program that accepts inputs and returns outputs, on infrastructure it manages. Your application sends a prompt, file, or other model-specific input; Replicate creates a prediction, its name for a single run, and returns the result or a job identifier you can check later. The catalog includes open-source and proprietary models, so availability on Replicate does not itself mean a model is open source. Replicate is now owned by Cloudflare: Replicate's November 2025 announcement said its brand and API would continue, and Cloudflare's completion announcement confirmed it was officially part of Cloudflare on December 1, 2025. That ownership does not make every Replicate model an edge-hosted service; choose from the capabilities documented for the endpoint you will use.

Who Should Use Replicate, and Who Should Skip It?

Replicate fits a builder adding model inference, the process of running a trained model, to a product that already has somewhere to handle users, jobs, and files. An image-generation feature in a SaaS app, an asynchronous video editor, or a custom image classifier can each use this arrangement. You avoid operating GPU servers, but still own the product workflow and the decision about which outputs are acceptable.

The useful shortlist depends on what you are deploying. These are workload-based judgments, not measured speed rankings.

Modal fits better when you want to express a custom GPU application and its environment in Python; its code-defined execution model gives you more application-level control, with more serving code to own. See Modal pricing for the bill that follows from that choice.

fal AI vs Replicate

fal deserves the first comparison for a product centered on generative media. Replicate deserves the first comparison when the same application also needs community models or your own packaged model. If both expose your chosen model, compare the input options, output unit, operational controls, and data policy for those endpoints. A platform-wide claim that one is always faster or cheaper is not a useful purchasing rule.

Skip a catalog-first approach altogether if your decision has already become a sustained hardware-capacity purchase. The broader GPU cloud providers comparison covers that next choice. Likewise, a nontechnical operator seeking a finished support agent or video-editing application should buy the application; a model endpoint leaves substantial product work to build.

Run a Model: From Selection to an API Call

Replicate makes the first integration small, but the model's API schema, the list of accepted inputs and returned fields, still decides what your application must send and receive.

Replicate AI Models

Replicate separates official models from community models. Its official-model documentation promises always-warm instances, stable input/output APIs, active maintenance, and predictable input or output billing. An official model can be called by its owner and name without a version identifier.

The community-model documentation describes a different contract: API calls identify a specific version, billing generally follows hardware time, and infrequently used models can encounter cold boots. Version pinning means your request names a particular packaged revision; it does not make every model's license or input fields identical.

For a product feature, choose the model before writing the integration. Check its license, accepted file types, required parameters, output shape, and pricing unit. Copying a request from an image model and replacing its name with a speech model is insufficient because their inputs differ.

Replicate AI Image Generator

Replicate exposes image generation as individual model endpoints. Black Forest Labs FLUX Schnell, for example, accepts a text prompt and returns generated image output. A founder adding concept-image generation can first choose the model's inputs in its browser interface, then use the same schema from a backend.

Create an API token in your account and put it in the backend's REPLICATE_API_TOKEN environment variable. Replicate's token documentation treats tokens as passwords; keep them out of browser-delivered code and use separate tokens for separate environments.

With that variable set, this is a runnable HTTP request. Running it uses your Replicate account and may incur the model's charge.

curl --fail-with-body --silent --show-error \
  https://api.replicate.com/v1/models/black-forest-labs/flux-schnell/predictions \
  --request POST \
  --header "Authorization: Bearer $REPLICATE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --header "Prefer: wait" \
  --data '{"input":{"prompt":"A matte ceramic teapot on a wooden kitchen table","num_outputs":1}}' \
  > prediction.json

The response is a prediction object. Inspect its status, output, and error fields instead of assuming that a successful HTTP request means generation has finished. The prediction-creation docs specify a default 60-second wait when Prefer: wait is used. That is a request-wait setting, not a latency promise. If the run remains unfinished, the response contains a starting or processing prediction and a urls.get address for subsequent checks.

Remove Prefer: wait to use the default asynchronous behavior. The API then returns a job identifier without waiting for completion. Official models, community models, and deployments have different creation routes, documented in the HTTP API reference; use the example generated for the model or deployment you selected.

Build a Background Workflow for Video, Speech, and Text

Replicate works best for longer jobs when your app keeps a job record and collects results after submission. A webhook, an HTTP notification sent to your server, lets the app react to completion instead of leaving a user waiting on an open request.

Consider a product that turns a customer's approved script into an illustrated clip. Generate the media, record the prediction ID against the customer's job, and collect the finished files before assembling the deliverable. Replicate's webhook documentation explicitly supports saving prediction data and passing the output of one model into another. The orchestration and final customer-facing job state remain your application's responsibility.

For video, inspect the text-to-video collection and then the chosen model's API. A text-to-video model and an image-to-video model require different starting material. Store the selected model and inputs with the job so that a failed or unsatisfactory result can be understood later.

Replicate Voice AI

Replicate's text-to-speech collection provides models that turn written text into audio. For a narrated product walkthrough, pick a model whose language and voice controls match the script, generate the narration, and save the audio alongside the rest of the job. Do not assume that the presence of speech models proves suitability for an interactive phone conversation; that requires evaluating the chosen endpoint's response behavior in your application.

Replicate also hosts large language models, models that generate and interpret text, including entries in its language-model collection. Use one to draft the narration or classify an incoming request, then validate that output before handing it to another stage. Keep script review and final assembly in the application workflow so a poor intermediate result does not become a finished customer deliverable.

Deploy Your Own Model with Cog

Replicate can serve your own trained model when the public catalog does not contain the logic you need. Cog is the open-source packaging tool that puts your code, dependencies, and model weights into a container, a reproducible software environment.

For example, a retailer with an existing product-image classifier can package that classifier and expose it as a private API. This is a deployment workflow for a model you already have. It does not train a useful classifier merely because you upload a folder.

Replicate's custom-model deployment guide and Cog push guide describe the following path.

The practical wall is packaging ownership. You no longer operate the GPU cluster, but you still need working inference code, compatible dependencies, appropriate hardware, and a model that produces useful results. If the model requires more memory than the selected machine provides, an API wrapper does not remove that requirement.

Control Capacity with a Deployment

Replicate deployments give you a dedicated endpoint and control over hardware and scaling. That matters when a model becomes a product dependency and a shared queue is no longer an acceptable operational choice.

The deployment documentation describes minimum and maximum instance counts, scale-to-zero, monitoring, and rolling version updates. An instance is one running copy of your model. A minimum of 1 keeps a copy available; a minimum of 0 permits the service to shut down unused capacity. Keeping one copy warm does not imply that an unlimited traffic burst needs no additional capacity.

For a customer-facing image classifier, choose the minimum around responsiveness needs and the maximum around the capacity you are prepared to fund. Watch active, idle, and starting instances alongside errors and request latency. If a deployment sits idle much of the day, the capacity decision belongs in the cost review. If it repeatedly reaches its maximum, adding more API retries will not create more configured capacity.

What Replicate Costs

Replicate charges for usage, with the billing unit determined model by model. The live pricing page says some models use hardware and time, while others use input and output. There is no single per-request price that describes the platform.

These are published examples, not a claim that they are the newest or best models for your workload:

For a small builder, the sensible starting point is a public model with the right output and billing unit. On a time-billed public model, you pay for processing your requests; setup and idle time are free. Deployments and most private models change that boundary: setup, active, and idle instance time are billable. The documented exception for private models is a labeled fast booting fine-tune, which charges only active processing time.

The billing documentation also distinguishes prepaid accounts from accounts billed in arrears. Prepaid usage deducts from credit; arrears accounts are charged at the start of the month for the previous month's usage.

Two calculated examples show why the distinction matters. 10,000 FLUX Schnell output images in a month cost $30 at the listed output rate, before other services or additional generated images. Separately, one T4 kept online for a 30-day month costs $583.20: 720 hours multiplied by $0.81, before any extra scaled instances. These are different purchasing arrangements, not a benchmark claiming that a T4 reproduces the image service's output or throughput.

The general rule is that failed runs are not charged, but the billing docs retain charges for active private-model and deployment instances, time consumed before cancellation on time-billed models, and possible official-model cancellation charges. A model that calls other models can also incur downstream charges, including when the overall run fails. Estimate the cost of the complete workflow you intend to run.

The Production Limits That Change the Decision

Replicate removes GPU operations from the initial integration, but its documentation still leaves concrete limits your application must handle.

Cold Starts and Shared Capacity

Replicate calls a cold start a cold boot: the model needs its environment and weights loaded before it can process the request. The platform architecture explanation says popular public models are often kept warm by ongoing usage, while less-used models encounter cold boots more often. Official models have the separate always-warm commitment described earlier.

The consequence is specific: an interactive feature built on an occasional community model needs a waiting state, or a deployment configured to keep capacity available. A background batch can tolerate startup differently from a user waiting for an immediate result. There is no universal latency number to substitute for evaluating that exact model and workload.

Rate Limits Tighten When Credit Runs Low

Replicate's rate-limit documentation specifies 600 prediction-creation requests per minute and 3,000 requests per minute for other endpoints. Short bursts above the defaults are possible; throttling returns HTTP 429, and higher limits require contacting Replicate. These are API request limits, not a promise that the model completes that many jobs per minute.

A less obvious constraint is the account balance. Replicate applies stronger rate limits as credit runs low and recommends automatic reload to keep the balance above $20. Accounts with granted credit and no payment method have a separate limit of 1 request per second, capped at 6 per minute.

That means a queue can slow because of billing state before the engineering team has changed any deployment settings. Monitor credit alongside request errors, use bounded retries with backoff for throttling, and avoid aggressive polling that consumes the other-endpoint allowance.

Data Handling Differs Between the API and Browser

Replicate's data-retention documentation says API prediction input parameters, output values, output files, and logs are removed after an hour by default. Your application must save the data it needs before that removal. A returned file URL is therefore not your permanent asset store.

Browser-created prediction data is kept indefinitely. The website provides a Delete action to remove a prediction and its associated output data and files. A browser experiment and an API integration consequently have different retention behavior; do not use one to infer the other.

For a production workflow, save the completed media into storage you control and retain the model, inputs, and job status your support process needs. Model visibility is a separate issue: making a custom model private controls who can access it, but does not establish a different retention promise. Likewise, the retention page alone is not evidence for a blanket statement about training use, regional residency, or every contractual data-handling requirement.

Model Choice Remains an Application Responsibility

Replicate's catalog is a distribution and execution layer. Commercial permissions still depend on the selected model's license, and community schemas differ. Treat a model change as an application change: check input validation, file outputs, permissions, and cost before switching production traffic. A uniform platform does not make every model interchangeable.

Verdict: Start Shared, Buy Dedicated Capacity for a Specific Reason

Replicate is a strong choice when the valuable part of your product is what you build around a model, and avoiding GPU operations lets you ship that product sooner. Start with a suitable public endpoint. Prefer an official model when its documented availability, stable interface, and billing unit meet the requirement.

Move to a deployment when you can name the reason: custom inference code, control over hardware, dedicated capacity, or a warm instance for a customer-facing feature. Accept the setup and idle bill as part of that decision. If the defining requirement is instead a media-specific catalog, language-model serving, Hub-based deployment, or a broader Python compute application, use the alternatives above as your shortlist.

The first implementation milestone should be a complete job: submit it, identify completion, save its output, and account for its cost. Only then decide whether the public endpoint or dedicated deployment belongs in production.

Replicate Questions

Use the AI business workflow audit checklist to map the work around the model before committing the feature.