OpenAI Embeddings Rate Limits 2026: Tiers, Batch API, and Matryoshka Dimensions

OpenAI enforces three independent rate limit dimensions for embedding API calls. RPM (requests per minute) limits how many API calls you can make regardless of their size. TPM (tokens per minute) limits the total token volume across all requests in a rolling one-minute window. TPD (tokens per day) limits total token consumption in a 24-hour period. When you hit any one of these limits, the API returns a 429 Too Many Requests error with a response header indicating which limit was exceeded and when it resets.

The binding constraint in practice depends on your batching strategy. The OpenAI embeddings API accepts batches of up to 2048 input strings in a single request. A developer sending one string per request with frequent calls will hit RPM before TPM — at 3,000 RPM with an average of 100 tokens per request, they max out at 300,000 tokens per minute, well below the 1,000,000 TPM ceiling. The same developer batching 200 strings per request (each ~100 tokens) would need only 15 requests per minute to generate 300,000 tokens per minute, using 0.5% of their RPM but 30% of their TPM. In general, maximizing batch size is the right strategy to avoid RPM limits — the embedding API is designed for batch inputs, and single-string requests are inefficient both in cost and quota utilization.

TPD is the most relevant constraint for teams doing large initial corpus indexing runs on Tier 1 accounts. At 3,000,000 tokens per day and an average document chunk size of 300 tokens, a Tier 1 account can index approximately 10,000 document chunks per day through the synchronous API. This is meaningful: a corpus of 100,000 chunks would take 10 days to index at Tier 1 without the Batch API. Teams that need to accelerate this either need to upgrade their tier (which requires spending to reach Tier 2 and above) or use the Batch API, which has a separate daily quota. The Batch API approach is almost always the right answer for initial indexing workloads, as discussed in the Batch API section below.

OpenAI's tier system is based on cumulative account spend rather than a subscription tier you select. New accounts with a verified payment method start at Tier 1 after their first $5 spend (or 7 days after the first payment, whichever comes first). Tier 2 requires $50 in total spend; Tier 3 requires $100; Tier 4 requires $250; Tier 5 requires $1,000. Tier promotion happens automatically without action required from the developer — the platform checks spend thresholds and upgrades limits accordingly. You can see your current tier and specific rate limits in the platform rate limits dashboard at platform.openai.com/settings/organization/limits.

The most significant limit jump for embedding workloads is the TPM increase from Tier 1 (1,000,000 TPM) to Tier 2 (10,000,000 TPM) — a 10x increase. This corresponds to a 10x increase in sustainable embedding throughput through the synchronous API. A team that genuinely needs to index millions of documents quickly and cannot use the Batch API for their use case should prioritize reaching Tier 2 (by spending $50 across any OpenAI API usage, not specifically embeddings) early in their development cycle. Note that because tier promotion is based on total account spend, teams using the API for other purposes (completions, chat, image generation) will advance through tiers faster than a team using only cheap embedding calls.

Tier 4 and Tier 5 represent the limits relevant for production applications with substantial real-time embedding demand — embedding queries as users submit them in a live application. At 10,000 RPM and 100-250M TPM, a Tier 5 account can sustain roughly 100 million embedding operations per day through the synchronous API (at average 250-token inputs). Very few applications outside large enterprise search or recommendation systems approach this scale. Teams operating at this volume should also be in contact with OpenAI's enterprise team to discuss custom rate limits, which are available beyond Tier 5 thresholds for qualifying accounts.

The Batch API is the most underutilized feature for teams doing bulk embedding workloads. Batch API calls are submitted as a JSONL file of individual API requests, processed asynchronously with a 24-hour completion SLA, and priced at 50% of the synchronous API rate. text-embedding-3-small at $0.02/1M tokens drops to $0.01/1M tokens through the Batch API. text-embedding-3-large at $0.13/1M tokens drops to $0.065/1M tokens. For initial corpus indexing runs that might process hundreds of millions of tokens, this 50% reduction represents meaningful savings.

