I can only agree with Niklas. For me the issue still persists. The answers are still to slow.
use run and stream on threads ‘client.beta.threads.runs.stream’
Hmm okey, can you elaborate a bit more my friend?
refer this
client.beta.threads.runs.stream(threadId, {
assistant_id: assistantId,
stream: true
})
.on("textCreated", (text) => {
console.log("textCreated", text);
})
.on("textDelta", (textDelta, snapshot) => {
//get word by word results (good for streaming)
// use websocket to stream word by word result on frontend
console.log("textDelta", textDelta.value);
})
// .on("event", async (event) => {})
.on("messageDone", async (event: any) => {
if (event.content[0].type === "text") {
// get completed result
//callback when the message is completed
}
})
.on("error", (error) => {
});
Hi @edwinarbus
we have an Assistant with only instructions - no knowledge from files - which is very fast when used in combination with gpt-4o-mini or gpt-4-turbo within the prompt, but when used via API still takes an average of 7-8 second to reply.
Here’s a recent example snippet from our logs:
1 Like
openai just released deprecation timeline for assistant api and revelaed the new response api. we need to migrate from assistant api to response api
2 Likes
I HEREBY DECLARE THERE IS NO LONGER A CRITICAL OUTAGE 
1 Like
Any reason to believe that the Responses API will be significantly faster than the Assistants API – especially when file_search is being used? Response time is the biggest complaint I’ve seen about Assistants. We have managed to get our response times down to 5-15s for 90% of responses. But that’s a lot slower than other APIs (both OpenAI and others). I’ve always wondered whether the slow speed is a function of the AI processing or the file search.