I’m receiving the following error when my Assistant tries to access a vector store:
Invalid URL (GET /v1/vector_stores/vs_68feaabc6d4c819181543489b7c792f9/associations)
The store exists and is attached correctly, but the Assistant cannot retrieve it.
Could you please confirm if this is a known issue with the File Search / Vector Store API?
Is your concern actually about using the platform web site for assistants? What page?
It seems that OpenAI dropped their API backend endpoint that shows the vector store “connections” in their vector store user interface (or it is just another thing malfunctioning for days…), but the Vector Store UI in the site still tries to make calls that would otherwise list the assistant IDs where a vector store is used. Something not on the API.
There should not be any API calls that you have to make - or can make - to that ../associations endpoint yourself in order to use Assistants with the file search tool. It is solely for OpenAI’s site, and as purely a part of the dashboard backend. Calls to that API URL are blocked without an owner session key by web browser (or a very good impersonation).
No, that file name in my screenshot is not self-censored. That is the dashboard->storage → vector stores not listing the files – not clearing a deleted file from the vector store as is the API’s promise. And then the “used by” that is throwing an error for a feature no longer working.
Problems continuing from these earlier reports - not just you:
Thanks for the clarification!
However, in my case this doesn’t seem to be just a visual dashboard issue.
My Assistant actually cannot access the files from the attached vector store — it keeps responding:
“Program details are currently unavailable because I can’t access the files.”
and sometimes also:
“I encountered a problem while checking the file. Please try again later or let me know if I can help with something else.”
The association error (Invalid URL (GET /v1/vector_stores/.../associations)) appears both in the dashboard and during runtime when the Assistant tries to read the files.
So this may indicate that the /associations endpoint issue is also affecting live Assistant–Vector Store connections, not just the UI.
Can anyone confirm if the API is still resolving vector store associations properly on the backend?
Let’s take a look.
The first thing I notice is that at the bottom of “Assistants” in the UI it says: “Updated 5/14, 1:55 AM” - but doesn’t show that the assistant I’m going to run is from 2024.
A vector store ID in the “assistant” has a backend call that gets its name and size for display as shown. That works in listing them.
It’s only appropriate that I also make a new test Assistant and new vector store with a file also as relevant as assistants: OpenAPI specification when it was 1/3 the size it is now:
![]()
and a “GPTs”-era model:
Yep. Useless for new. Then, useless for old:
I don’t think that has direct corellation to ‘associations’ - it just fails.
So add ‘massive failure with multi-day inaction’, and we are at what, number four with vector stores in the last three months?
Try to diagnose: 90% view on this machine to even make the 'logs" button work to get this great diagnosis of ‘steps’, absolute brilliance:
Conclusion: I encourage you to leave Assistants and Vector Stores behind in your future AI developments.
I can confirm the same issue where vector store associations are not being resolved.
In this case it is an existing vector store already connected to an assistant.
Will raise this issue with the team and thank you for flagging!
Thanks everyone for checking and confirming!
It seems clear now that this issue is affecting both the dashboard and live assistant–vector store connections.
Hopefully the team can resolve it soon.
If anyone notices that the issue gets fixed or the associations start resolving again, please drop a quick note here — it’d be great to know when it’s back to normal. ![]()
I’m having issues with vector store too: API Problem with file processing, file uploaded but not found in vector store
The problem seems to be there at least from yesterday, but OpenAI doesn’t seem to be aware of it.
Error creating files: Error code: 404 - {'error': {'message': "No file found with id 'file-Uzx4KBALYwxHUwbLV8hoGJ' in vector store 'vs_68ff70740380819199a336c074652ac9'.", 'type': 'invalid_request_error', 'param': None, 'code': None}}
same, so sad
Hello, I’m experiencing the same issue.
assistants using the File Search (Vector Store) tool cannot retrieve data from their attached documents. All configuration steps were performed correctly: the vector store is fully processed (status: completed with 3 files), and the assistant correctly references the vector store ID. However, when a run is executed, the tool_resources field in the run object becomes empty ({}), meaning the assistant loses access to the vector store at runtime. This behavior matches the ongoing “Invalid URL (GET /v1/vector_stores/…/associations)” bug reported in the OpenAI Developer Community. I’ve confirmed this via multiple API calls, using proper headers and models (gpt-4o, assistants=v2). The issue appears to be a backend regression where vector store associations are not propagated to runs, breaking document retrieval functionality.
Is this a same issue?
I created the vector store yesterday and it works well as a tool parameter of responses api, but cannot get file contents from the vector store.
The issue retrieving files has been reported in a previous post, but is part of multi-faceted issues with vector stores that have continued for days. Other symptoms are delays in updating server objects on upload (breaking SDK polling), incomplete file listings, non-deleting file attachments, missing endpoint for a platform site service - and plainly, Assistants that cannot answer because the file search tool returns an error instead of retrieving information and loading tokens.
I’d like you to carefully read this announcement:
https://openai.com/index/introducing-company-knowledge/
If OpenAI is going directly compete for your business vertical, why would they continue to provide a quality (yet generic and unconfigurable as a tool) service for you to wrap? Quality has been degraded with unfortunate timing in direct correlation to that announcement, across multiple endpoints, to disrupt your reputation?
This image is a comparison, today, of the benchmarks of two competing AI embeddings models, at their full dimensionality (embeddings being the underlying AI power of a vector store semantic search). The red one was GA last month. The orange one was released January 2024,
MTEB Score, Multilingual, v2 Mean (task)
| MRL Dimension | gemini-embedding-001 | embeddinggemma-300m | 3-large | 3-small |
|---|---|---|---|---|
| 3072 | 68.37 | — | 58.93 | — |
| 2048 | 68.16 | — | — | — |
| 1536 | 68.17 | — | — | 54.00 |
| 768 | 67.99 | 61.15 | — | — |
| 512 | 67.55 | 60.71 | — | ? |
| 256 | 66.19 | 59.68 | ? | — |
| 128 | 63.31 | 58.23 | — | — |
and with only 256 Matryoshka dimensions of that shown 3072-dimension 3-large embeddings model score being employed for OpenAI’s vector store semantic search product, you can run open-weight EmbeddingGemma in 2MB and be competitive; quant Q8_0 (768d): 60.93. Knowledge of August 2024 instead of September 2021 that could even classify “ChatGPT” to similar space as “OpenAI”.
With no MTEB v2 benchmarks at lower dimensionality, here’s text-embeddings-3-large scaling on MTEB v1, by OpenAI in 2024, for interpretation:
| – | 3-large | 3-large | 3-large |
|---|---|---|---|
| Embedding size | 256 | 1024 | 3072 |
| Average MTEB score | 62.0 | 64.1 | 64.52 |
Update: I notice that the AI model used for vector stores has been downgraded from its earlier “256 dimensions of 3-large” (along with an upgrade to a per-use fee) - Now documentation says text-embedding-3-small (and doesn’t state dimension reduction).
This appears to be the culprit for my issue as well: File Search Issue in Assistant Playground