More importantly for throughput-constrained teams, the Batch API operates on its own quota that is separate from the synchronous API quotas. This means that running a large Batch API indexing job does not consume any of your RPM or TPM budget for the synchronous embedding API. A production system can process real-time user query embeddings through the synchronous API at full Tier 1 limits while simultaneously running a Batch API job to index new documents without either workload affecting the other. The Batch API supports up to 50,000 input strings per file upload, and there is no documented limit on the number of batch jobs you can queue simultaneously.

The 24-hour SLA means the Batch API is not appropriate for interactive or real-time embedding needs. However, the actual completion time is typically faster than the SLA — many batch jobs complete within minutes to a few hours, depending on current system load and file size. For document indexing pipelines that run nightly or on a schedule, the 24-hour SLA is almost never a practical constraint. The workflow is: prepare a JSONL file of embedding requests (each JSON line contains the model, input text, and a custom ID for your tracking), submit via the /v1/batches endpoint, poll the batch status until complete, then download the results file. The OpenAI Batch API limits reference documents the specific file size limits and status polling behavior.

Matryoshka Representation Learning (MRL) is a training technique that produces embedding models where shorter vector prefixes retain meaningful semantic information. In practical terms, it means you can truncate a text-embedding-3-large vector from its full 3072 dimensions down to 256, 512, or 1024 dimensions and still retrieve semantically relevant results — at reduced quality compared to the full vector, but often at acceptable quality for the application. text-embedding-3-large supports truncated dimensions of 256, 512, 1024, and 3072. text-embedding-3-small supports 512 and 1536.

The cost impact of Matryoshka truncation operates on the storage side, not the API billing side. OpenAI charges for tokens processed (input text tokens), not for output vector dimensions. Whether you request a 256-dim or a 3072-dim output from text-embedding-3-large, the API cost is identical for the same input text. The savings come from storing smaller vectors in your vector database, which reduces RAM requirements in Qdrant, reduces storage costs in Pinecone serverless, and reduces memory pressure in self-hosted solutions. A 256-dim float32 vector occupies 1 KB instead of 12 KB for a full 3072-dim vector — a 12x reduction. At one million vectors, this translates from 12 GB to 1 GB of pure vector storage.

The recall quality trade-off from Matryoshka truncation is model and task dependent. OpenAI's benchmarks show that text-embedding-3-large at 256 dimensions still outperforms text-embedding-ada-002 at its full 1536 dimensions on the MTEB benchmark, which provides a useful baseline for teams evaluating truncation. However, MTEB benchmark performance does not always correlate to performance on your specific domain or task. The recommended evaluation approach is to take a representative sample of your actual queries, generate embeddings at both full and truncated dimensions, run nearest-neighbor searches in your vector database with both, and measure overlap in the top-k results. If the top-5 results overlap at 85% or more between full and truncated dimensions, the quality loss is likely acceptable for RAG applications. If overlap is lower, you need more dimensions — or the underlying embedding model may not be a good fit for your domain. The embedding model leaderboard tracks quality benchmarks across models and dimension settings.

text-embedding-ada-002 (ada-002) is OpenAI's previous-generation embedding model, released in late 2022 and widely used for early RAG systems. OpenAI has indicated that ada-002 is deprecated in favor of text-embedding-3-small and text-embedding-3-large, and while they have not announced a hard shutdown date as of June 2026, teams should assume that continued availability is not guaranteed and that the risk of unplanned deprecation increases over time. OpenAI has historically provided advance notice before model deprecations, but waiting for the announcement before beginning migration puts your system in a reactive posture.

The migration is not a simple model name swap. ada-002 produces 1536-dimensional vectors. text-embedding-3-small also produces 1536-dimensional vectors by default, but the vector representations are not compatible — you cannot query text-embedding-3-small embeddings against an index populated with ada-002 embeddings, as the semantic geometry is different. A full re-embedding of your corpus is required when migrating to either text-embedding-3-small or text-embedding-3-large. This means: new index creation in your vector database, re-processing every document through the new model, verifying result quality, and cutover. For teams with large corpora, the Batch API is the cost-efficient path for re-embedding — at $0.01/1M tokens through the Batch API for text-embedding-3-small, re-embedding 10 million tokens costs $0.10.

