chat(protocol="messages", stream=True) now gives the run's totals through stream.get_final_result() instead of a closing result event, so the stream itself carries only the Anthropic SDK's events, exactly as in 0.4.4. Answers that stop short raise on more paths instead of passing as complete: a managed (cloud) chat() cut at max_tokens or refused, an answer cut by a full context window on the cloud or claude-code/, and the text stream of chat_completions(stream=True). On claude-code/, an answer the CLI resumed after its output cap no longer loses its first part, and a stream the CLI retried no longer repeats its text.

Changes

• get_final_result() replaces the result event (feat: report token usage for local indexing and chat runs, failures included #572, unreleased). The stream is now a MessagesStream. Iterating it yields the Anthropic SDK's events, so a finished run ends with message_stop again and code reading events[-1].message keeps working. get_final_result() reads the rest of the stream first, then returns the run's usage (summed across turns), its messages turn sequence and its final turn's stop_reason, the same values the non-stream envelope carries, so a caller reading only the final result can still tell a cut answer. Called before the end, it waits for the run rather than return a partial total, and a failed run raises the same error from it as iterating does. This follows the official SDKs: Anthropic's get_final_message(), OpenAI's get_final_response(), the tool runner's until_done(). MessagesStream is exported next to ChatStream.
• A cut managed answer raises. The managed endpoint reports Anthropic's stop reasons as finish_reason ("max_tokens", "refusal"), not OpenAI's "length" and "content_filter", so the answer lane's cut check never fired on the cloud. The check now knows both sets of names: chat() raises with the text in partial_answer, and a stream raises after its text, as own-model chat already does. The endpoint's values pass through untouched: protocol="chat_completions" still returns finish_reason as the endpoint sent it.
• An answer cut by a full context window raises too. Claude stops with stop_reason "model_context_window_exceeded" when its context window fills before the answer is finished, and on claude-code/ and the managed endpoint such an answer passed as complete. It now raises as a max_tokens cut does, and protocol="chat_completions" on claude-code/ marks it "length". The Claude Code CLI (2.1.301) builds the same max_output_tokens error for this stop reason that it builds for max_tokens. LiteLLM-routed Claude models still get "stop", since LiteLLM maps this stop reason that way.
• chat_completions(stream=True)'s text stream raises on a cut answer. Without stream_metadata it yields only the answer text, and on every engine it dropped the finish chunk, so an answer cut at max_tokens, filtered, or (on the managed endpoint) refused ended like a finished one, though this stream is documented as chat(stream=True, show_process=False), which raises. It now raises after the text, with the run's usage. stream_metadata streams keep marking the cut in finish_reason. What the stream yields is unchanged.
• A resumed claude-code/ answer comes back whole. When an answer hits the Claude Code CLI's output cap, the CLI resumes it with a second model call, but its ResultMessage.result holds only the last text block, so chat() and chat_completions() returned only the last part, as if complete, while the stream showed both. The answer is now the run's own assistant text since the last tool call.
• A retried claude-code/ stream doesn't repeat its text. When a stream failed after some text and the CLI retried the model call, the retry's text went out a second time. A retry's text now goes out only once it passes what was already sent; a retry that writes it differently follows a blank line, as the CLI's non-streaming fallback already did.
• Claude's refusal stop maps as LiteLLM maps it. The claude-code/ engine mapped only max_tokens to an unfinished finish_reason; it now maps Claude's stop reasons the way LiteLLM's finish-reason table does (max_tokens to "length", refusal to "content_filter"). Today's Claude Code CLI (2.1.299 to 2.1.301) reports a refusal as an API error instead, which claude-code/ already raises as Claude Code failed: ... with usage; the mapping covers a CLI that reports the stop reason, as the max_tokens branch does.

Verification

• CI: 970 passed with frameworks on py3.10 and py3.13 (969 + 1 skipped on pdfium 4), 689 passed + 281 skipped without, on anthropic 1.17.0, claude-agent-sdk 0.2.170, openai-agents 0.20.0 and litellm 1.105.3.
• Locally: 963 passed + 7 skipped; with the frameworks blocked, 682 passed + 288 skipped. The first commit passes on its own too, and the Messages tests pass on anthropic 0.122.0, the floor.
• The real bundled Claude Code CLI (2.1.301), run against a local mock Messages API: an answer resumed after the output cap, a stream dropped and retried, and a reply in two text blocks all come back whole and once, from chat(), its stream and chat_completions(); with the resumes used up, all three still raise. A refused answer streams a message_delta with stop_reason "refusal" before the CLI turns it into an error, and that is the stop reason the managed endpoint relays as finish_reason. The CLI version the managed endpoint runs (2.1.273), read the way the endpoint reads it, ends a refusal with "refusal" after its text and an answer still cut after three resumes with "max_tokens".
• The new tests catch seventeen mutants: no drain before returning, the captured result overwritten, the Anthropic names dropped, the claude-code/ refusal mapping dropped, "model_context_window_exceeded" dropped from either list (two), ResultMessage.result used again, the tool-call reset dropped, every retried delta sent again, the fallback compared with the retry's own text, a differing retry sent without its blank line, the text stream's raise dropped, each engine's text stream left on its old path (three), no stop_reason, the first turn's stop_reason.