Hi,
I am encountering the error “Vector store size limit reached” while using multiple assistants, each with its own vector store.
Could you clarify why this error is occurring? After seeing this issue, I removed a few vector stores, and the system started working again. I would like to understand the specific limitations on vector store size and if there are any ways to manage or increase this limit.
Looking forward to your guidance.
There could be a couple of reasons - do you have additional details on the way you’ve set everything up? In general most of the issues come from not setting the index right:
Choosing an index is mainly a trade between these four factors:
- Query Speed: How fast you need the search results.
- Accuracy (Recall): The quality of the search results.
- Memory Usage: The amount of RAM you’re willing or able to use.
- Indexing Time: How long it takes to build the index.
Refer to Unlocking the Power of Efficient Vector Search in RAG Applications | by Chirag Agrawal | Towards AI for more details on this
Yes, I am using the Assistant API, and below are the steps I follow:
For each user, I create a unique assistant and a corresponding vector store.
After a long period of usage, I encountered the error “Vector store size limit reached.” I would like to understand:
Your guidance on this would be greatly appreciated.
Yes there are limits on the project, limits on per file size and limits on number of files which can be attached per assistant. The limits for storage is as follows:
File Size and Token Limits: Each file can be up to 512 MB with a maximum of 5 million tokens.
File Size Limits: The total size of all the files uploaded in your project cannot exceed 100 GB.
Total Number Of Files: You can attach a maximum of 20 files to code_interpreter and 10,000 files to file_search.
You can read more about this in this post: Technical Insights
Do you have more than 100GB of data?
The documentation says that those are “some” of the limits.
Exploring other possibilities or other documentation, we don’t really find anything that provides limit, such as controls within “projects” that may have been overlooked.
An OpenAI programmer with too much insight and time could look at your “monthly limit” setting in a project, and extrapolate out a maximum vector store size that would incur that cost in monthly billings. Don’t think that is how it works though.
Discover: Run a “get vector store” in see if particular ones reaching the size limit error report a similar byte size value.
Did you limit the amount of data returned after the vector search when you do the recall? I belive otherwise that could be the issue.
When creating a new Assistant, I got the error " Vector store size limit reached".
I am using the default limit and usages
That is interesting information.
Is the Actual assistant creation call alone what is returning the error? Are you including file IDs with the creation, and/or including an existing vector store ID?
Example of a single “create” call directly employing file IDs would be:
import openai
openai.api_key = "YOUR_API_KEY"
# 1. Upload a file to OpenAI (returns a file ID)
file_obj = openai.File.create(
file=open("company_report.pdf", "rb"),
purpose="assistants"
)
file_id = file_obj.id
# 2. Create an assistant and attach the file via a new vector store
assistant = openai.beta.assistants.create(
name="Financial Analyst Assistant",
model="gpt-4-turbo",
tools=[{"type": "file_search"}],
tool_resources={
"file_search": {
"vector_stores": [
{"file_ids": [file_id]}
]
}
}
)
print("Assistant created with ID:", assistant.id)
Or is it that you have a combination of calls that upload or use existing file ids, then making vector store endpoint calls, and a particular API call there is producing the error? Which?
Another thing to note: when creating a project API key, and limiting the scope, we see no mention of vector stores’ endpoint api.openai.com/v1/vector_stores
This means that the unmentioned (and responses even was only recently added) could default to block, and thus usage that goes at vector stores in a sideways manner could also fail. Use a new API key where you have left it at “all”.
To paste the Python “create with file id” not shown in API reference examples, I initially was going to just have an AI unwrap the parameters needing multiple expansions into documentation here. Then I decided I wanted a whole bunch more discovery - like if this “create assistants” permanently adds and even duplicates file IDs. So wrote a whole bunch more, input a whole bunch more specification, and sent it off to Deep Research for a big chunk of “missing documentation”.
This guide explains how file attachments are handled in the OpenAI Assistants API using vector stores, and answers common questions about automatic vector store creation, isolation vs. reuse of data, and best practices for using file attachments in the Python SDK.
file_idsWhen creating a new assistant, you have the option to attach files directly by providing their file_ids in the tool_resources. This uses the vector_stores parameter to create a vector store on-the-fly. Key points about this approach:
Automatic Vector Store Creation: If you call client.beta.assistants.create() and include tool_resources={"file_search": {"vector_stores": [{"file_ids": [...]}]}}, the API will automatically create a new vector store behind the scenes containing those files. You do not need to manually call vector_stores.create beforehand – the assistant creation will handle setting up the vector store for you.
Unique Vector Store per Assistant: The files you attach inline go into a new vector store unique to that assistant. In other words, each assistant created with its own file_ids gets its own isolated vector store (with its own ID) that the File Search tool will use. This store is not an existing “global” store; it’s created fresh for that assistant’s knowledge base. By default, no other assistant knows about or uses this store unless you choose to share it (more on reuse later).
Embedded and Ready to Search: Once attached, the files are automatically processed (parsed into chunks and embedded into vectors) as part of vector store creation. This enables the assistant’s file_search tool to retrieve relevant content from those files when you ask questions. Typically, you don’t have to do anything extra to trigger this processing – it begins when the assistant is created. However, for large files or many files, processing may take some time (the assistant might not find info until embedding is complete).
Example – Creating an Assistant with Inline Files:
import openai
openai.api_key = "YOUR_API_KEY"
# 1. Upload a file to OpenAI (returns a file ID)
file_obj = openai.File.create(
file=open("company_report.pdf", "rb"),
purpose="assistants"
)
file_id = file_obj.id
# 2. Create an assistant and attach the file via a new vector store
assistant = openai.beta.assistants.create(
name="Financial Analyst Assistant",
model="gpt-4-turbo",
tools=[{"type": "file_search"}],
tool_resources={
"file_search": {
"vector_stores": [
{"file_ids": [file_id]}
]
}
}
)
print("Assistant created with ID:", assistant.id)
In this example, the assistants.create call automatically creates a vector store containing the PDF file and attaches it to the new assistant. The assistant can immediately use the content from company_report.pdf via the File Search tool.
How to verify the attached store? After creation, the assistant’s configuration will include the ID of the vector store it’s using. For example, assistant.tool_resources["file_search"] would show a vector_store_ids list (usually with one newly created ID). This confirms a new store was made and tied to the assistant.
In contrast to the inline approach, you can attach files by referencing a pre-existing vector store. This is done via the vector_store_ids parameter in the assistant’s tool_resources. Instead of providing file IDs directly, you provide the ID of a vector store that you have created earlier (and already populated with files).
No New Store Created: When you use tool_resources={"file_search": {"vector_store_ids": [<STORE_ID>]}}, the assistant will use that existing vector store. No new vector store is created in this call – it simply links the assistant to the specified store. This means you must have set up the vector store (and added files to it) beforehand using the vector store API.
Read-Only Attachment: Attaching an existing store by ID will not modify or add to that vector store’s contents. The assistant gains read-access to whatever is already in the store. Any file_ids you want in that store must have been added earlier. The assistant creation call itself does not upload or index new files into an existing store. In other words, using vector_store_ids is a purely reference operation – it points the assistant to a prepared knowledge base. If you need to add more files to that store, you’ll do so with separate API calls (e.g. using the vector store file upload endpoints) rather than via the assistant.
One Vector Store per Assistant: Currently, an assistant can have at most one vector store attached at a time. If you pass a list with one vector_store_id, the assistant will use that store. (Multiple stores per assistant are not yet supported via the API – you would organize data into one store, or swap stores by updating the assistant.)
Example – Using a Pre-Created Vector Store:
import openai
openai.api_key = "YOUR_API_KEY"
# 1. Upload files (if not already uploaded)
file_obj1 = openai.File.create(file=open("policy.docx", "rb"), purpose="assistants")
file_obj2 = openai.File.create(file=open("handbook.txt", "rb"), purpose="assistants")
# 2. Create a vector store and add files to it
vector_store = openai.beta.vector_stores.create(
name="HR_Documents", # give the store a descriptive name
file_ids=[file_obj1.id, file_obj2.id]
)
vector_store_id = vector_store.id
# (Optional) Wait or poll until the vector store has finished processing the files.
# You can use client.beta.vector_stores.file_batches.upload_and_poll or similar helper if needed.
# 3. Create an assistant that uses the existing vector store
assistant = openai.beta.assistants.create(
name="HR Assistant",
model="gpt-4-turbo",
tools=[{"type": "file_search"}],
tool_resources={
"file_search": {
"vector_store_ids": [vector_store_id]
}
}
)
print("Assistant created with ID:", assistant.id)
Here we first set up a vector store called “HR_Documents” and upload two files into it. We then create an assistant and attach the HR_Documents store by its ID. The assistant will be able to search those two files. If later we upload another file into the same HR_Documents store, the HR Assistant (and any other assistant using that store) will automatically have access to the new content as well.
Understanding how data is stored and shared is important for using the Assistants API effectively:
Persistence of Files and Stores: Uploaded files and created vector stores are persistent objects in your OpenAI account. Attaching a file to an assistant (via a vector store) does not consume or delete the original file; it remains available for reuse. Similarly, the vector store created (whether inline or beforehand) will persist until you delete it. Even if you delete an assistant, the vector store it was using will likely remain in your account (as a separate resource) unless you remove it. This means you can potentially reuse that store for other assistants or threads.
Reusing Vector Stores Across Assistants: Vector stores are not tied to a single assistant. You can attach the same vector store ID to multiple assistants or conversation threads. All those assistants will then draw from the same pool of documents. This is useful if you have a common knowledge base (e.g. a product documentation store) that several different assistants should use. Any updates to that store (adding or removing files) will affect all assistants that reference it. Keep this in mind if you want a truly isolated knowledge base per assistant – in that case, create separate stores for each one.
Isolation of Inline-Created Stores: When you use the inline file attachment method (vector_stores with file_ids), you are essentially creating a new store for that assistant alone. By default no other assistant is using it, so it provides isolation. However, because that store is a normal resource, you could later attach it to another assistant if desired (by retrieving its ID). If you don’t plan to share it, you can treat it as exclusive to that assistant.
No Implicit Store Mutation via Assistants: Creating or updating an assistant with vector_store_ids will never implicitly add files to a store. All file additions are explicit operations via the file upload or vector store APIs. Assistants only consume the content. (One exception: if you attach files as messages in a thread, those get added to the thread’s vector store automatically. But for assistants, attachments are fixed in the config unless updated.)
Both approaches – creating a vector store inline with the assistant or using a pre-created store – achieve the same end result (your assistant can search the file contents). However, they are suited for different scenarios. Consider the following guidelines to decide which method to use:
Use Inline file_ids for Quick, Single-Use Knowledge Bases: If you have a few files and you want to spin up an assistant specialized on those files quickly, the inline method is very convenient. It’s essentially a one-step process (after uploading the files) – great for rapid prototyping or cases where that assistant’s data won’t be reused elsewhere. For example, if you are programmatically generating an assistant on the fly for a specific dataset and won’t need that dataset for other assistants, inline creation saves a bit of code. Just be mindful to allow time for the indexing to complete if the files are large. Typically, you might create the assistant and then immediately start a conversation; in most cases the system will handle the background work, but for very large documents consider adding a short delay or checking that the assistant’s vector store is ready.
Use Pre-Created Vector Stores for Reusability and Control: If you have a larger set of files or a knowledge base that might be referenced by multiple assistants or sessions, it’s better to create a vector store explicitly. This gives you more control: you can give the store a meaningful name, add metadata, and crucially, you can update it or reuse it without re-uploading files. For example, you might create a vector store for “Product Manuals” and attach it to a customer support assistant, a sales assistant, and so on. Maintaining this store separately means you only embed the files once, and all assistants share the consistent data. It also lets you monitor the ingestion process (using the file_batches helpers to ensure all files are processed) before the assistant uses it. In the Python SDK, you can easily poll the status of the upload to know when it’s done. This method is also advisable if you plan to gradually add more files over time – you can keep updating the vector store without recreating assistants.
Managing Updates and Changes: If an assistant’s knowledge needs to change, consider how you set it up:
client.beta.vector_stores.file_batches.create (or upload_and_poll) to add files to that store. The assistant will then have access to the new files since its attached store was updated. Alternatively, you could create a brand new store with the expanded file list and update the assistant to use the new store (though that’s usually unnecessary unless you want to keep the old version intact).Avoiding Duplicate Uploads: A practical advantage of using vector store IDs is avoiding duplicate data. If you have the same file relevant to multiple assistants, you should upload it once and put it in one vector store, rather than attaching it separately to each assistant (which would create multiple stores with duplicate content and extra embedding overhead). Using a shared vector store makes maintenance easier and reduces processing time and storage usage.
Lifecycle and Cleanup: Remember to clean up resources when they’re no longer needed. If you created an assistant with an inline store and later don’t need that knowledge base, you might delete the assistant and delete the vector store (since it remains in your account). Conversely, if you delete a vector store that an assistant is using, the assistant’s File Search tool will no longer have access to that content (you’d need to attach a different store or add files again). Plan your resource management accordingly – especially if you’re creating many assistants or vector stores in automation.
In summary, providing file_ids during assistant creation does automatically create a new vector store containing those files (no separate vector store API call is required in that moment). This new store is unique to the assistant by default, not a pre-existing shared store, though it behaves like any other vector store resource and can be reused elsewhere if needed. If instead you attach an existing vector_store_id to an assistant, the assistant will use that store’s data and will not add or change any files in it through the create call – it’s a read-only reference.
Choose the inline method for simplicity when the data is one-off for that assistant. Choose the separate vector store method for more complex scenarios: when you want to reuse data across assistants, handle large numbers of files, or maintain/update the knowledge base over time. In either case, the Python SDK provides convenient methods to upload files, create or attach vector stores, and manage the assistant’s tools. By understanding these two approaches, you can effectively manage file-based knowledge for your assistants while keeping data organized and avoiding unnecessary duplication.
const assistantConfig: AssistantCreateParams = {
name: `Ottavia Health App-${userId}`,
instructions: ASSISTANT_INSTRUCTIONS,
model: ASSISTANT_MODEL,
tools: [
{ type: 'file_search' },
{
type: "function",
function: {
"name": "get_nutrition_from_image",
"description": "Retrieve nutritional values or calorie content from a food image. Also before calling the function ask for detect the food item and ask for quantity consumed",
"strict": true,
"parameters": {
"type": "object",
"required": [
"food_item",
"quantity",
"biotin",
"caffeine",
],
"properties": {
"food_item": {
"type": "string",
"description": "The name of the food item."
},
"quantity": {
"type": "string",
"description": "Quantity of the food item consumed (e.g., 2 slices, 1 cup)."
},
"biotin": {
"type": "number",
"description": "Amount of Biotin in micrograms"
},
"caffeine": {
"type": "number",
"description": "Amount of Caffeine in milligrams"
},
},
"additionalProperties": false
}
}
}
],
};
// File upload to AssistantAPI
const file = await uploadToOpenAI(userUiContentPath);
fileIds.push(file.id);
const vectorStore = await openai.beta.vectorStores.create({
name: type,
file_ids: fileIds,
});
const vectorStoreId = vectorStore.id;
await openai.beta.vectorStores.files.create(vectorStoreId, { file_id: file.id });
const assistant = await openai.beta.assistants.create({
...assistantConfig,
tool_resources: {
file_search: {
vector_store_ids: [vectorStoreId],
},
},
}
);
assistantDetails = { assistantId: assistant.id, file_ids: fileIds, ...assistantConfig, assistant };
const thread = await openai.beta.threads.create();
return {
message: 'File processed successfully.',
userId,
assistantId: assistant.id,
threadId: thread.id,
assistantDetails,
};
It is your code and method.
Here’s a summary of your process:
uploadToOpenAI(userUiContentPath)) and get a file ID.openai.beta.vectorStores.create).await openai.beta.vectorStores.files.create(vectorStoreId, { file_id: file.id });
This step is suspicious and most likely problematic:
file_ids: fileIds parameter).This is distinctly blocked. Even an attempt to re-chunk a file and add it as a single file API call requires the original file to be deleted from the vector store first.
The only problem on OpenAI’s side is the poor error message.