Embedding API pricing, line by line: the units, the tiers, and the dimension bill

Every big embedding provider bills by the token, and every rate card looks comparable. It is not. Three things separate the bills. First, the unit each card counts. Second, the batch tier three providers hide in plain sight. Third, the dimension bill no rate card shows at all. This page re-read the providers' own pages on 28 October 2026. Each row prints as a dated relation, never a bare figure. One worked corpus gets priced twice, once for the API and once for storage. The young marketplace route class, which no ranking comparison prices, gets mapped too. This platform's embeddings route serves two rows: bge-m3 for text and wemm-embed for multimodal work. Both meter per token against a prepaid wallet.

Each fact below carries its owner and its date. The OpenAI rates come from its pricing page. The OpenAI dimension and unit facts come from its embeddings guide. The batch facts come from its Batch API guide. All three were read 28 October 2026. The Google rows come from the Gemini pricing page and its embeddings docs. The Cohere rows come from the Embed 5 post and its pricing explainer. The Voyage rows come from its pricing docs and its dimensions guide. Those were read the same day. Rows read from a model catalog instead of a vendor page are labeled database-reported. Where a rate could not be read on a public page, this page prints a dash and the attempts behind it. The pages ranking today paste price columns with no units, no dates, and no second bill. This page does those three jobs.

Last verified: 2026-10-28

What an embedding bill is made of

An embedding API turns text into vectors and charges you for the text, not the vectors. The charge is a rate multiplied by a token count. That much every provider agrees on. The disagreement starts at three questions. What does a token cost? Which tokens count? What happens after the response arrives?

The first bill is the API rate. Most providers quote it per million tokens. One quotes per thousand. None of the major ones charge per request. Three of the five providers surveyed here discount slow delivery. Two of them halve the rate. The third takes a third off. The wait is half a day to a day. So a rate card read without its batch tier is a rate card half read.

The second bill arrives after the response. Every vector you store takes memory and disk. The take scales with the vector's width and its precision. A model with wide vectors costs more to index than one with narrow vectors, at the same API rate. No embedding rate card prints this number. It lands on your vector database invoice, not the provider's.

The third cost is not a bill but a risk: the re-embed. Switch embedding models and every vector in your index is suddenly worthless. You re-embed the whole corpus at whatever the new rate is. You rebuild the index at whatever the new width is. A rate comparison that ignores re-embed cycles compares rent on two apartments. It leaves out the moving truck.

The unit table: how each provider counts

Each row below is the provider's own counting rule, read from its own surface on the date shown. This table makes the rate columns comparable. Read it before any rate.

Three rows deserve a second read. The Voyage row prints both display units side by side, the only provider that does. The per-thousand figure looks small next to per-million figures. It is not. The Azure row lists per thousand tokens only. Its cells do not line up against per-million quotes even when the rates load. The Google row bills per modality. Text, image, audio, and video inputs each carry their own rate on the same model. The audio and video rates are the expensive ones.

The rates, as relations

This page states every competitor rate as a direction against this platform's embeddings rate, each named and dated. It prints no provider's figure. A figure without its unit rule and its batch tier misleads twice. A dated relation carries the real information.

The relations below each anchor on the fenced bge-m3 rate above.

• OpenAI, per its pricing page read 28 October 2026: the small model's per-million rate sits below this platform's rate. The large model's sits above it. The legacy ada row sits above it too, between its two siblings. The three OpenAI rows bracket this platform's rate from both sides.
• OpenAI at batch, per its Batch API guide read the same day: batch runs at half the standard rate with a 24-hour turnaround. The small model drops further below this platform's rate. The large model at batch still sits above it.
• Google, per the Gemini pricing page read the same day: the Gemini Embedding 2 text rate sits above this platform's rate, and its batch table, at exactly half, still sits above it. The image input rate is above the text rate, and the audio and video input rates sit far above both. The text-only 001 model remains available per its docs, and its rate as listed on a third-party catalog, database-reported the same day, sits above this platform's rate.
• Cohere, per the Embed 5 post read the same day: both Embed 5 tiers price their text rate above this platform's rate, the Fast tier by a small margin and the Pro tier by more. Its pay-as-you-go card sits behind a consent wall that three read methods did not pass on 28 October 2026, so the card itself prints no rate here; the post's stated rates are the cited source.
• Voyage AI, per its pricing docs read the same day: the voyage-4-lite rate sits below this platform's rate. The voyage-4 rate sits just above it, and voyage-4-large above that. The multimodal rows price their token rate above this platform's multimodal row and add a per-pixel charge on top.
• DeepInfra, per its own model page read the same day: it serves the same open bge-m3 weights this platform serves, at a per-million rate below this platform's rate. Same model, lower rate, no bundle. That is the honest floor of the open-weights hosting band, and this page does not pretend it away.
• A third-party model marketplace, database-reported 28 October 2026: the same bge-m3 listed at a rate matching that discount band, and the open Qwen3 embedding rows listed below this platform's rate as well. Its OpenAI, Google, and Voyage rows carried the same list rates as each vendor's own pages on every row this page cross-checked.
• Mistral: dash. Its docs pricing page returns not found after a restructure, and both renderings of its main pricing page show chat tables only. No embed rate was read on a Mistral surface on 28 October 2026, so none appears.
• Azure OpenAI: dash. The embedding table renders with every rate cell empty outside a browser session, across three read methods. The unit rule above is real; the rate is not readable, so it is not printed.
• Jina AI: no relation applies. It sells one shared token pool across its APIs, and no per-token embedding rate appears on the surfaces read.

