Embeddings API: text vectors for semantic search, RAG, and hybrid retrieval

An embeddings API takes text in and returns vectors out: one fixed-length list of numbers per input, positioned so that texts close in meaning end up near one another. From that one trick comes semantic search, the retrieval stage of RAG, hybrid retrieval, clustering, and deduplication. This page maps the route as this platform serves it: what the jobs are, how the route meters, which model answers it today, and when a reranker belongs behind it.

One model fills this category at present, bge-m3 from BAAI, and the page says so plainly instead of padding a catalog. Two things are missing on purpose. Prices are missing: the platform registry feeds both the metering and the rate table rendered on the pricing page, so a number typed here could only drift. Per-model spec tables are missing too: the bge-m3 model page owns every spec, its measured lane numbers, and its copy-ready code examples. What follows is the map.

Last verified: 2026-09-11

What an embeddings API is

OpenAI's embeddings guide gives the definition the industry works from: an embedding is a list of floating point numbers standing for a piece of text, and the distance between two of these lists measures how related the texts are. Everything else in the category is logistics around that definition. The model has already done the reading; your database does arithmetic.

The mechanics are small. One POST carries a model id and your input texts. Back comes a data array with one vector per input, in input order, plus a usage record saying what the call consumed. Most vendors and local runtimes settled on one request and response shape: the OpenAI embeddings shape. That is the portability fact for buyers: code written for one host transfers to another once the base URL and then the model id are changed. The route on this platform speaks that shape.

The route itself is only half the product. Vectors become searchable in a vector store, or a vector extension on a database you already run, and storage is arithmetic you can plan before spending anything: a float32 vector around a thousand dimensions costs roughly 4 KB raw, so a million texts run to about 4 GB before index overhead. Dimension and window length are per-model numbers, which is why they live on model pages, but the planning habit belongs to the category.

The jobs embeddings do

Job	What you build	Why vectors
Semantic search	Embed the corpus once, embed each query, return the nearest stored vectors	Matches meaning even when query and document share no words
RAG retrieval	The same index, feeding a language model's context	Retrieval quality sets the ceiling on answer quality
Hybrid retrieval	Dense vectors scored together with keyword signals	Catches exact strings that meaning-matching blurs
Clustering and dedup	Group or drop texts by vector distance	Cheaper than reading, and it works across languages

Semantic search is the headline job. Keyword search fails on vocabulary mismatch: a user asks about canceling a plan and the help page is titled "Ending your subscription". Vectors close that gap because the model learned which ideas sit near which. When the corpus is multilingual, the effect is larger still: a query in one language can retrieve documents written in another, and bge-m3's training covers more than 100 working languages, per its model card.

RAG retrieval is the same index doing harder work. A language model answers from the passages retrieval hands it, so retrieval ordering bounds the answer. Teams reach for the embedding stage first when generated answers cite the wrong chunk of the right document: the material exists in the corpus, and retrieval ordering is what buries it. One pipeline note for document corpora: parsing the documents into clean text comes before embedding them, and the guide PDF to markdown for RAG pipelines, part of the guides block on this page, handles that step in depth.

Hybrid retrieval exists because dense vectors have a blind spot. Product codes, error numbers, rare names, and internal identifiers matter exactly when they match exactly, and a single vector compressing a whole text blurs them. Hybrid search scores a dense signal and a sparse keyword signal together. The BGE documentation describes how bge-m3 produces both from one forward pass: the dense vector for meaning, and a learned weight per token for keyword-style matching. Milvus, a vector database that ships hybrid support, publishes the same reasoning from the storage side. One honest note for buyers: an embeddings route on the OpenAI response shape returns the dense vector; the sparse output of this model is consumed through its local library or a hybrid-capable store, and the model page draws that line exactly.

Clustering, dedup, and classification are the quiet jobs. Near-duplicate support tickets group by distance; a crawl's repeated pages drop out below a threshold; an incoming text classifies by its nearest labeled neighbors. None of these need a store with ANN indexes, just the vectors and something to compare them. A batch call sends many inputs at once, and metering adds their tokens together.

The model that answers this route

This category currently holds a single model: bge-m3, built by BAAI and released under an MIT license. Its profile: a mid-size encoder trained for more than 100 working languages and 8,192-token inputs, producing dense, sparse, and multi-vector outputs from one pass. BAAI's documentation adds the honest caveat: training data reached over 170 languages, and coverage is unbalanced across them.

It is also not a fading pick. The same day this page was verified, the Hugging Face repository counted about 37.8 million downloads and Ollama's library listing about 6.5 million pulls. That is the usage signature of a default, not a legacy model. Newer open families score higher on today's benchmarks: Qwen3-Embedding runs from 0.6B to 8B parameters with 32k input windows, and its 8B member took first place on the MTEB multilingual leaderboard when it released in June 2025. The split for a buyer is plain. Chase the highest benchmark score and the newer families win. Want one small open model covering languages, long inputs, and hybrid output types in one pass, and this category's pick is the standard answer. The bge-m3 model page holds the whole working contract: the request fields, the response shape, lane measurements from this platform, and code tabs in three clients.

When reranking enters the pipeline

The model card's own recommendation for RAG pipelines is two stages: hybrid retrieval first, then reranking. The logic is a division of labor. An embedding model scores a query against documents it never saw together with that query. That design is cheap enough to sweep the entire corpus and too coarse to finalize an ordering. A cross-encoder reads the query and one candidate in a single pass and returns a judgment on that pairing: sharper, at the cost of one scoring pass per pair.

So the working shape is retrieve wide, then judge the shortlist: embeddings pull the top slice from the corpus, the reranker rescores that slice, and the top few head to the prompt or the search results. This platform serves both halves of that pattern. The two family models were built for each other: when retrieval runs on bge-m3, the designed companion on the second stage is bge-reranker-v2-m3, served on the rerank route. When retrieval surfaces the right documents in the wrong order, the rerank stage is the fix, not a bigger embedding model.

How billing works on this route

Metering counts tokens, taken from the usage record inside the response itself, and nothing else. Twelve texts in one request bill as one total, the sum of their tokens. And nothing is billed when the gateway turns a request away before the model runs: empty input, unknown parameter, zero charge.

The ceiling on spend is the wallet itself. Every request draws down a prepaid balance, and a request that arrives after the balance is gone is refused with a named error rather than running into debt; a request already running when the balance hits zero may still complete and leave a small negative balance before the stop takes effect, bounding any overshoot at seconds of usage. There are no monthly fees and no trial credits to expire. Each API key can be switched off on its own, immediately, so one leaked key is contained without touching the wallet's other keys. Caps that bound a single key's spending are planned for a later sprint and are not on today's surface. The limit that exists now is the loaded balance. The rate for this route is on the pricing page, which builds its table from the same registry row the metering uses. In the guides block, How to avoid API bill shock walks the habits that keep metered spend predictable.

Open weights, and the local road

An MIT license means the weights behind this route are yours to keep, download, and run, whatever you decide about hosting. The official local routes: BAAI's FlagEmbedding library, which exposes all three output types through its BGEM3FlagModel class, and Ollama's bge-m3 listing, one command away for dense vectors on a local endpoint.

The local road is right when machines are already provisioned and traffic is steady, when tuning on pair data you labeled in-house is the goal, or when the corpus is not allowed to cross a boundary you hold. Hosting wins when the work you would otherwise own is the work you do not want: a live endpoint, a billing record that matches each charge, and a balance that stops spend by being finite. The route speaks the OpenAI-compatible shape either way, and the guide The OpenAI-compatible API guide, linked in the guides block, walks the base-URL swap for code you already have.

One rule travels with the decision: vectors from different models, and even from different serving runtimes, never mix in one index. Re-embed the corpus when anything on the encoding side changes.

Where serving stands today

