Use case
The best API for semantic search and embeddings
Semantic search runs on an embedding model, not a chat model — there is no output side to price, only the text you turn into vectors — and Qwen3-Embedding-8B is the strongest open-weight retrieval model available here, with Matryoshka truncation so you can take a narrower vector and cut your storage and search cost without re-embedding.
This is a different model class, and the pricing shape follows: an embedding model is billed on input only. Both sides of the workload — indexing the corpus once and embedding each incoming query — are input tokens, and a query is a handful of tokens against documents that are hundreds, so the corpus dominates and traffic barely moves the number.
The consequence is that the token bill is usually not where this workload gets expensive. Vector storage and the search itself scale with dimensions and corpus size, and both are decided at index time. Choosing a narrower vector is the lever that matters; choosing a marginally cheaper embedding rate is not.
What actually matters here
- Vector width
- Dimensions set the recurring storage and search bill for as long as the index exists, and past a point they stop improving recall. Truncating at index time is the cheapest decision available and the hardest one to reverse later.
- Embedding context length
- It caps how much of a document goes into one vector. A short window forces finer chunking, which multiplies the vector count — the thing that actually costs money — rather than the token count.
- Multilingual coverage
- Search fails asymmetrically across languages. A model that embeds a query and its translation far apart makes non-English search quietly useless, and no amount of tuning downstream fixes it.
- Stability of the model version
- Vectors from two versions of a model are not comparable. Re-embedding a whole corpus is the real switching cost of this workload, which is why the rate matters less than committing to something you will not need to leave.
What it costs, at a 5M-chunk corpus re-indexed monthly, plus 2M searches
Worked from this catalogue’s published rates at 3,040M input and 0M output tokens a month. Your figure will differ; the arithmetic will not.
| Model | Input | Output | Per month | At official rates |
|---|---|---|---|---|
| Qwen3 Embedding 8B40% | $0.030/M | — | $91.20 | $152.00 |
Excludes cached-input savings, which on a repeated-prefix workload typically reduce the input column substantially. Cached rates are published per model on the pricing page.
Questions
- Why is only one model listed here?
- Because embeddings are a separate model class. A chat model cannot return a vector, so comparing this workload against generation models is comparing two different products. The models on the RAG page are the ones that read the retrieved chunks afterwards, which is a different page for a reason.
- Why is there no output column?
- An embedding model has no output side to bill. It returns a fixed-width vector, which is the same size regardless of what you sent, so the entire cost is the text you embedded. That is why the monthly figure here moves with corpus size and hardly at all with query traffic.
- Should I use 4096 dimensions or fewer?
- Start narrower than the native width and measure recall on your own queries. Qwen3-Embedding-8B is trained for Matryoshka truncation, so a shorter prefix of the vector remains usable — and since storage and search scale with width, the narrower vector is cheaper every day the index exists, while the embedding call costs the same either way.
- Do I have to re-embed the whole corpus each month?
- No — the volume above is deliberately pessimistic. Most corpora only need new and changed documents embedded, so the recurring bill is far smaller than the initial index. The figure is priced as a full re-index because that is the worst case, and a worst case you can afford needs no further modelling.