fix(core): count a Responses request when the provider omits usage - #4444

Both points were right. Fixed in the latest commit.

Streaming. You are right that this left a streaming versus non-streaming split, which AGENTS.md calls out directly. The reason I had scoped it out was OpenAIHostedMultiAgentModel: it inherits stream_response, and marking the terminal event there would have double-counted its synthetic multiplexed responses, which is what broke test_injection_failure_after_completion_starts_continuation_response on my first attempt.

The way out was to stop thinking about stream_response and count at the transport exits this class actually owns, which is where "one request happened" is known:

• _fetch_response, non-streaming HTTP
• OpenAIResponsesWSModel._fetch_response, non-streaming websocket
• _ResponseStreamWithRequestId.__anext__, the HTTP stream wrapper this class constructs
• _iter_websocket_response_events, the websocket event iterator

OpenAIHostedMultiAgentModel overrides _fetch_response and drives its own _iter_websocket_turn, so it never reaches any of the four and its accounting is untouched. That is checked by the Hosted Multi-Agent suite still passing rather than by a type check on self. Only response.completed is counted; failed, incomplete and error raise before any usage is consumed.

Span usage. Fixed on both paths, non-streaming and streamed, mirroring what openai_chatcompletions.py already does at the equivalent point.

Five regression tests now, covering HTTP and websocket in both streaming and non-streaming form plus the span payload. All five fail against main and pass here. uv run pytest tests/models/ tests/extensions/ is green at 2235 passed, and .agents/skills/code-change-verification/scripts/run.sh passes.

One gap I am deliberately leaving, so it is not a surprise: the compatibility branch in _fetch_response for custom clients that implement responses.create() but not with_streaming_response returns the provider's iterator directly and is not wrapped, so it still does not count. Routing it through _ResponseStreamWithRequestId would change that path's stream lifecycle, and the wrapper needs an async iterator where that branch may hand back an async iterable. Happy to take it on if you would rather have it covered.

Thanks, both were right. Done in 95952a2.

Fallback path. It now goes through _ResponseStreamWithRequestId, so terminal-event accounting is the same code as the normal HTTP stream rather than a second copy. To keep that path's behavior, the wrapper resolves its iterator on first __anext__ instead of at construction, so a client handing back an async iterable still works, and _close_stream_once closes the object it was given, so cleanup is unchanged. The fallback passes request_id=None and a no-op cleanup, since the SDK never opened that transport.

Span usage before the yield. Moved into the ResponseCompletedEvent branch, so it runs before yield chunk rather than after the loop. The post-loop copy is gone, so there is one place that sets it.

Two tests added for exactly those cases:

• test_fallback_stream_counts_request_when_provider_omits_usage uses a client with no with_streaming_response whose create() returns an async iterable with no __anext__ of its own, and asserts the run reports one request.
• test_streamed_span_usage_survives_a_consumer_that_stops_at_the_terminal_event consumes stream_response() directly, breaks at response.completed, closes the generator, and asserts the span still carries the count.

Both fail against the previous head. Raw usage stays absent and token counts stay zero in every one of these, and the Hosted Multi-Agent suite is untouched and still passing, which is the check that the exclusion still holds.

On CI: tests (3.11) on the previous head failed on tests/realtime/test_session.py::test_tracked_task_reentering_active_cleanup_does_not_create_wait_cycle with a TimeoutError, which I do not think is this PR. That test is pure in-process asyncio with a wait_for(..., timeout=0.5) deadlock guard, it ran on xdist worker gw2, and the same commit passed tests on 3.10, 3.12, 3.13, 3.14 and Windows. agents.models.openai_responses is also not reachable from agents.realtime.session through any import path, so this diff cannot affect it. I could not reproduce it locally in 25 serial runs, in the realtime suite at -n 24, or in two full -n 9 --dist worksteal runs under heavy CPU contention. I have not pushed anything for it. If it reappears on this new run I will dig further rather than assume.

Good catch, that was a leak I introduced when I widened the wrapper to accept an iterable. Fixed in the latest commit.

_close_stream_once now closes the resolved iterator and then the source, and only closes the source separately when it is a different object, so the normal path where __aiter__() returns self still closes exactly once.

Worth noting how it is tested, because my first attempt at a regression test was useless: asserting on the existing exhaustion test passes either way, since an exhausted async generator runs its own finally. The leak only shows on an early close. test_fallback_stream_close_releases_the_resolved_iterator consumes one event, closes the stream, and asserts the generator built by __aiter__() was finalized as well as the source. It fails against the previous commit and passes here.

.agents/skills/code-change-verification/scripts/run.sh passes.

Thanks for trying to resolve the issue. #4453 resolves it and its commit includes your contribution credit.