fix(models): report Responses-only settings dropped by Chat Completions

[ConnorMoss02]

Closes #4837

Summary

ModelSettings.truncation, response_include and context_management are read only by OpenAIResponsesModel. OpenAIChatCompletionsModel never reads them, so setting one on a Chat Completions model did nothing and said nothing.

Setting	openai_responses.py	openai_chatcompletions.py
truncation	:1012	none
response_include	:958-959	none
context_management	:1026	none

The one truncation match in openai_chatcompletions.py is raise_on_length_truncation at :494, which is a different thing.

Approach

The file already reports two other Responses-only features rather than dropping them, _handle_unsupported_prompt and _handle_unsupported_reasoning_settings. This adds a third handler in the same shape, called from the same place as the reasoning one:

• raise UserError when strict_feature_validation is on
• otherwise log once, guarded by _has_warned_unsupported_response_settings
• return immediately when none of the three are set, so a caller who does not use them is unaffected

No public API change, and nothing about request construction changes.

Tests

tests/models/test_openai_chatcompletions.py, mirroring the existing reasoning-settings pair:

• warns once across two calls and names all three settings
• raises UserError under strict validation
• stays silent when the settings are unset

Confirmed load-bearing: with openai_chatcompletions.py reverted, the first two fail.

Validation

uv run pytest tests/models/          # 863 passed
uv run mypy src/agents/models/openai_chatcompletions.py   # clean
uv run ruff check && uv run ruff format --check

uv run mypy src reports the same 46 pre-existing errors in extensions/sandbox/ and voice/ before and after this change; none are in the touched file.

[sylvesterkaczmarek]

The single _has_warned_unsupported_response_settings flag suppresses newly introduced unsupported settings too. If the first call only uses truncation and a later call adds context_management, that later setting is silently dropped. Please track which setting names have been warned and add a staggered-settings regression.

[ConnorMoss02]

Reproduced it:

call 1: ModelSettings(truncation="auto")
  → WARN … does not support `truncation` …

call 2: ModelSettings(truncation="auto", context_management=[…])
  → (nothing)

context_management had never been warned about and was dropped in silence.

Fixed in a58dabf by tracking the setting names already warned about instead of a single flag. Now:

call 1: truncation                        → warns `truncation`
call 2: truncation + context_management   → warns `context_management` only
call 3: truncation                        → silent

Only the newly introduced setting is named, so a repeated setting does not become recurring noise. Strict mode is unchanged and still raises on the full set.

Added test_chat_completions_warns_for_a_response_setting_added_on_a_later_call, which walks those three calls and asserts the third logs nothing. Confirmed load-bearing: it fails with the source change reverted.

864 tests pass. mypy clean on the file, ruff check and format clean.

One thing worth flagging separately: _handle_unsupported_reasoning_settings has the same single-flag shape, so reasoning.mode on a first call suppresses a later call that adds reasoning.context. I verified it behaves that way today. I have left it alone to keep this PR scoped, but happy to send it as its own change if you want it.