At first glance, an Embedding API charges only for input tokens, with no output. After a RAG project has run for a few months, though, budget overruns usually come not from "too many queries" but from the total volume of chunked documents, full re-embedding after a model change, and the combined storage and request fees of the vector store.

This article breaks down those cost items and gives an estimation order plus a priority list for reducing spend. Unit prices change, so refer to model pricing and vendor documentation. This article does not hard-code any numbers.

Note: OpenAI, DeepSeek, and other names are trademarks of their respective owners. This article uses common interface patterns as of October 2026 as examples. Model names, billing rules, and prices may change; verify official pages again before purchasing.

1. You are billed for input tokens, not "number of calls"

Most Embedding endpoints charge only for input and produce no output-token fee. Input is the text you want vectorized, including titles, body text, table text after conversion, and also HTML tags, navigation bars, and excess whitespace.

Four factors amplify the estimate:

  • Tokenizer differences: one Chinese character is not necessarily one token, and tokenization varies by model. Do not estimate by character count. Run a small sample first and read the usage field in the response.
  • Chunk overlap: to preserve context, chunks often use 10%–20% overlap, and that text is billed repeatedly. The higher the overlap, the more expensive the initial indexing.
  • Dirty text: headers, footers, template copy, and repeated tables of contents are billed at normal token rates if not cleaned, without adding retrieval value.
  • Repeated indexing: embedding the same document set separately in test, staging, and production multiplies cost by the number of environments.
Cost item When it occurs Billed by Easy to miss
Input tokens Document and query vectorization Embedding provider Chunk overlap, headers and footers, duplicate indexing
Batch jobs Offline full and incremental indexing Provider batch endpoint Whether batch discounts actually apply
Re-embedding Model, dimension, or chunking changes Embedding provider Full rebuild and double storage during cutover
Vector storage Vectors and indexes on disk Vector database or cloud platform Replicas, backups, index growth
Retrieval and egress Reading vectors on each query Database or cloud platform Cross-region access, peak QPS
Generation calls Passing retrieved context to an LLM LLM provider Often mistakenly counted as Embedding cost

The last row deserves emphasis: cheap embeddings do not mean a cheap RAG system. Retrieved passages are sent to a chat model to generate answers, and input tokens there are often far more expensive than vectorization. Budget the two stages separately.

2. Batch endpoints: lower unit price for more time

Most platforms bill batch endpoints below real-time prices. The trade-off is queued jobs, turnaround measured in hours, and possible restrictions on available models and request size. Batch suits initial indexing, nightly incremental sync, and offline evaluation; it does not suit real-time vectorization of user questions.

Check three things before use:

  1. Whether batch jobs have a separate quota or compete with real-time requests.
  2. Whether failed or partially successful requests are billed, and who bears the retry cost.
  3. Whether the gateway passes through upstream batch discounts. Not every gateway does. Ask before purchasing, or verify with the first invoice.

Batch does not mean unlimited concurrency. Submitting millions of items at once can trigger rate limits or job failure. Split by scale, record tokens and latency per batch, and retry failed batches individually instead of rerunning everything.

3. Re-embedding: the most underestimated one-time cost

The following changes usually require a full re-embedding:

  • Replacing the embedding model, or a model upgrade that changes the vector space.
  • Changing vector dimensions, since old vectors cannot be mixed with new ones.
  • Changing chunking, cleaning, or document parsing rules.
  • Adding a language the original model handles poorly.

The cost of re-embedding is not just the API call fee. It also includes rerun time, storage for old and new indexes in parallel, and retrieval quality fluctuations during cutover. For a large knowledge base, this can exceed all previous query costs combined.

Ways to reduce risk:

  • Keep the original text as the source of truth. Vectors are derived data that can be rebuilt at any time.
  • Record model name, version, dimension, and chunking parameters in index metadata.
  • After building the new index, compare it on a fixed question set before shifting traffic.
  • Embed only new and modified documents day to day, and treat full re-embedding as a planned migration.

4. Vector storage and egress: the second bill

Vector store billing usually depends on five things: storage capacity, memory specification, replica count, request volume, and egress traffic. To estimate capacity from vector count, start with raw size: at 1536 dimensions and float32, each vector is about 6 KB; one million vectors is about 6 GB. Add indexes, metadata, and replicas, and actual usage can be several times that.