The pattern across the list: this platform's text row sits in the middle of the band. Above it sit the flagship closed models and their wide vectors. Below it sit the discount hosts serving the same open weights. The closed vendors' small tiers sit near the discount band's edge. Where a platform earns its rate, or fails to, is everything else on the bill. The unit rule matters. The batch tier matters. The second bill matters. The exit matters. Those follow.

The worked example: one corpus, two bills

Take a corpus of 50,000 pages. Use a planning convention of 800 tokens per page, the convention OpenAI's own guide uses for its pages-per-dollar table. The full index is 40 million tokens. Price both bills.

Bill one is the API, on named variables:

index cost  =  ( T / 1,000,000 ) x R

T:  tokens in the indexing pass, here 50,000 pages x 800 tokens = 40,000,000
R:  the per-million rate you chose, from the fence above for this platform,
    or from the provider's own card, at its standard or batch tier

One pass is never the whole story. Queries add tokens one at a time. That is a small share for most workloads. Model switches add whole passes. If you re-embed once a year, plan two passes a year at minimum:

yearly budget  =  passes x ( T / 1,000,000 ) x R  +  query tokens x R

passes:  1 for a stable index, 2 or more if the model or corpus churns

Batch cuts R by half at OpenAI and Google and by a third at Voyage, dated above, for work that can wait. A first index usually can. A query path never can.

Bill two is storage. It is pure math on width and precision, and no vendor invoice controls it:

raw vector bytes  =  vectors x dimensions x bytes per dimension

float32: 4 bytes per dimension
int8:    1 byte per dimension, a quarter of float32
binary:  1 bit per dimension, a thirty-second of float32

At 50,000 vectors, a 1,024-wide model at float32 stores about 200 MB raw. A 3,072-wide model stores about 600 MB. Quantize the wide one to int8 and it drops near 150 MB. This is why the dimension column in the unit table is a pricing column. No provider prices by dimension. Your index prices by width.

One sensitivity note: chunk overlap inflates T before any rate applies. Overlapping text is embedded twice. Tighten overlaps before you shop rates.

Dimensions: the bill the rate card does not show

Per-token pricing is dimension blind. A model that returns 3,072 numbers per text and a model that returns 1,024 bill the same tokens at the same rate. The difference lands entirely on your storage and memory, per the math above. So the real dimension question is never which model is cheaper per token. It is which width you can afford to index.

Shortening is the lever, and in 2026 it is a trained behavior, not a hack. OpenAI's models accept a request parameter that returns shorter vectors. Its guide's own table shows a large model shortened hard still beating the legacy model at full width. Google's two models are trained the same way. They default to 3,072 with recommended stops at 768, 1,536, and 3,072. Cohere's Embed 5 lists six widths from 2,048 down to 256 from one model. The open Qwen3 family does the same across its three sizes, per its card. The technique's name, Matryoshka representations, matters less than its effect. The first k numbers of the vector stay meaningful. You buy quality by width, on demand.

Quantization is the second lever. Voyage's guide states the math: int8 cuts storage to a quarter of float32, binary to a thirty-second. The quality cost is modest. Cohere's Embed 5 ships int8 and binary output formats directly. A wide model, quantized, can store for less than a narrow model in full precision.

Cohere added one more trick worth pricing. Its two Embed 5 tiers share one vector space. A team can index with the higher tier and embed queries with the cheaper tier against the same index. The index quality of one rate, the ongoing query cost of another. If your workload is query heavy, that split moves the monthly bill more than any headline rate comparison.

The exit cost is the last dimension fact. Widths are model specific. Switch models and the storage rebuild rides along with the re-embed. It lands at the new width, in the new precision. The embedding dimensions and context table in this section set carries the selection side of that decision.

