I believe the folks at OpenAI have been brilliant at releasing the assistants-api from the perspective of extensibility through metadata.
However I think that having some one chase down threads and runs and messages is brain clutter from the perspective of a dev. One simple exercise is the concept of session.
Why is this not exposed as a simple thing like (AND store this session in Assistant) not chase threads/runs/messages.
assistant = BaseAssistant.create()
assistant.createSession("session-id1") ## Yeah websockets
Why cannot I create a PublishQueue in the Assistant and publish events in the Assistant so that other processes can consume it from the assistant.
The key abstraction that Betaassi (GitHub - icdev2dev/betaassi: "betaassi: An innovative Python package for seamless integration and management of OpenAI sessions, designed to enhance developer experience with asynchronous server support and extendable classes) provides is the ability to define additional attributes on each one of the four entities (assistant, thread, message and run) which are contained within the relavant entity; limited by 16 maximum attributes and 512 characters by attribute.
If I want to create a message queue with high water mark contained within it, it is literally
class StreamThread (BaseThread):
hwm:str = Field(default="")
One creates, retrieves, deletes etc with the same sematics of original beta classes. The persistence of hwm is managed transparently through into the metadata of the thread.
st = StreamThread.retrieve(thread_id=sthread_id)
print(f"High Water Mark = {st.hwm}")
One can create multiple sessions on the Assistant; each one with it’s own different dynamic characteristics. For example, for one user the same assistant can provide extended context; but for other user on the same assistant with a different session, the session context can be set to be one off.
To accomodate several sessions and potential users choosing different options on the same assistant and the storage of the sessions in the assistant object itself means that creates/deletes/updates have to be single-tracked in the assistant. This involves creating a publishing-thread stored in the assistant (with that high water mark) and having a server (betaassi/src/openai_session_server at main · icdev2dev/betaassi · GitHub) in background processing those publish events .The classes themselves are written with extensions in mind.
I thought that I would give a sneak peek at what is possible with the metadata that has provided as a part of the api. The code is definitely pre-alpha. But I hope to make rapid progress on documentation, testing etc.