[halcyon-r]

runAnthropicStreaming collects tool_use blocks in a map keyed by
content-block index and assembles the final response by ranging over the map,
so when one streamed response carries multiple parallel tool calls, the
resulting parts — and the FunctionCalls the agent loop executes — come out in
randomized order instead of the order the provider emitted them. Same class of
bug as #2988, which fixed randomized map iteration for Ollama argument order.

Tool results are matched by call ID, so nothing mispairs. The nondeterminism
shows up everywhere the parts travel: session history and replay, traces and UI
rendering, and any serial runner that executes the calls in part order. The
non-streaming path iterates message.Content in order, so streaming and
non-streaming disagreed for the same response shape.

• Assemble the final response by iterating the collected indices in sorted
  order (slices.Sorted(maps.Keys(...))), matching the non-streaming path.
• Collection and delta handling are unchanged; the text-before-tool-call part
  layout is unchanged.

Testing: TestAnthropicStreamingKeepsParallelToolCallOrder streams one text
block plus three tool calls (including one with no input deltas) and asserts
part order. It fails without the fix and loops 20× because map iteration order
is randomized and a single run can pass by chance. go test ./adk/pkg/models/
(run from go/) passes and go vet is clean.

[halcyon-r]

Hi @supreme-gg-gg @dimetron, could you take a look at this PR when you get a chance? It's a related fix to #3289 in the same Anthropic adapter, so it may be easier to review them together. The CI workflows are also waiting for maintainer approval to run. Thanks!

[github-actions]

This pull request has been marked as stale because of no activity in the last 15 days. It will be closed in the next 5 days unless it is tagged "no stalebot" or other activity occurs.