Batch and realtime: two prices for the same tokens

Three providers in this comparison discount embedding work by delivery speed. None of them buries it in a footnote. Two halve. The third takes a third off on a shorter clock.

OpenAI's Batch API runs at half the standard rate with a 24-hour turnaround, per its guide read 28 October 2026. Google's Gemini Embedding 2 carries a standard table and a batch table on its pricing page. The batch table sits at exactly half, per the page read the same day. The third-party marketplace carries batch variants of the OpenAI rows as separate catalog entries at the same halving, database-reported.

Voyage is the third, and its shape is its own. The batch section of its pricing page, read 28 October 2026, offers a 12-hour completion window at a third off the standard rate. Its batch docs name the use outright: embedding large corpora for vector databases. The voyage-4 families sit on its batch availability list, and the feature carries a public preview label as of the read. A third off for half the wait is a different trade than half off for a day. Price it as its own shape, not as a weaker halving.

The decision rule is about your latency, not your volume. Initial indexing of a corpus is almost never latency critical. Batch it wherever batch exists, and the biggest bill of the year drops by a third to a half. Query-time embedding is latency critical by definition. A user is waiting, and no 12-hour queue fits that. The discounting providers charge a patience premium. For indexing workloads that premium is pure savings.

This platform's embeddings route has one tier. The rate the fence renders is the realtime rate. No batch discount applies. If your workload is one big indexing job a month with no query latency to protect, a batch lane elsewhere will cut that job's cost by a third to a half. This page says so plainly. If your workload is query serving, incremental indexing, or anything where an hour matters, the single tier costs you nothing.

Free exists in three different senses

The question "is there a free embedding API" has three honest answers. Picking the wrong one for your case is how prototypes die in production.

The first sense is a free tier with rate limits. Google's pricing page lists a free tier for Gemini Embedding 2, free of charge, read 28 October 2026. OpenAI's pricing table shows no free token grant for its embedding rows. What it maintains instead is request-rate limits that scale with usage tier. Rate-limited free tiers answer one question: does this work for my corpus. They are not a production plan.

The second sense is a one-time token grant. Voyage gives every account 200 million free tokens on the voyage-4 family. The multimodal rows add 200 million text tokens plus 150 billion pixels, per its pricing docs read the same day. A grant is real money, but it burns once. It burns at your corpus size. Index 40 million tokens twice, as in the worked example, and a grant covers exactly one rebuild.

The third sense is free weights. bge-m3 ships under MIT, per its model card. The Qwen3 embedding family ships open weights across three sizes. Free weights mean no per-token bill ever, on hardware you run, with no rate limit but your own. They do not mean free. The machine, the operator, and the idle hours are the bill. The embeddings local versus API guide works that trade to its crossover point.

Two more free doors exist on the shelf today, both dated. Cohere's trial keys run every model free with rate limits and a bar on commercial use, per its docs. On the third-party marketplace, several embedding rows list at zero outright, including two from a major chip vendor, database-reported 28 October 2026. Free rows on a marketplace are a pricing decision by their hosts. That can change. Free weights are a license. That cannot.

The young route class and where this lane sits

Something changed on this shelf recently, and no ranking comparison prices it. A third-party marketplace now serves a unified embeddings route. One endpoint, a catalog of embedding rows from many providers, per-token rates set per row, provider routing underneath. On 28 October 2026 its live list carried 42 embedding rows. That is a young class, and it moves. The same day, its own docs still recommended a small Qwen3 row that its live list no longer carried.

What the young class does to pricing is compression. On one page, the open-weights rows sit at deep discounts to the closed flagship rows. Several rows list at zero. The closed vendors' rows carry their own list rates. This page cross-checked those rates against the vendors' own pages wherever both could be read. The band from the bottom of that list to the top spans a factor of twenty for the same job: turn text into vectors. When a static comparison crowns one vendor's rate, the shelf underneath it has already moved.

Against that band, this platform's embeddings lane is young too. This page states its position plainly. As of 28 October 2026 the route serves two rows: bge-m3, a 1,024-dimension multilingual text model with an 8,192-token window, and wemm-embed, a 2,048-dimension multimodal model covering text, images, video, and visual documents. Both meter per token against one prepaid wallet. The per-token rate is not the floor of the market. The sections above say exactly where it sits. What the rate buys is the aggregate: two rows on one route, one bill, one request shape, the OpenAI-compatible call below. The exit stays open, because both models' weights are downloadable.