A few commonly overlooked points:

  • Dimensions: higher dimensions make storage and retrieval computation more expensive. Some models support reduced-dimension output. Whether it is available and how much it affects recall should be validated on your own evaluation set.
  • Replicas and backups: high-availability replicas multiply storage, and backup policies also appear on the bill.
  • Request volume: retrieval counts grow faster than document counts. Choose instance size by QPS, not by data volume.
  • Egress: applications and databases deployed in different regions, queries returning many candidates, and syncing vectors to multiple environments all generate traffic fees. Keeping the application in the same region and limiting candidates per response can save a hard-to-notice amount.

For small-scale scenarios, PostgreSQL with pgvector is often sufficient. Once data volume and concurrency grow, evaluate whether a managed vector database justifies its premium.

5. The order for estimating monthly cost accurately

  1. Count source documents, average length, and chunking parameters, then calculate total input tokens after chunking, not raw character counts.
  2. Use real query logs from the last week to count daily queries and average query length.
  3. Clarify the re-embedding plan for the next three months: model changes, chunking changes, language expansion.
  4. Ask the vector store vendor how each billing item works: storage, replicas, backups, requests, and egress.
  5. Calculate "first month of indexing" and "steady-state month" separately. Do not mix the two budgets.
  6. Leave a margin in the estimate and calibrate the coefficients against the first week's real invoice.

A reusable estimation framework follows. The placeholder numbers are for demonstration only; fill in unit prices from model pricing and your vector store bill.

# Estimation framework: numbers are placeholders, not any vendor's real prices
docs_tokens = 40_000_000       # Input tokens after chunking the full document set
query_tokens = 2_000_000       # Monthly query vectorization tokens
reindex_per_month = 1          # Full re-embeddings per month
vector_gb = 12                 # Vectors, indexes, and replicas combined

embed_price_per_1k = 0.0       # Fill in the per-1K-token price from the pricing page
storage_price_per_gb = 0.0     # Fill in the per-GB vector store price

monthly_embed = (docs_tokens * reindex_per_month + query_tokens) / 1000 * embed_price_per_1k
monthly_storage = vector_gb * storage_price_per_gb
print(monthly_embed + monthly_storage)

6. Do not reverse the order of cost reduction

Clean up the input before considering a cheaper model. The order is roughly:

  1. Cleaning: remove navigation, headers, footers, and repeated templates; extract the main content before chunking.
  2. Chunking: split at semantic boundaries. Use only as much overlap as needed; do not treat overlap as insurance.
  3. Hot and cold separation: archived content does not all need to live in the vector store. Embed on demand when needed.
  4. Query caching: reuse vectors for frequent identical questions to reduce repeated calls.
  5. Batching: use batch endpoints for offline indexing and real-time endpoints for live queries.
  6. Storage optimization: choose dimensions sensibly, evaluate quantization, and size replicas by query volume.
  7. Model routing: evaluate embedding and generation models separately. Do not sacrifice retrieval quality just to save on vector costs.

If the order is reversed, the usual outcome is switching to a slightly cheaper embedding model while chunk overlap stays high, dirty text stays in, and re-embedding stays frequent. The bill barely moves, and recall gets worse.

FAQ

Why is there no output-token fee for Embedding APIs?

Embedding outputs fixed-length vectors rather than generated text, so billing is usually input-only. A few platforms may charge separately for capabilities such as storage; follow official documentation.

Are batch endpoints always cheaper than real-time endpoints?

The unit price is usually lower, but consider turnaround time, failure retries, and whether the gateway passes the discount through. They are not suitable for queries that need an immediate response; the lower unit price is offset by waiting time.

After changing the embedding model, can I re-embed only part of the documents?

Vector spaces of old and new models are usually incompatible, and mixing them corrupts retrieval. The safer approach is a full rebuild: build a shadow index, validate it, then switch. Re-embedding only part of the documents is generally not viable.

Why can vector storage cost more than Embedding calls?

Storage is billed continuously by capacity, replicas, requests, and egress, while embedding is a one-time cost when documents do not change. With large data volumes, many replicas, and frequent queries, the second bill can easily exceed the first.

The estimate does not match the actual invoice. What should I check first?

Check token amplification from chunk overlap and dirty text first, then repeated indexing in test environments, failed retries, and whether batch discounts apply. Finally, verify vector store replica and egress charges.

Next steps

If you need a unified endpoint, pay-as-you-go billing, and access to multiple models, register for the ZSQH AI Gateway, run one indexing and query cycle on a small budget, and then estimate from real usage. Models and prices are listed on model pricing.

Related reading: