Search for "Dify pricing" and the answers usually compare different things: how much a Cloud subscription costs, how much model calls cost, and how large the server bill for self-hosting is. These are three separate bills, and mixing them up easily leads to the wrong conclusion that "the cloud is expensive" or "self-hosting is free."

Dify is an orchestration layer and does not produce models. Whether you use Cloud or self-host, model call charges exist separately. This article separates platform fees, model fees, and operations fees, and gives an estimation order. Prices and quotas change, so this article does not lock in numbers; refer to the vendor pages and the in-site model pricing page.

Note: Dify is a trademark of LangGenius, Inc. This is an independent technical note with no affiliation or agency relationship with the Dify team. Other product names mentioned belong to their respective owners.

1. Split the bill into four layers first

Cost layer Dify Cloud Self-hosted Easy to miss
Platform Subscription covering members, features, and quota No subscription fee for the community edition, but license conditions apply Subscriptions are monthly or annual; check the license for commercial use
Model Built-in AI credits, or your own provider key Your own provider key or a unified gateway Billed by token, image, or request
Infrastructure Included in the subscription Servers, database, vector store, object storage, bandwidth Shows up line by line on the cloud bill
Operations Handled by the platform Upgrades, backups, monitoring, security, on-call Labor is the cost most often counted as zero

Cloud bundles infrastructure and operations into the subscription; self-hosting hands those two layers back to you. Compare on the same basis: either total cost over three years, or monthly cash spend. Comparing a subscription price with a server price tells you nothing.

2. Dify Cloud: the subscription buys quota and peace of mind

Cloud subscriptions are billed per workspace and determine the member limit, features, and quota. As of the October 2026 documentation, there are three tiers: Sandbox, Professional, and Team. Sandbox is free and includes one-time AI credits that are not replenished; the upper tiers have higher quotas. Refer to the Dify pricing page for specifics.

Two kinds of quota are easily confused with the subscription fee:

  • AI credits: used for the platform's built-in models; once exhausted you can switch to your own provider key and costs move to your model account.
  • Knowledge-base storage: measured by vector usage, not file size; only high-quality indexing consumes storage, while economical indexing does not count against quota.

How much a document consumes depends on chunk size, parent-child segmentation, and embedding dimensions. Each child chunk under a parent is a vector, and a high-dimensional model may use twice the space per chunk of a low-dimensional one. Once the quota is full, adding documents, editing chunks, and rebuilding indexes are blocked; existing knowledge bases remain searchable, but you must trim or upgrade first.

Cloud suits teams that do not want to manage servers and are not large. The risk is quota: knowledge-base growth, more members, or exhausted credits can all force an upgrade.

3. Self-hosting: no subscription fee does not mean cheap

The community edition can be self-hosted with zero software subscription, but the license is not unconditional Apache 2.0: running a multi-tenant SaaS requires written permission; if you use its front end, you may not remove or modify the logo and copyright notices; ordinary commercial use is permitted. If you plan to package Dify as a SaaS offering, assess the license first.

A complete self-hosted stack includes at least api, worker, web, plugin_daemon, PostgreSQL, Redis, a vector database, nginx, and a sandbox service. The documented minimum is 2 CPU cores and 4 GiB of memory, which is enough only for a trial; production sizing depends on concurrency, document volume, and index scale.

The cost items are:

  • Compute: application, plugins, sandbox service.
  • Database: PostgreSQL storage, backups, and high availability.
  • Vector store: memory and disk dominate, and scaling up is not cheap.
  • Storage and network: object storage, backups, bandwidth, load balancing, certificates.
  • Operations labor: upgrades, plugin compatibility, vulnerability patching, monitoring, on-call.
  • Environment copies: test, staging, and production each need their own.

The last two are the easiest to miss. Self-hosting's "savings" are bought with labor; without an operations owner, the saved money may come back as outages and overtime.

4. Model calls: the part that really grows with usage

Model calls are metered and grow linearly with business volume. In Dify, every LLM node execution, every tool call in an agent, and every rerank and embedding call incurs upstream charges.

Three multipliers:

  1. Multi-step orchestration: agents and workflows carry the system prompt, history, and retrieved passages into later steps, so input tokens climb steeply with step count.
  2. Long context: stuffing a whole document or many retrieved chunks into a prompt can affect per-request cost more than the model's unit price.
  3. Retries and failures: timeouts, 429s, and 5xx responses can trigger retries; whether you are billed twice depends on upstream, so budget for the worst case.

Control is straightforward: small models for classification, rewriting, and extraction, a strong model for final generation; cap the number of retrieved chunks and per-chunk length; set an output limit; deduplicate identical requests. Streaming improves perceived latency only; it does not reduce billed output tokens.