The lane's planning numbers come from the platform's 2026-08-28 bench window. Median response was 1.38 seconds at single flight, 1.90 at eight in flight, and 4.33 at thirty-two. Aggregate throughput scaled about ten times along the way. A real request completed the full round trip on 2026-09-09. Its usage row matched the billing ledger. Read them as planning inputs from those windows, not promises.

Make the first call

The route is OpenAI compatible. Sign up, create a key, and run:

curl -X POST "https://api.ironstratum.com/v1/embeddings" \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "bge-m3",
    "input": [
      "One page of the corpus, priced per token.",
      "A second page, stored as one thousand twenty four numbers."
    ],
    "encoding_format": "float"
  }'

The response carries the vectors and a usage block. The usage block is the metering record your bill will match. The wallet is prepaid. A refused request bills nothing. The balance itself is the spend ceiling. The bill shock guide covers that failure mode in depth. Keys can be revoked on their own without touching the wallet. The bge-m3 model page holds the full request contract. The embeddings lane page maps the route family. The models index is the live catalog. The pricing guide always carries the current rates, rendered from the same model data the metering reads.

What to check before you commit

Work the list in order and stop at the first red flag.

1. The display unit. Check whether each card you compare quotes per million or per thousand tokens. One provider prints both. Divide before you compare.
2. The batch tier at your patience. If your indexing can wait half a day, three providers discount it: two by half, one by a third. If it cannot, a batch table is noise.
3. The dimension bill at your width. Multiply vectors by dimensions by bytes and put the result next to the API cost. For large corpora the two numbers are the same order of magnitude, and only one of them appears on the vendor card.
4. The free tier in the sense you need. A rate-limited tier proves the pipeline. A one-time grant covers one index build. Free weights remove the per-token bill and add an operations bill. None of the three is the others.
5. The re-embed exit. Before you index a corpus into one model's vector space, price one full re-embed at that vendor's rate, and check whether the weights can leave. A rate that looks high with a cheap exit can be the cheap choice over three years.

Common questions

How much does the OpenAI embedding API cost?

Per its pricing page read 28 October 2026: the small model's per-million rate sits below this platform's embeddings rate. The large model's sits above it. The legacy ada row sits between its two siblings. The Batch API halves all three with a 24-hour turnaround. This page prints the directions. The figures live on OpenAI's own card, which owns them.

Is there a free embedding API?

Yes, in three different senses. Google lists a free tier for Gemini Embedding 2. Voyage grants 200 million tokens once per account. The open weights of bge-m3 and Qwen3-Embedding are free to run on hardware you control. Rate limits, one-time grants, and licenses are three different products. Pick by what your workload needs after the prototype.

Are embeddings billed per token or per dimension?

Per token, at every provider in this comparison, without exception. No major provider prices by output dimension. Dimensions bill you later, in vector database storage and memory. The cost is four bytes per dimension at float32, and less when quantized. A wider model is a storage decision, not a rate decision.

Is the batch discount worth it?

If the work can wait, yes, arithmetically. OpenAI and Google halve the rate for a 24-hour wait. Voyage takes a third off for a 12-hour window. All three dated 28 October 2026. First-time corpus indexing is the canonical fit. Query-time embedding is the canonical mismatch, because a user is waiting. This platform's route carries one realtime tier and no batch table.

How do I compare rates when the units differ?

Normalize to one shape before comparing anything. Compute cost per million tokens. Then cost per one thousand pages at 800 tokens per page. Then cost per full corpus pass, including one rebuild. Put the storage math next to it. A rate compared at a different unit or a different tier is not a comparison. That is the quiet defect in most static pricing tables.

How many tokens is a page of text?

Near 800 for a dense page of prose, the convention OpenAI's own guide uses for its cost table. At that convention, a 50,000 page corpus is 40 million tokens per full pass. Every rate on this page multiplies that count. Chunk overlap adds more. Budget for it before you budget the rate.

The short version

Embedding API pricing is three bills wearing one rate card. The API bill is per token everywhere. Batch discounts it where batch exists and your patience allows it. The storage bill scales with width and precision. Shortening and quantization cut it. It appears on no vendor card. The exit bill is a full re-embed, priced at whatever rate you move to. This page read every provider's own surface on 28 October 2026. It printed the unit rules, the rates as dated relations, and both worked bills. This platform's lane sits mid-band on rate. It aggregates two rows, bge-m3 and wemm-embed, on one prepaid route. The rerank side of the retrieval bill is priced in the reranker pricing guide. The model-level comparison against OpenAI's pair is the bge-m3 versus text-embedding-3 guide. When you are ready, sign up and price the lane on your real corpus, not on a headline.

Last verified: 2026-10-28