The quality case for migrating is strong independent of deprecation risk. text-embedding-3-small outperforms ada-002 on the MTEB benchmark while costing 5x less ($0.02/1M vs ada-002's $0.10/1M at the time ada-002 was current pricing). text-embedding-3-large provides the highest quality OpenAI embedding available at $0.13/1M. For most RAG applications, text-embedding-3-small at its default 1536 dimensions is the right choice: it is cheaper than ada-002, better quality, and supports Matryoshka truncation for storage optimization. Teams on ada-002 should plan migration in their next technical debt sprint. Waiting until a forced deprecation creates schedule pressure and risks production downtime. The chunking strategies for RAG guide covers how chunk size affects both embedding quality and token costs for the new models.

Translating rate limits into practical throughput requires knowing your average chunk size in tokens. A typical RAG chunk — a paragraph of text, a product description, a support ticket snippet — ranges from 100 to 500 tokens. Using 250 tokens as a representative middle value: at Tier 1 with 1,000,000 TPM, the maximum sustained throughput is 4,000 chunks per minute or approximately 240,000 chunks per hour. At 250 tokens per chunk, this corresponds to 250 million tokens per hour — but note that the 3,000,000 TPD limit would be hit in about 12 minutes of sustained maximum throughput. The TPD ceiling is therefore the primary constraint for bulk indexing at Tier 1 even more than the TPM limit.

At Tier 2 with 10,000,000 TPM and the much higher TPD ceiling, the same 250-token chunks can be embedded at up to 40,000 per minute or 2.4 million per hour. A 1-million-chunk corpus would take about 25 minutes of sustained maximum throughput. This assumes the Batch API is not used — with the Batch API, even Tier 1 accounts can process large corpora efficiently because the Batch API quota is separate. At Tier 5 with 250,000,000 TPM, the theoretical throughput is 1,000,000 chunks per minute (1 billion tokens per minute), but actual achieved throughput will be limited by your client's ability to batch and submit requests at that rate, not by OpenAI's API limits.

The practical recommendation for teams doing initial corpus indexing: use the Batch API regardless of your tier. Submit files of up to 50,000 embedding requests per batch, queue as many batch jobs as needed, and let the 24-hour SLA work in your favor. This uses a separate quota, costs 50% less, and allows your synchronous embedding budget to remain fully available for real-time user requests during the indexing process. Only fall back to synchronous indexing if your use case requires real-time confirmation that each document has been indexed before proceeding.

All rate limit figures in this document are sourced from platform.openai.com/docs/guides/rate-limits and openai.com/api/pricing, verified June 2026. OpenAI's rate limits are documented per model and tier, and the documentation is updated when limits change. The figures most likely to have changed since this writing are the exact RPM and TPM values for Tier 2 and above, as OpenAI has increased these limits several times in 2024 and 2025. Always verify your current limits in the platform dashboard rather than relying on documentation or third-party references.

The model pricing figures ($0.02/1M for text-embedding-3-small, $0.13/1M for text-embedding-3-large) were accurate as of June 2026. OpenAI has reduced embedding prices several times since the models launched, and further reductions are plausible. If the gap between text-embedding-3-small and text-embedding-3-large pricing has narrowed since this writing, the quality advantage of -3-large becomes more compelling relative to its cost.

The Matryoshka dimension benchmarks referenced in this document (text-embedding-3-large at 256 dimensions outperforming ada-002 at 1536 dimensions) are based on OpenAI's published MTEB results at launch. MTEB scores are available at huggingface.co/spaces/mteb/leaderboard and are updated as new models and evaluations are submitted. For the most current performance comparisons, consult the live leaderboard rather than memorized benchmark results. The Batch API file size limit of 50,000 inputs and the 24-hour SLA are documented at platform.openai.com/docs/api-reference/batch and have been stable since the Batch API launched, but verify these limits remain current before building production pipelines that depend on them.