Conversation
src/helpers/beta/zod.ts
Outdated
There was a problem hiding this comment.
nit: these should use v4 imports https://zod.dev/library-authors#how-to-support-zod-3-and-zod-4-simultaneously
src/resources/beta/beta.ts
Outdated
There was a problem hiding this comment.
you should define a sibling chat.ts file in this directory and define a new class there instead of adding toolRunner() to the existing resource class, as now it'll be accessible from client.chat.completions.toolRunner() which isn't what we want yet
There was a problem hiding this comment.
I extended and created a BetaChat, I'm not entirely sure if this is what you had in mind, but it limits it to .beta.chat and not just .chat like we want
update types start setting up tests get non streaming working begin work on modifying anthropic tests to openai update models
src/resources/beta/chat.ts
Outdated
There was a problem hiding this comment.
this should just extend the base APIResource as there's no benefit to exposing the other methods on Completions here as well
| export class BetaCompletions extends ChatResource.Completions { | |
| export class BetaCompletions extends APIResource { |
RobertCraigie
left a comment
There was a problem hiding this comment.
Looking good.
Once we've ironed out some of the naming questions, could you also add docs for this?
src/helpers/beta/zod.ts
Outdated
There was a problem hiding this comment.
nit: this should be parameters to match the API shape
src/helpers/beta/zod.ts
Outdated
There was a problem hiding this comment.
nit: I don't think we need this check? I think we should be able to just do parameters: objectSchema below?
examples/tool-helpers-advanced.ts
Outdated
There was a problem hiding this comment.
thinking through these again, I wonder if we should call these helpers betaZodFunction()? because that feels more accurate with respect to the API.
thoughts?
There was a problem hiding this comment.
It's a big mix --
They use "tool_calls" in the actual messages for the list of tool calls, "function" as the type of the tool (or at least the ones we are using), and title their docs page "function calling."
Because we're talking about a type of tool call called a function call, for full transparency I'm actually starting to think we should call it "betaZodFunctionTool" (on their page they also refer user supplied functions as "function tool")
src/lib/beta/BetaToolRunner.ts
Outdated
There was a problem hiding this comment.
some incorrect references here 😅
src/lib/beta/BetaToolRunner.ts
Outdated
There was a problem hiding this comment.
q: why are these explicitly listed?
There was a problem hiding this comment.
Because typescript can't infer that stream: false even though we're in the else. tools/messages/model are not necessary
There was a problem hiding this comment.
In completions.ts I saw we always explicitly provide stream (we don't leave it as undefined) so I think it's okay to override it here to get nicer inference
src/lib/beta/BetaToolRunner.ts
Outdated
There was a problem hiding this comment.
this seems redundant given we check prevMessage above?
There was a problem hiding this comment.
I'll remove both checks -- both are no longer relevant under the assumption that the API always will return at least one choice
| ); | ||
|
|
||
| this.#message = this.#chatCompletion.then((resp) => resp.choices.at(0)!.message); | ||
| this.#message.catch(() => {}); |
There was a problem hiding this comment.
q: should we be logging the error? or is this safe to just ignore if the error is already reported somewhere else?
There was a problem hiding this comment.
When the caller does an "await" (i.e. for await const of), if it was rejected they will get to see the error since they'll be awaiting a rejected promise (of which we ignored the error previously -- here)
If i'm understanding right, the footgun is when they do iterator.next() without an await or looking at the result then there'll be an uncaught exception that is caught and ignored. In the way people use this I think that that is okay
There was a problem hiding this comment.
Also, in the "handles api errors" test we show where you can allow an api error to happen but keep on iterating anyway, which is an artifact of how the exception doesn't throw in the actual iterator
50dbc89 to
d5d3818
Compare
d5d3818 to
c1dd29b
Compare
b870a1f to
d18bbfb
Compare
There was a problem hiding this comment.
Thinking through naming more again (sorry), we'll likely want to add a similar helper for the Responses API as well in the future, so we should namespace these helpers in some fashion to make it clear they're for Chat Completions instead of Responses, e.g. betaChatFunction() etc.
Could you review the current naming and suggest some alternatives taking this into account?
|
|
||
| ## Tool Helpers | ||
|
|
||
| The SDK makes it easy to create and run [function tools with the chats API](https://platform.openai.com/docs/guides/function-calling). You can use Zod schemas or direct JSON schemas to describe the shape of tool input, and then you can run the tools using the `client.beta.messages.toolRunner` method. This method will automatically handle passing the inputs generated by the model into your tools and providing the results back to the model. |
There was a problem hiding this comment.
FYI looks like the primary examples in those linked docs are for the Responses API, not Chat Completions.
There was a problem hiding this comment.
It's where they explain what a function tool call actually is, but yes it focuses on the responses API. Should we re-explain it here instead and not link to it, since it could cause confusion?
Sure, some thoughts (in order of preference):
|
2db4f0a to
949d8a0
Compare
2f06c89 to
ec31a58
Compare
|
|
||
| ## Streaming Helpers | ||
|
|
||
| The SDK makes it easy to stream responses, by providing an emitter helper via `.stream()`: |
There was a problem hiding this comment.
nit: I think the flow is slightly better if you do
| The SDK makes it easy to stream responses, by providing an emitter helper via `.stream()`: | |
| The SDK makes it easy to stream responses by providing an emitter helper via `.stream()`: |
| main(); | ||
| ``` | ||
|
|
||
| With `.stream()` you get event handlers, accumulation, and an async iterable. |
There was a problem hiding this comment.
could we add hyper links from here to the relevant sections in helpers.md? e.g. "event handlers", "accumulation"
| }); | ||
| ``` | ||
|
|
||
| ## Streaming Helpers |
| for await (const messageStream of runner) { | ||
| for await (const event of messageStream) { |
There was a problem hiding this comment.
I don't think messageStream is an accurate description of this
|
|
||
| ## Tool Helpers | ||
|
|
||
| The SDK makes it easy to create and run [function tools with the chats API](https://platform.openai.com/docs/guides/function-calling). You can use Zod schemas or direct JSON schemas to describe the shape of tool input, and then you can run the tools using the `client.beta.messages.toolRunner` method. This method will automatically handle passing the inputs generated by the model into your tools and providing the results back to the model. |
There was a problem hiding this comment.
| The SDK makes it easy to create and run [function tools with the chats API](https://platform.openai.com/docs/guides/function-calling). You can use Zod schemas or direct JSON schemas to describe the shape of tool input, and then you can run the tools using the `client.beta.messages.toolRunner` method. This method will automatically handle passing the inputs generated by the model into your tools and providing the results back to the model. | |
| The SDK makes it easy to create and run [function tools with the chat completion API](https://platform.openai.com/docs/guides/function-calling). Function tools let the agent call functions you define in your code, allowing the model to request specific actions or data retrieval that your application then executes and returns. | |
| You can use Zod schemas or direct JSON schemas to describe the shape of tool input, and then you can run the tools using the `client.beta.messages.toolRunner` method. This method will automatically handle passing the inputs generated by the model into your tools and providing the results back to the model. |
we should also link to the api reference in helpers.md here.
Changes being requested
Update the tool call pattern to use a new async iterable style pattern that makes more easily accessible tool calls as they are fired, and API responses.
Additional context & links