feat: support tool-level provider options in OpenAI-compatible provider - #11505
feat: support tool-level provider options in OpenAI-compatible provider#11505KONRADS098 wants to merge 2 commits into
Conversation
- Add getToolMetadata() helper function to extract providerOptions from tools - Spread tool-level provider options into prepared tools for API requests - Update return type to support additional metadata fields via Record<string, unknown> - Add comprehensive tests for tool-level providerOptions support - Tests follow the same pattern as message-level provider options in convert-to-openai-compatible-chat-messages.test.ts Note: Currently uses the hardcoded 'openaiCompatible' key pattern to maintain consistency with message-level conversion behavior. Dynamic provider names for both message and tool options should be addressed in a future refactoring.
ghost
added
ai/core
…ions in OpenAI-compatible provider
6080a26 to
ad5241d
Compare
| function getToolMetadata(tool: { providerOptions?: SharedV3ProviderMetadata }) { | ||
| return tool?.providerOptions?.openaiCompatible ?? {}; | ||
| } |
There was a problem hiding this comment.
instead of openaiCompatible, can you pass in the provider name so it matches how it is handled in packages/openai-compatible/src/chat/openai-compatible-chat-language-model.ts?
(ideally that parsing would be extracted into a helper function)
There was a problem hiding this comment.
I had this initially, but then I noticed that we already have some inconsistencies in this regard. I decided to stick to what we are doing in the packages/openai-compatible/src/chat/convert-to-openai-compatible-chat-messages.ts.
That being said it would be better to pass the provider name like you suggested.
- Shall I update the
packages/openai-compatible/src/chat/convert-to-openai-compatible-chat-messages.tsandpackages/openai-compatible/src/chat/openai-compatible-prepare-tools.tsto use the provider name? - For the
packages/openai-compatible/src/chat/convert-to-openai-compatible-chat-messages.ts, shall I use a fallback to theopenaiCompatible, as consumers might have already integrated with this key?
There was a problem hiding this comment.
It should be consistent. I would suggest a separate PR that cleans out the current behavior 1st and makes it consistent. That way we we can focus first on consistency and think about backwards compat, testing, etc. Once that lands we can continue with this PR. Would you be interested in taking this on?
There was a problem hiding this comment.
Sounds good to me, will tag you once it's ready.
2 participants
Summary
This PR adds support for tool-level provider options in the OpenAI-compatible provider. Tools can now include custom provider metadata through the
providerOptionsfield, which gets properly merged into the prepared tools for API requests.Changes Made
prepareToolsfunction to extract and merge tool-level metadata fromproviderOptions.openaiCompatible