Streaming Function Calls: Assemble Partial Arguments

Streaming function calling needs a different boundary from streaming chat text: show progress immediately, but execute only after a complete, validated call. In Chat Completions, function arguments arrive as string fragments inside tool-call deltas, not necessarily as independently valid JSON objects. This walkthrough builds an assembler around that distinction. ([developers.openai.com](https://developers.openai.com/api/reference/resources/chat/subresources/completions/streaming-events))

§1 Step 1: Define the Tool and Its Execution Boundary

Use a small example: get_weather accepts a required city string and a unit restricted to celsius or fahrenheit. Define those requirements in the tool schema, supply the tool with your request, and enable streaming. Function calling is a conversation loop: receive the requested call, run application code, and return its result to the model. ([developers.openai.com](https://developers.openai.com/api/docs/guides/function-calling))

Keep three application stages separate: receiving fragments, validating arguments, and executing tools. For this implementation, make the assembler return candidate calls rather than allowing it to invoke business logic directly.

§2 Step 2: Create a Buffer for Each Tool Call

For Chat Completions, inspect every choice and every entry in delta.tool_calls. The tool-call index identifies which call a fragment belongs to; preserve the call ID and function name when supplied. These metadata fields may appear only in an initial delta. ([developers.openai.com](https://developers.openai.com/api/docs/guides/function-calling))

Use a request-local map keyed by choice index and tool-call index. Give each entry an ID, function name, argumentsText string, and completion state. Treat missing metadata as no update, not permission to erase earlier values.

Do not use the function name as your key. Design for two requests to the same function with different arguments, and keep their buffers independent.

§3 Step 3: Append Argument Fragments Without Modification

Append each supplied function.arguments fragment to its matching argumentsText buffer, preserving arrival order. The documented aggregation pattern accumulates argument strings rather than merging parsed objects. ([developers.openai.com](https://developers.openai.com/api/docs/guides/function-calling))

For example, three illustrative fragments might contain {"city":, then "Boston", then ,"unit":"celsius"}. Their concatenation produces {"city":"Boston","unit":"celsius"}. The individual pieces are not complete argument objects.

Keep this path deliberately mechanical: append the received string without trimming whitespace, adding commas, or repairing quotes. Reserve any preview formatting for a separate display value, leaving the execution buffer untouched.

§4 Step 4: Wait for the Protocol Completion Signal

In Chat Completions, finish_reason equal to tool_calls signals that the model stopped to request tools. A length finish reason instead indicates a token limit, so do not treat that outcome as successful argument completion. Validate generated arguments before invoking a function. ([developers.openai.com](https://developers.openai.com/api/reference/resources/chat/subresources/completions/streaming-events))

Adopt a conservative policy: mark a call executable only after the expected terminal signal, successful JSON parsing, and schema validation. Reject unknown functions, missing identifiers, unauthorized operations, and invalid parameter values. A syntactically complete object should not bypass these checks.

§5 Step 5: Return Results With the Original Call Identity

After validation, dispatch the approved function. In Chat Completions, preserve the assistant message containing its assembled tool_calls and append tool-result messages associated with the original call IDs before requesting the next answer. This maintains the connection between each requested action and its output. ([developers.openai.com](https://developers.openai.com/api/docs/guides/function-calling))

For side-effecting tools, add an application-level idempotency key tied to the intended operation. On interruption, discard unfinished assembly state and require an explicit retry decision rather than automatically replaying an action.

§6 Step 6: Test Fragment Boundaries Before Using Fluxio

Build tests around the assembler’s contract:

• – Split arguments inside quoted strings, escaped characters, and nested objects.
• – Interleave fragments for multiple calls and verify their buffers stay separate.
• – Simulate cancellation, malformed final JSON, and missing call metadata.
• – Assert that execution never occurs before completion and validation.

Fluxio fits naturally when you want a streaming-first, pay-per-token relay with OpenAI SDK compatibility. Use it behind your transport layer while keeping argument assembly and execution safeguards in your application. Verify streamed tool-call behavior for your selected model and route before production deployment.

Sign up for Fluxio.