I am not sure if this fits AIProxySwift's vision/goal but it would make it much more flexible if there is an abstraction layer on top of the current concrete providers response/request implementation. A "generic provider" request/response model such as ProviderStreamingResponse/Request, ProviderUsageResponse/Request, ProviderCompletionResponse/Request... coupled with a provider manager factory would make working with the library super simple.
Simplified Example: Creating a new provider from the factory by specifying the type (.openAI, .anthropic, .gemini, .deepseek, ...)
The usage could be as simple as
let providerService = try await ProviderManager.createProviderService(type: .openAI)
var streamingRequest = ProviderStreamingRequest(model: modelName, messages: messagesHistory)
let streamingResponse = await providerService.fetchStreamingResponse(request: streamingRequest)
I am not sure if this fits AIProxySwift's vision/goal but it would make it much more flexible if there is an abstraction layer on top of the current concrete providers response/request implementation. A "generic provider" request/response model such as ProviderStreamingResponse/Request, ProviderUsageResponse/Request, ProviderCompletionResponse/Request... coupled with a provider manager factory would make working with the library super simple.
Simplified Example: Creating a new provider from the factory by specifying the type (.openAI, .anthropic, .gemini, .deepseek, ...)
The usage could be as simple as
let providerService = try await ProviderManager.createProviderService(type: .openAI)
var streamingRequest = ProviderStreamingRequest(model: modelName, messages: messagesHistory)
let streamingResponse = await providerService.fetchStreamingResponse(request: streamingRequest)