The embeddings lane on this platform is wired and verified: a real request completed the whole round trip, verified 2026-09-09, with the metering row asserted against the billing ledger. The serving card behind the lane remains stopped ahead of the fleet-start wave; the platform is gated by invite codes while the beta runs, so this page describes capability, not traffic. The models index tracks catalog state as it changes, and the model page states this route's working contract.

Getting started

Open your console account. Signup takes an email and one invite code while the closed beta runs; the wallet and every API key live there.
Issue a key per project. A key is its own off switch, and one key per project contains a leak to that key alone.
Look up the rate. This route's per-token rate is published on the pricing page, and the prepaid balance you load is the working budget.
Make the first call. Open a code tab on the bge-m3 model page, put your key in, and embed two sentences. When the vectors come back with a usage record attached, one round trip has proven all three at once: your key, the route, and the ledger.

Beyond this route, the models index covers the whole platform: chat, speech, parsing, and rerank, all drawing on the same wallet.

The catalog table

Specialty models — kind and unit price
Model	Kind	Price
bge-m3	embeddings	$0.05 / 1M tokens

Token prices per 1M unless the unit says otherwise; a dash means the value isn't set yet — confirmed when the model goes live. Everything here is served by the same API that bills you: GET /v1/models. The full list with model details lives on the model index.

Guides

Questions

What is an embeddings API?

An HTTP service that turns text into vectors. You send a model id and your texts; the service returns one list of numbers per text, called an embedding, plus a usage record. Texts with similar meanings get vectors that point in similar directions, so comparing numbers replaces scanning words. A search works by embedding the corpus once ahead of time, embedding each query as it arrives, and returning the stored vectors nearest the query vector. The same vectors feed recommendation, clustering, and classification jobs.

Is there a free embeddings API?

Free exists in two different senses, and the difference decides what you can build. Free tiers at some hosts hand out a rate-limited slice of their models, and those limits shape the product. Free in the licensing sense is broader here: the model behind this route, bge-m3, ships under MIT, so the weights are free to download and local encoding costs nothing beyond the machine that does it. The hosted route here is neither of those. It meters every request by token against a wallet funded in advance, and current unit rates are published on the pricing page.

Can I use an LLM as an embedding model?

Not by default, and the distinction matters. Chat models generate text; embedding models score it. Research projects do convert decoder models into encoders, LLM2Vec being the named example, and some teams read a model's last hidden layer as a vector. Both paths trade standard behavior for custom plumbing, and the vectors they produce are meaningful only inside that same setup. Dedicated encoder models are what embeddings routes serve, what vector stores expect, and what benchmark tables compare.

Do vector embeddings replace keyword search?

No, and the strongest retrieval systems run both signals. Dense vectors catch meaning: a question about pricing finds a page about costs that never uses the word pricing. Keyword matching catches exact strings that dense vectors routinely blur: product codes, error numbers, rare surnames, internal identifiers. Hybrid retrieval scores both signals together. The model behind this route was trained to emit a dense vector and a learned keyword weight in the same forward pass, which is one cheap road into hybrid; a full build also works with plain BM25 running beside any dense model.

How is an embeddings request billed?

By the token, counted from the usage record inside the response itself, never by the request. One request holding twelve texts bills the tokens of all twelve, added together. A request rejected at the gateway before the model runs bills nothing. Each call is paid from a prepaid balance: a request that arrives after the balance is gone is refused with a named error, and current rates appear on the pricing page, rendered from the same registry the metering reads.

Which model answers the embeddings route, and is it serving traffic now?

bge-m3, the multilingual embedding model from BAAI, is the single model behind this route today. Its lane passed platform verification end to end, with a real request completing the whole round trip, verified 2026-09-09. The serving card behind it stays stopped until the fleet-start wave, so the route is not taking live traffic at this moment. The model page states the working contract, and the models index shows catalog state as it stands.

Can I mix embeddings from different models or hosts in one index?

No. Each model maps text into its own vector space, and distances only mean something inside one space. Two models can return identical dimension counts and still place similar texts far apart, so a mixed index quietly returns noise instead of matches. Pick one model per index, and when you switch models, or even serving runtimes, encode the whole corpus again rather than merging across the boundary.