5. RAG and knowledge bases: one-time plus ongoing cost

Knowledge-base cost has two phases: building and querying.

In the build phase, embedding is billed by input tokens, and chunk overlap, headers and footers, and repeated templates all count. Changing the model, dimensions, or chunking rules usually requires re-embedding everything, a one-time but potentially large expense. In the query phase, each question involves at least query embedding and vector retrieval, possibly rerank and a long generation input.

The cost-reduction order should be: clean the text first, then chunk by semantics and keep overlap within a useful range, then add incremental indexing, and only then consider a cheaper embedding model. Reverse the order and the usual result is a slightly cheaper model, but dirty text and duplicate indexes remain, the bill barely moves, and retrieval gets worse.

Economical indexing does not consume vector storage, but its retrieval method differs, so validate quality on your own question set. For support, contracts, regulations, and other recall-sensitive scenarios, do not switch just to save storage.

6. Workflows, caching, and budget caps

Do not budget by "number of runs." Two runs can differ by dozens of times in model calls: one may go through only classification and a template reply, while another may trigger multiple retrieval rounds, rerank, and long-form generation. The unit of estimation should be "average tokens per run" times "runs per month."

Caching usually saves money more directly than switching models:

  • Reuse answers to identical questions with a sensible expiry.
  • Cache retrieval results for high-frequency queries and invalidate by knowledge base when documents change.
  • Cache embedding results for identical text to avoid repeated vectorization.
  • Do not cache time-sensitive, personalized, or sensitive answers.

Put budget caps in three places: Cloud quota and billing alerts, provider-side usage limits where available, and per-key statistics and alerts on the gateway. Give each app or environment its own key so bills can be attributed to a business line; otherwise you see one large number at month end. Set thresholds at 50, 80, and 90 percent, degrade non-critical workflows first, and only then consider switching models.

7. A reusable estimation framework

Estimate in the following order.

  1. List apps and workflows, marking which call models and which only retrieve.
  2. Take real token usage from the last two weeks of logs and compute average input and output per run.
  3. Estimate monthly runs, separating peak and off-peak.
  4. List knowledge-base builds and re-embeddings separately; do not mix them into monthly inference cost.
  5. Add infrastructure bills: servers, database, vector store, storage, bandwidth.
  6. Add operations labor and a buffer of at least 20 percent, then correct against the first real monthly bill.
# Estimation framework: leave unit prices blank, fill them from the pricing page and bills
runs_per_month = 30_000
input_tokens_per_run = 3_000
output_tokens_per_run = 500
embed_tokens_per_index = 20_000_000
reindex_times_per_month = 1

input_price_per_1k = 0.0   # fill in price per 1K input tokens
output_price_per_1k = 0.0  # fill in price per 1K output tokens
embed_price_per_1k = 0.0   # fill in price per 1K embedding tokens

model_cost = (
    runs_per_month * input_tokens_per_run / 1000 * input_price_per_1k
    + runs_per_month * output_tokens_per_run / 1000 * output_price_per_1k
)
embed_cost = embed_tokens_per_index * reindex_times_per_month / 1000 * embed_price_per_1k
print(model_cost + embed_cost)

This framework covers only models and embeddings; add infrastructure and labor separately. Do not copy unit prices from marketing pages; take them from the in-site model pricing page and your cloud bill.

FAQ

Does Dify itself charge for model calls?

Dify is an orchestration platform; model calls are billed by the provider. Cloud may include built-in credits, after which you use your own key; self-hosting uses your own model account. Refer to the billing page.

Is self-hosted Dify completely free?

The community edition has no subscription fee, but you bear servers, database, vector store, bandwidth, backups, and operations. Counting labor, it is not necessarily cheaper than Cloud at small scale.

Can the Dify Cloud subscription offset model API costs?

Usually not directly. The subscription covers platform features and quota, model fees settle through the provider account, and built-in credits are limited in scope. Confirm both bills separately before purchasing.

Why is knowledge-base storage much larger than the original files?

Because it is billed by vector count, not file size. Smaller chunks, more parent-child segments, and higher embedding dimensions all increase usage. Economical indexing does not consume storage but retrieves differently.

With a limited budget, what should I cut first?

Cut ineffective context and duplicate calls first: compress prompts, limit retrieved chunks, cap output, and add deduplication and caching. Then consider smaller models or a different tier. Dropping model quality directly hurts the user experience most.

Next steps

Once the four bill layers are clear, the choice becomes simple: estimate monthly tokens from real logs, then compare the total of Cloud subscription, self-hosting operations, and gateway pay-as-you-go billing. If you want a unified entry point and usage-based billing, you can register for the ZSQH AI Gateway; the model range and prices are listed at model pricing.

Related reading: