[weiqingy]

Linked issue: #1036

Purpose of change

Claude Opus 4.7+ and the Sonnet, Fable and Mythos 5 lines return HTTP 400 for a non-default temperature, top_p or top_k. The Anthropic integration defaults temperature to 0.1 and sent it on every request without checking the model, so picking one of those models turned every chat call into a provider error. Both languages had the defect.

All three parameters are now dropped on models that reject them, in both languages. Dropped rather than clamped: omitting the parameter is accepted everywhere, while substituting the provider default would quietly change sampling behaviour. Each drop is logged once per model and parameter.

Three paths could reach the wire, and all three are gated:

Path	Was
Java top-level temperature	sent unconditionally
Java additional_kwargs → top_p / top_k	sent unconditionally
Java additional_kwargs → temperature	no case label, so forwarded as a raw body property

Python gates the merged kwargs immediately above its single create call.

The model list is deliberately separate from the prefill and structured-output lists in this connection: the three boundaries do not coincide. Structured output starts at 4.5, prefill rejection at 4.6, sampling rejection at 4.7, so Claude 4.6 rejects a prefill while still accepting a temperature. A test pins that.

One behaviour change. A caller setting temperature both at the top level and in additional_kwargs now has the additional_kwargs value win. Previously both were emitted under the same key, producing {"temperature":0.1,"temperature":0.5}, which is undefined. Typed and raw routes serialize identically for a number, so accepting models see no change on the wire. The dropped-parameter warning names the value that was actually withheld: the two routes are resolved before the gate rather than reporting whichever was read first.

One bug fix beyond the 400. The warn-once bookkeeping was keyed on the model alone, so a second parameter dropped for an already-warned model was discarded silently. It is now keyed on model and parameter.

Tests

Java 90 in AnthropicChatModelConnectionTest, 92 in the module. Python 84 passed, 2 skipped. Spotless, Ruff and RAT clean.

Coverage was driven by mutation testing. Every mutant in scope dies in both languages: the guard removed per parameter, each parameter's routing removed, and the warn key reverted to model-only.

Worth knowing for future edits: an unrecognised key is forwarded as a raw body property, so asserting the typed accessor is empty does not prove a parameter was left off. The drop tests assert the raw body too.

Which value the warning names is pinned by passing both temperatures as a Number that records whether it was rendered, since the message is assembled with %s. stop_sequences is covered too, the last arm of the additional_kwargs switch that had no test.

Not covered: the LOG.warn call itself, and a rewrite that keeps the dedup helper but rebuilds the message at the call site and logs unconditionally. Both need a logging binding in a module that has none.

API

No public API change. temperature, top_p and top_k keep their names, types and defaults; only whether they reach the provider depends on the model. No change on models that accept sampling parameters, including the default claude-sonnet-4-20250514.

Documentation

• doc-needed
• doc-not-needed
• doc-included

chat_models.md: both temperature rows note the parameter is not sent on Claude 4.7+; the Java additional_kwargs row adds temperature and states the precedence. The Python additional_kwargs row was removed because that parameter does not exist in the Python setup.

Was this patch authored or co-authored using generative AI tooling?

• Yes
• No

Generated-by: Claude Code 2.1.234, 2.1.251 (Claude Opus 5)

[wenjin272]

Thanks for fixing this! When both the top-level temperature and additional_kwargs.temperature are set, the latter should take precedence. However, the warning is emitted for the top-level value first and may report the overridden value. Could we resolve the effective temperature before filtering/logging and add a test for this case?

[weiqingy]

Yes, good catch. The warning is owed once per model and parameter, so the top-level value claimed it first and named a temperature that was about to be overridden anyway.

Fixed in daa13b34. additional_kwargs is read before the gate now, and effectiveTemperature picks the winner, so the warning names the value the request would otherwise have carried. The temperature case in the switch stays, just empty: dropping the label would send the value through the default branch and onto the body raw.

The test was the awkward part. On a rejecting model neither value is sent, so the only place the choice shows up is the warning text, and the module has no logging binding. What I settled on was passing both temperatures as a Number that records whether toString() ran, since the warning is built with %s. The value that got rendered is the value that got named. Putting the old order back fails that test and nothing else.

There's also a parameterized test on effectiveTemperature for the cases where the top-level value still wins: no temperature key, or one holding a non-number.

[wenjin272]

LGTM

[weiqingy]

@wenjin272 Thanks for the review. Rebased onto main and pushed.