fix: count a model request when the provider omits usage - #4281

Thanks, all three points are addressed in 0194e7a.

Streaming was still reporting zero. Confirmed before changing anything: a streamed run over a provider that sends no usage chunk reported requests == 0 while the non-streaming call on the same provider reported 1, so the fix I first submitted just moved the inconsistency rather than removing it.

Fixed at the owning adapter boundaries. An adapter that reaches a terminal response without a provider usage payload now marks that response:

mark_request_completed_without_usage(final_response)

Nothing is synthesized, so raw_usage stays None and token counts are never reported as real zeros. New tests assert both halves of that.

ChatCmplStreamHandler is shared by the OpenAI Chat Completions, LiteLLM and AnyLLM chat streams, so marking it there covers all three from one place. AnyLLM's Responses stream is marked where it captures the completed response, which closes the non-streaming/streaming split you pointed out there.

The generic run-loop fallback is unchanged in effect. It reads a helper that defaults to zero:

def requests_for_response_without_usage(response: Any) -> int:
    """Defaults to zero so adapters that multiplex several provider responses into one,
    and report their counts separately, are not double-counted."""
    return 1 if getattr(response, _REQUEST_WITHOUT_USAGE_ATTR, False) else 0

So Hosted Multi-Agent's interim logical completions with usage=None still contribute nothing, and its accumulated request usage remains the only source of truth. tests/extensions/experimental/hosted_multi_agent/ is 30 passed, 1 skipped, including test_injection_failure_after_completion_starts_continuation_response, which is the test that caught the double-count when I tried the unconditional Usage(requests=1) in the first place.

Regression coverage, each failing on main and passing here:

Plus paired guards that pass either way, so the usage-less path cannot start double-counting later: test_streamed_run_does_not_double_count_when_usage_is_present, test_any_llm_responses_stream_with_usage_is_not_marked.

The end-to-end streaming test asserts what a user sees rather than the marker, so it is a genuine main failure rather than one that only fails because a new symbol is missing:

assert result.context_wrapper.usage.requests == 1   # 0 on main
assert result.context_wrapper.usage.total_tokens == 0
assert completed.response.usage is None             # nothing synthesized

Can you resolve the conflicts?

Rebased onto main (5a24959) to clear the merge conflict.

The conflict was with the new raw_usage snapshot work. It touched the same three places this PR does, and both sides are additive rather than competing, so both are kept:

• chatcmpl_stream_handler.py: _attach_raw_usage_snapshot under preserve_raw_usage, then the usage-less marker.
• any_llm_model.py: the same pairing on the Responses stream.
• run_loop.py: import only. The usage-less fallback merged cleanly and still sits next to the new raw_usage= argument on ModelResponse.

That work also makes the intent here more explicit than when I first wrote it. mark_request_completed_without_usage records only that a request happened, so when no provider payload arrives nothing is attached and raw_usage stays None, which is the behaviour you asked for.

Re-verified on the rebased branch against main at the same commit: 6373 passed, no new failures.

Thanks. Both done in 93ebe1e.

Renamed to internal helpers. _mark_request_completed_without_usage and _requests_for_response_without_usage, with imports and tests updated. Neither was exported from agents/__init__.py, so nothing was reachable as public API, but the underscore makes that explicit.

The automated review also caught a real gap in the same area, so it is fixed here. Span usage was populated only when the terminal response carried a usage payload, so a streamed run reported one request while its model span omitted the request entirely:

The OpenAI Chat Completions, LiteLLM and AnyLLM chat spans now fall back to a shared _span_usage_without_provider_totals(), so the two paths agree. Token totals stay at zero, since the provider reported none. Covered by test_streamed_span_records_the_request_when_provider_omits_usage, which fails on the previous commit.

@abhay-codes07 I won't review again unless all the codex review feedback are resolved.

ok I am trying my best to resolve it @seratch

All Codex threads on this PR are now addressed and resolved.

Span usage is recorded before the terminal event is yielded. It was being set after the stream loop, so a caller that consumes stream_response() directly and stops once it sees response.completed closes the generator at that yield, the loop never resumes, and the span was left with no usage or output even though the run counted the request. The OpenAI Chat Completions and LiteLLM streams now populate the span where the terminal response is captured, matching what the AnyLLM chat path already did.

Covered by test_stream_span_is_recorded_for_a_consumer_that_stops_at_the_terminal_event, which breaks out of the loop at the terminal event and then asserts the span. It fails on the previous commit.

The AnyLLM Responses path now records span usage at all. It never set span_response.span_data.usage, so with tracing on, the run result and the turn and task spans counted a request the model response span did not show. It now records usage the way OpenAIResponsesModel does, on both the streaming and non-streaming paths, which also makes the usage-less count visible there.

The remaining thread was the original "count usage-less streamed requests too" note, written against fee6f481 before the streaming fix landed in 0194e7a6; GitHub had re-anchored it to a newer commit.

typecheck is failing, so #4290 will take over the completion. Your contribution credit is included in the PR's commit.