How is the embedding cost calculated?

The planner estimates tokens as characters divided by about four (a common English heuristic), multiplies by your document count to get total tokens, then multiplies by the model's per-million-token price. Embeddings are priced on input tokens only, so there is no output cost to add — the total is simply total tokens times the rate.

What is the optimal batch size and why does it matter?

Most embedding APIs accept many inputs in a single request, up to a model-specific cap (often 2048). Batching slashes the number of HTTP round-trips and helps you stay under your requests-per-minute limit. The planner picks the largest batch that fits under both the model's input cap and the per-request token budget implied by your TPM/RPM ratio.

Why does the estimated time depend on a bottleneck?

Throughput is limited by whichever ceiling you hit first — requests per minute or tokens per minute. With small documents you usually run out of requests; with large documents you run out of tokens. The planner computes the time implied by each limit and reports the larger one, labelling which limit binds so you know what to ask your provider to raise.

How accurate is the token estimate?

The four-characters-per-token rule is a rough average for English; code, other languages, and unusual formatting can differ substantially. For a precise figure, run a sample through the model's real tokenizer. Treat the planner's output as a solid budgeting estimate, not an invoice.

Does the tool account for batch-API discounts?

No — it prices at the standard synchronous rate. Many providers offer roughly a 50% discount on asynchronous batch endpoints. If you can tolerate the higher latency of a batch job, halve the displayed cost as a starting estimate and confirm against current pricing.

Embedding Batch Cost Planner

Before you embed a large corpus you want two numbers up front: how much will it cost, and how long will it take under your rate limits. This planner gives you both, plus the batch size that gets you there fastest — all computed locally in your browser.

How it works

Token volume is estimated as characters ÷ ~4 (a standard English heuristic) times your document count. Cost is that token total times the selected model’s per-million-token price — embeddings bill on input tokens only, so there’s no output cost to add.

For scheduling, the tool finds the optimal batch size: the most inputs it can pack into one request without exceeding the model’s input cap (commonly 2048) or the per-request token budget implied by your tokens-per-minute ÷ requests-per-minute ratio. From there it derives the number of requests and the run time, computing the time under both your RPM and TPM ceilings and reporting whichever is larger. The binding bottleneck is labelled so you know exactly which limit to ask your provider to raise.

Reading the bottleneck

Request (RPM) bound — you have lots of small documents and run out of requests before tokens. Bigger batches help most here.
Token (TPM) bound — your documents are large and you saturate the token budget. Only a higher TPM tier (or fewer/shorter chunks) speeds things up.

Tips

Chunk size is a lever on both axes: smaller chunks cost fewer tokens each but produce more documents, shifting you toward the RPM bottleneck.
If you can tolerate latency, use the provider’s asynchronous batch endpoint for roughly half the cost.
Re-run with your real tokenizer count once for a representative document to calibrate the estimate.