You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Non-standard OpenAI-like response format on tool_calls. #160
Hello, opening the bug here despite it being not the best place.
Wanted to let you know about some non-standard answers in the Together API which force special cases in OpenAI-like protocol parsers.
The root is returning null in place of a missing (or undefined) field. Not a big deal, it just forces special cases, as OpenAI-compliant parsers do not treat null and undefined (aka missing) fields equally.
This happens in 3 instances (that I know of):
choices[number].delta.tool_calls = null; // for text-only responses
choices[number].delta.tool_calls[number].function.arguments = null; // seems to be during the first call when the name is given
choices[number].delta.tool_calls[number].function.name = null; // seems to be during the continuation of json tool call arguments
This is nothing major, but imagine that other downstream parsers will break and have to add special cases for Together. Sometimes it can hinder adoption, so I thought you'd appreciate if I'd let you know.
Hi! I would like to take this one. On the streaming delta, tool_calls is currently untyped (it rides on extra="allow"), so an explicit null and an omitted field behave differently (None versus AttributeError), tool call fragments come back as raw dicts, and model_dump(exclude_none=True) still leaks the nested function.name and arguments nulls. I opened PR #454 that types the streaming delta so all three reported cases parse the same way openai-python does, with a regression test for each. Kept small for V1 maintenance mode. Thanks, Rayyan
Activity
Together: add tool_calls=null exception.
[-]Non-standard OpenAI-like response format.[/-][+]Non-standard OpenAI-like response format on tool_calls.[/+]orangetin commentedon Sep 9, 2024
thanks! this should be fixed this week
Ranoobaba commentedon Jul 21, 2026
Hi! I would like to take this one. On the streaming delta, tool_calls is currently untyped (it rides on extra="allow"), so an explicit null and an omitted field behave differently (None versus AttributeError), tool call fragments come back as raw dicts, and model_dump(exclude_none=True) still leaks the nested function.name and arguments nulls. I opened PR #454 that types the streaming delta so all three reported cases parse the same way openai-python does, with a regression test for each. Kept small for V1 maintenance mode. Thanks, Rayyan
fix: normalize null tool_calls fields in streaming chat deltas
fix: normalize null and missing fields in streaming chat deltas
blainekasten commentedon Sep 15, 2026
This repo is deprecated and is not taking new patches. Thanks.
The new SDK is hosted at https://github.com/togethercomputer/together-py