[BUG]: Playground allows invalid temperature + top_p combination for all Claude 4.x models

[jash0803]

Where do you use Phoenix

Self-hosted

What version of Phoenix are you using?

12.34.0

What happened?

In the Phoenix Playground, all Claude 4.x models allow configuring both temperature and top_p simultaneously via the UI.

This results in a consistent runtime failure when executing the prompt:

invalid_request_error: 'temperature' and 'top_p' cannot both be specified for this model. Please use only one.

This is reproducible across every Claude 4.x variant, including:

• claude-opus-4-5
• claude-opus-4-5-20251101
• claude-sonnet-4-5
• claude-sonnet-4-5-20250929
• claude-haiku-4-5
• claude-haiku-4-5-20251001
• claude-opus-4-1
• claude-opus-4-1-20250805

What did you expect to happen?

The Playground UI should prevent invalid parameter combinations for Claude 4.x models by enforcing that only one of temperature or top_p is set.

Acceptable solutions would be:

• Disable one control when the other is set
• Automatically omit one parameter from the request
• Surface a UI validation error before execution

Why this is critical

This is a breaking change introduced when migrating from Claude 3.x to Claude 4.x, where:

• Claude 3.x allowed both parameters
• Claude 4.x explicitly rejects requests containing both

Because the Playground still exposes both controls without validation, every run fails by default unless the user manually discovers and fixes the issue.

Impact:

• Playground is effectively broken for all Claude 4.x models
• Blocks prompt iteration and experimentation
• Produces confusing errors that look like platform failures
• Affects new users and existing users migrating models

Additional information

[jash0803]

Official Documentation:
https://platform.claude.com/docs/en/about-claude/models/migration-guide#migrating-from-claude-4-1-or-earlier-to-claude-4-6

[dosubot]

The restriction that only one of temperature or top_p can be set for Claude 4.x models is confirmed in the official Anthropic migration guide (link). The current Playground UI behavior—allowing both parameters to be set—does not align with this requirement and leads to runtime errors.

There are several open issues and enhancement requests in the Phoenix repo tracking the need for better UI validation and parameter handling, including consistent exposure of core generation parameters, client-side validation, and the ability to unset or disable parameters (#11266, #9806, #7792, #6711). A recent backend fix ensures that None values for these parameters are not sent to the API (#10361), but UI-side validation to prevent invalid combinations is still needed.

The recommended approach, supported by both the documentation and ongoing repo discussions, is for the Playground UI to enforce this restriction by disabling one control when the other is set, omitting one parameter from the request, or surfacing a validation error before execution. This is a known issue and is being tracked for future improvements.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}