Decide whether `openai_unsupported_model_settings` should warn on drop, as `AnthropicModel` does

[dsfaccini]

This issue was posted by Claude Code using claude-fable-5-1 on behalf of David.

The problem

openai_unsupported_model_settings drops settings silently. AnthropicModel warns when it drops the same kind of setting. Pick one.

• pydantic_ai_slim/pydantic_ai/models/openai.py — _drop_unsupported_params pops every named setting, no warning.
• pydantic_ai_slim/pydantic_ai/models/anthropic.py — AnthropicModel._drop_unsupported_sampling_settings pops, then warnings.warn(... 'These settings will be ignored.', UserWarning).

Three profiles name settings today, so three sets of users get the silence:

profile	dropped
providers/cerebras.py	logit_bias
profiles/openai_codex.py — openai_codex_model_profile	max_tokens, temperature, top_p
providers/github_copilot.py — _github_copilot_overlay (Claude ids)	temperature, top_p

A user who sets temperature on an OpenAI Codex model gets no signal that it never reached the wire.

Gotcha for whoever picks this up

tests/models/test_model_settings_support.py::test_supported_by_lists_match_the_wire probes each setting one at a time and the suite runs under filterwarnings = ["error"] (pyproject.toml). Adding the warning makes that probe raise instead of building a request, and the case fails with sent no request while probing logit_bias / max_tokens. That is exactly how commit 7a9a7cf8f0 on #8059 reddened all 26 test shards (run 34266627473); the change was reverted there. The probe has to learn to expect the warning as part of the fix.

Direction

Either warn like AnthropicModel does, or document the silence on the openai_unsupported_model_settings docstring in pydantic_ai_slim/pydantic_ai/profiles/openai.py. Note that pydantic_ai_slim/pydantic_ai/models/AGENTS.md currently tells adapters to ignore unsupported generic tuning settings silently and document them, which argues for the second — so the parity call is a real one, not a bug fix.

Background

Surfaced while reviewing a bot commit on #8059 (GitHubCopilotProvider), which added the warning inside that PR. Reverted there: making _drop_unsupported_params warn moves observable behavior for Cerebras and OpenAI Codex users, which is outside a Copilot provider PR's scope.

[dsfaccini]

This comment was posted by Claude Code using claude-fable-5-1 on behalf of David.

Whoever resolves this should also fix the docstring line on the function itself, since the caller set is part of the decision here — _drop_unsupported_params in pydantic_ai_slim/pydantic_ai/models/openai.py still says:

    Used currently only by Cerebras

That is already false on main: pydantic_ai_slim/pydantic_ai/profiles/openai_codex.py — openai_codex_model_profile sets openai_unsupported_model_settings, alongside pydantic_ai_slim/pydantic_ai/providers/cerebras.py, and #8059 adds a third in pydantic_ai_slim/pydantic_ai/providers/github_copilot.py — _github_copilot_overlay, for Claude ids.

One distinction worth keeping in the replacement wording: only Cerebras and Copilot reach this function (GitHubCopilotModel is an OpenAIChatModel), while the Codex profile's setting is consumed on the Responses side, by OpenAIResponsesModel._build_responses_request_params reading the same profile field directly.

[rscholz98]

Hey @dsfaccini happy to pick this up. It is close to #7791 / #7961, which I already worked on.

Do you want _drop_unsupported_params to warn like AnthropicModel, or should the silence stay and get documented on the openai_unsupported_model_settings docstring? Either way I will adjust test_supported_by_lists_match_the_wire to expect the warning per profile so we don't repeat [7a9a7cf8f0](https://github.com/pydantic/pydantic-ai/commit/7a9a7cf8f0).

Just say which direction and assign me and I can open a PR.