[Bug]: anthropic.rs has same temperature: f64 shape as Bedrock pre-#6144 — verify whether native Anthropic API rejects for opus-4-7

[JordanTheJet]

Affected component

provider

Severity

S2 - degraded behavior

Conservative — would escalate to S1 if confirmed, since it'd block opus-4-7 on the native Anthropic provider exactly the way #6095 blocked it on Bedrock. May also be a non-issue if Anthropic's native API is more permissive than Bedrock's Converse API.

Current behavior

Suspected — needs reproduction. PR #6144 (just merged as 5d31172) fixed crates/zeroclaw-providers/src/bedrock.rs where InferenceConfig.temperature: f64 was always serialized, causing a non-retryable Bedrock 400 (temperature is deprecated for this model) on claude-opus-4-7.

The Anthropic native provider has the structurally identical shape on master at the time of #6144 merge:

// crates/zeroclaw-providers/src/anthropic.rs:32
struct NativeChatRequest {
    ...
    temperature: f64,  // not Option, no skip_serializing_if
}

// crates/zeroclaw-providers/src/anthropic.rs:64 — second request struct, same shape

Both are reachable from chat_with_system (anthropic.rs:799) and chat (anthropic.rs:872) production paths via let temperature = temperature.unwrap_or(self.default_temperature()) followed by unconditional inclusion in the request body. There is no code path that can omit temperature for any model.

Unknown: whether the native Anthropic API (api.anthropic.com/v1/messages) actually rejects temperature for claude-opus-4-7 the way Bedrock does. Bedrock and the native API use different infrastructure and may not share the deprecation. Need a live repro to confirm.

Expected behavior

If the native Anthropic API also rejects temperature for claude-opus-4-7:

• Apply the same fix shape as fix(providers): omit Bedrock temperature for Opus 4.7 #6144: temperature: Option<f64> + #[serde(skip_serializing_if = "Option::is_none")] + a per-model predicate (anthropic_model_omits_temperature) that returns None for opus-4-7.

If the native API accepts temperature for claude-opus-4-7:

• Document the divergence between Bedrock and native (one rejects, one accepts) so future contributors don't get surprised.
• Close this issue as "not a bug, divergence documented".

Steps to reproduce

# 1. Build current master (post-#6144)
cargo build --release

# 2. Configure native Anthropic provider with opus-4-7
# ~/.zeroclaw/config.toml:
#   [providers.models.anthropic]
#   model = "claude-opus-4-7"
# Set ANTHROPIC_API_KEY in env.

# 3. Send any message
zeroclaw  # interactive mode, send "hi"

# 4. Observe whether the request 400s with "temperature is deprecated for this model"
#    or completes successfully.

If the request 400s with the temperature-deprecation message, this issue is confirmed at S1 and needs the same fix shape as #6144. If it completes, close as non-issue + add a comment to the divergence (Bedrock rejects, native accepts).

Impact

No response

Logs / stack traces

No response (pending repro)

ZeroClaw version

master post-#6144 (squash commit 5d31172)

Rust version

No response

Operating system

No response (any — bug is in serialization, OS-independent)

Regression?

Unknown

Additional context

• Surfaced during review of fix(providers): omit Bedrock temperature for Opus 4.7 #6144 (review id 4177643367) as a 🟡 follow-up.
• The PR body of fix(providers): omit Bedrock temperature for Opus 4.7 #6144 cited #6007 as parallel work for the Anthropic side, but #6007 does not resolve in the repo (gh pr view 6007 → "Could not resolve to a PullRequest"). No companion PR currently exists.
• Two paths forward (either is fine):
  1. Whoever has Anthropic API access runs the repro above and either confirms (→ open a fix PR mirroring fix(providers): omit Bedrock temperature for Opus 4.7 #6144) or refutes (→ close this issue, add divergence note).
  2. File a defensive PR matching fix(providers): omit Bedrock temperature for Opus 4.7 #6144's shape; the Option<f64> change is backward-compatible regardless of whether the predicate ever fires.

Pre-flight checks

• I reproduced this on the latest master branch or latest release.
• I redacted secrets, tokens, and personal data from all submitted content.

Note: first checkbox is technically inaccurate — this is a suspected-issue file, not a confirmed repro. Will edit with confirmed/refuted status once someone runs the repro.

[singlerider]

Doesn't #5960 address the Anthropic default temperature handling? It rewrote the whole way that works.

[Audacity88]

@singlerider I think #5960 addresses the defaulting layer, but not this narrower native-wire omission question.

#5960 changed the provider trait to pass temperature: Option<f64> and moved default selection into each provider. In current master, though, AnthropicProvider still unwraps that option before building NativeChatRequest, whose temperature field is still f64. So the current native Anthropic request paths still serialize either the configured value or AnthropicProvider::default_temperature(); they do not have a way to omit temperature from the payload.

That leaves the issue body’s repro question: does api.anthropic.com/v1/messages reject temperature for claude-opus-4-7 the same way Bedrock Converse did before #6144? If yes, we should mirror the #6144 omit-temperature shape here. If no, a short divergence comment in anthropic.rs would be enough and we can close this as not a bug.

I closed #6146 as a duplicate so this stays the canonical tracking thread.

[Audacity88]

@JordanTheJet Confirmed against the native Anthropic path:

zeroclaw agent -p anthropic --model claude-opus-4-7 -m "Reply exactly OK."

returns:

Anthropic API error (400 Bad Request): {"type":"error","error":{"type":"invalid_request_error","message":"temperature is deprecated for this model."}}

So this does need the #6144-style omission behavior for native Anthropic as well.