It's easier to not have to handle string on the models, so we already do the transformation here.

It's easier to handle this in the models if it's aTypedDict, since it matches the type.

From the DX POV, it's nicer for it to be aBaseModel ordataclass.

We should deprecate theopenai_builtin_tools in this PR.

So we'll add support for FileSearchToolParam and ComputerToolParam as well?

Note thathttps://platform.openai.com/docs/guides/tools-file-search also results in a"type": "file_search_call" output item.

Do we still want to allow people to use arbitrary built-in tools we haven't created a class for yet by passing the appropriate JSON?

I think worth including a sentence here explaining how the code execution works to make use of them — something like "these are passed to the model as part of the ModelRequestParameters" or whatever. (Not sure if that's true, haven't gotten there yet ..). But I imagine it helping someone who is trying to figure out how they are different from normal tools.

So we'll add support for FileSearchToolParam and ComputerToolParam as well?

Note thathttps://platform.openai.com/docs/guides/tools-file-search also results in a"type": "file_search_call" output item.

I think we'll want anelse ->raise "Unsupported built-in tool" here as well (and in OpenAI and Groq, looks like only Google has it currently)

We still need to implement CodeExecutionTool here, right?

The linked commit I have has a basic implementation. Not sure if it would be best to open a PR into this branch or add it after this is merged. There’s unfortunately a bunch of type errors (or were last I checked) from OpenAI where required fields are empty so need a series of guards that look redundant to checkers

No, chat completions doesn't have it.

Do we still want to allow people to use arbitrary built-in tools we haven't created a class for yet by passing the appropriate JSON?

The case I was thinking of that I mentioned on the call this morning is that someone may useOpenAIModel withOpenRouterProvider and an Anthropic model, and it's possible that the built-in tool specifications should then match those for Anthropic rather than those for OpenAI. But from a quick search it doesn't look like OpenRouter currently supports built-in tools (at least there's no doc on it), and when they do they'll probably require a OR-specific specification that they'll translate to the model-specific specs behind the scenes, so we don't have to worry about that for now.