Passing additional client state to server using session.update

API
1

We have some additional states that can vary by client, which we’d like to communicate to the server so it can take appropriate action.

It appears that the only coordination between the client’s desired state and the server occurs via the session.update response to the session.create message. I don’t see any well-defined field to hold extra content.

Though having additional fields in the object shouldn’t break anything, I wanted to check a) if an optionally present, architected object could be provided via “extra_info” or some such key so we could be safe to send this data, or b) whether it is safe to add a field in the session.update response without expecting something to break.

The alternative would be to send an undefined message to the server and have it react outside the OpenAI API, which would mean OpenAI-compliant servers would ignore that information.

In our case, we want to use intrinsic loras to improve the response being generated depending on the client’s situation (so it can’t be a global configuration for all clients known only to the server).

2

Hi @wnmills3

If I understand correctly, you’re looking for a method to add context specific to an individual client after the session has started?

If so you could create a conversation item and send a system message with the relevant context.

content

array

The content of the message, applicable for message items.

  • Message items of role system support only input_text content
  • Message items of role user support input_text and input_audio content
  • Message items of role assistant support text content.
2 Likes
3

So, normally I’ve used the system to send a prompt, but I believe you are suggesting I could put a string form of a JSON object for role “system” type “input_text” and then parse and store it as needed in the server. I could make this work.

However, it seems a more natural thing to send when establishing / negotiating the session in the session.update response from the client. This message already allows the client to alter some well defined session parameters. I guess I’m just asking for a well defined key where we could send whatever object we want to allow our server to find this within the session.

In theory, the server could review and make changes to this new object to coordinate back with the client in the session.updated response (e.g., if the server were to override a client requested state).