Should we be storing threadIds ourselves for call back? I don’t see an option to list threads by assistant.
The use case would be to view a list of threads by assistant and load an old thread if desired. I can create my own schema and store this myself but just curious
One follow up question… It seems that thread/thread messages aren’t deleted if an assistant gets deleted. Are those threads deleted over time by a job ? or should we again be deleting these ourselves say after an assistant gets deleted?
Opinion: Yes, it makes sense to attach the threadID to your user in your database
It seems like they took it down. When it was first released there was an option to view all threads.
There was an insightful comment here indicating that it could be because a single organization could see EVERYONE’S chat logs. I believe this is the case especially because of the new warning that has appeared:
Playground messages can be viewed by anyone at your organization using the API.
So I’m guessing it will be back soon once they figure out how to make it a little more scoped. Maybe.
Threads aren’t attached to assistants. You could create a new run using a different assistant if you wanted to.
For some reason there’s no information regarding the lifespan of threads, so, indefinite. I guess for the sake of organization it makes sense to delete the thread when the conversation is finished 
My approach has been to store thread and assistant IDs in a cache (based on hash of user machine agent name), and in a later session I can bring up the cached ids and have the user decide whether to use the cached entities or not. Example in my code here:
(This is Langroid code for an agent that wraps the Assistant API)
I’m interested to know whether there are plans for exposing an API call that lists threads. The playground lists them, so it must exist.
2nd that, I’m surprised I cant get a list of ALL threads, id like to implement a delete all function.
Agree this could be useful to provide more clarification on the lifespan and management/maintenance of threads…
Necro’ing this thread because there’s an answer:
just call: https://api.openai.com/v1/threads with no other params (you’ll need the OpenAI-Beta: assistants-v2 header
If I do that with these headers:
{
'Authorization': 'Bearer sk-svcacct-...',
'Content-Type': 'application/json',
'OpenAI-Beta': 'assistants=v2'
}
I get:
Error sending message: {
error: {
message: 'Your request to GET /v1/threads must be made with a session key (that is, it can only be made from the browser). You made it with the following key type: secret.',
type: 'invalid_request_error',
param: null,
code: 'missing_scope'
}
}
if I run the code below, I create a new thread with each call (just what I didn’t want to do) rather than getting a list of existing threads. Not suprising since this is the documented API call for creating a thread. is there something else which is supposed to go into the headers to get a list back?
API Call Example<script>
async function makeApiCall() {
const apiKey = 'sk-'; // Replace with your actual API key
try {
const response = await fetch('https://api.openai.com/v1/threads', {
method: 'POST',
headers: {
'Authorization': `Bearer ${apiKey}`,
'OpenAI-Beta': 'assistants=v2',
'Content-Type': 'application/json'
}
});
if (!response.ok) {
throw new Error(`Error: ${response.status} - ${response.statusText}`);
}
const data = await response.json();
displayData(data);
// Check if there's more data to fetch
if (data.nextThread) { // Assuming 'nextThread' indicates if there's more data
await makeApiCall();
}
} catch (error) {
document.getElementById('result').textContent += `\nError: ${error.message}`;
}
}
function startApiCalls() {
document.getElementById('result').textContent = ''; // Clear previous results
makeApiCall();
}
function displayData(data) {
const resultElement = document.getElementById('result');
if (data.created_at) {
const date = new Date(data.created_at * 1000);
data.formatted_date = date.toLocaleString();
}
resultElement.textContent += JSON.stringify(data, null, 2) + '\n';
}
</script>