Support for Assistants API v2

[sevzas]

This is an enhancement request.

OpenAI has overhauled the assistants Api - https://platform.openai.com/docs/changelog/released-assistants-api-updates

I'm hoping that Forge.OpenAI can be enhanced to support the new Assistants API features.

Thank You!

[JZO001]

Hello,
I made some changes on the API, following missing properties, new models, etc.

[sevzas]

I see in v1.37 the following properties were added to AssistantRequestBase: Temperature, TopP and ResponseFormat so I can create an assistant and specify the new fields.
But I don't see the new fields on AssistantResponse so I can't read those fields back. Can you add them?

Plus it's not clear how I can specify that I want to use the Assistants V2 API instead of the V1 Api - OpenAI docs indicate that this request header needs to be present: "OpenAI-Beta: assistants=v2" - you might want to make that configurable through OpenAIOptions and possibly overridable on a per-operation basis (this might unnecessary).

[sevzas]

Additionally I noticed that some OpenAI-supported parameters are missing from the Forge.OpenAI code in the areas of Threads and Runs:
CreateThreadAndRunRequest - https://platform.openai.com/docs/api-reference/runs/createThreadAndRun
CreateThreadRequest - https://platform.openai.com/docs/api-reference/threads/createThread
CreateRunRequest - https://platform.openai.com/docs/api-reference/runs/createRun

The related GetXXX and ModifyXXX need to support the new parameters.

[JZO001]

Hello sevzas,

Thanks for the feedbacks. I see there were lots of changes again in the API documentation, I try to follow them as I have some time to do. Please be patient, I try to do my best, sometimes slower, sometimes faster, depends on my amount of works.

I almost finished with the missing properties on the functions above, but some properties are requires more time to implement because of that is the first time, the server side developers sends back string or object under the same property name, which requires converters. So it is not just a "lets create a property and job done" type work.

I will get back to you.

[sevzas]

I agree, there are many changes related to Assistants API for v2. Thank you for your hard work, Zoltan.

[JZO001]

Hello,
Please check v1.4.0. A couple of improvements applied in this version, supporting the v2 APIs

[theyellowgreen]

HI Zoltan, you are doing very cool, i like your lib =)

There is not "retrieval" tool, it should be "file_search"
https://github.com/JZO001/Forge.OpenAI/blob/main/Forge.OpenAI/Models/Shared/Tool.cs#L16

This is migration guide https://platform.openai.com/docs/assistants/migration

[sevzas]

I tried v1.41 ... There are build errors in my code because OpenAIService.CreateService(OpenAIOptions) has been removed. Can you put this factory method back? I don't use DI so I can't use the remaining 2 flavors of CreateService( )

I see in the code that "OpenAI-Beta: assistants=v2" appears to be the default so I understand that Forge.OpenAI supports v2 assistants API by default (which is fine for me).

[JZO001]

You do not have to use DI directly. Please check manual creation of the service in the Playground -> MultipleApiKeyUsage -> Program.cs, line 29 - 33.

[sevzas]

I managed to create an instance of OpenAIService based on Playground -> MultipleApiKeyUsage -> Program.cs, line 29 - 33.
However, this code is cryptic/complicated for developers that want a quick, simple console app to test your API. If a developer doesn't see a straight-forward way to instantiate a service, they will likely move on to try a different API instead of asking for help like I did. Please re-consider putting OpenAIService.CreateService(OpenAIOptions) back into the code.

Issues I see:

1. It appears that the JSON Serializer has an error de-serializing Forge.OpenAI.Models.Messages.MessageData because IncompleteDetails and Status properties have the same [JsonPropertyName("status")] - so at the moment I'm unable to read Messages from a Thread+Run.
2. AssistantRequest.ResponseFormat is of type Forge.OpenAI.Models.Shared.ResponseFormat however AssistantResponse.ResponseFormat is Object. I think the two ResponseFormat properties should be of the same type.

[JZO001]

Hello,
The messages was fixed in 1.4.2.

The library basicly based on DI. The factory service which was removed was a bad conception, left behind unmanaged resource in the background and does not work properly with the given option. The new one is same, except you have a better freedom to initialize the service behavior manually.

However, I can help you with an additional CreateService signature, where you can provide a method, which will accept the configuration from your side. In that case, just set necessary values to the configuration. Also you can handle the lifecycle of the internal ServiceProvider, or if your service instance is global or its liefecycle eqvivalent with your application, than you can discard it with _

IOpenAIService openAiInstanceForUserB = OpenAIService.CreateService((OpenAIOptions options) =>
{
options.AuthenticationInfo = new AuthenticationInfo(apiKeyForUserB);
}, out _);

I have update the sample code in MultipleApiKeyUsage project, please have a look.

[sevzas]

I switched to the new CreateService() signature that you added.
I confirmed that JSON DeSerialization of Forge.OpenAI.Models.Messages.MessageData is fixed so my code is working now with 1.43.

Thank you.

[JZO001]

Hi,
I added in v1.4.4 a similar service factory method, like the old what you have requested:

"CreateService(OpenAIOptions options, out ServiceProvider serviceProvider)"

It will copy your settings into the internal option instance. You can discard the serviceProvider as I mentioned above, if you do not want to manage the ServiceProvider. This a convenience function, but its using reflection for the copy of properties.

I have update the sample code in MultipleApiKeyUsage project, please have a look, if you are interested in it.