Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Bedrock Opus 4.7 (us.anthropic.claude-opus-4-7) rejects requests with `temperature` field — causes silent run-dispatch hangs, no failover [2 pull requests, 2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#73663•Fetched 2026-04-29 06:16:45
View on GitHub
Comments
2
Participants
3
Timeline
5
Reactions
0
Author
bstanburybstanbury
Participants
bstanburybstanburyclawsweeper[bot]clawsweeper[bot]steipetesteipete
Timeline (top)
commented ×2cross-referenced ×2closed ×1

On OpenClaw 2026.4.25, chats routed to amazon-bedrock/us.anthropic.claude-opus-4-7 never complete. The chat.send is accepted, the session transitions to processing, and then nothing happens — no embedded run start, no LLM attempt logged, and no failover fires. The diagnostic watchdog eventually flags stuck session ... state=processing age=143s queueDepth=1. Meanwhile the same gateway can successfully call Opus 4.6 (via ARN) to completion in ~1.7s.

Root cause: Bedrock Converse returns an upstream validation error from Anthropic:

ValidationException: An error occurred (ValidationException) when calling the Converse operation:
The model returned the following errors:
{"type":"error","request_id":"req_...","error":{"type":"invalid_request_error",
 "message":"`temperature` is deprecated for this model."}}

OpenClaw's embedded agent runtime unconditionally sends temperature for every Bedrock Claude call. Opus 4.7 rejects it at the Anthropic-upstream layer, the Bedrock SDK surfaces a ValidationException, and OpenClaw's runtime does not classify it as a surfaceable error in a way the failover chain will move past — the run just hangs until a watchdog eventually kills it. The user-facing UX is total silence.

Error Message

ValidationException: An error occurred (ValidationException) when calling the Converse operation: The model returned the following errors: {"type":"error","request_id":"req_...","error":{"type":"invalid_request_error", "message":"temperature is deprecated for this model."}}

Root Cause

Root cause: Bedrock Converse returns an upstream validation error from Anthropic:

Fix Action

Workaround

Swap primary to Opus 4.6 via inference profile ARN; keep Opus 4.7 as a tertiary fallback in case upstream reverts.

"agents": {
  "defaults": {
    "model": {
      "primary": "amazon-bedrock/arn:aws:bedrock:us-west-2:<account>:inference-profile/us.anthropic.claude-opus-4-6",
      "fallbacks": [
        "amazon-bedrock/us.anthropic.claude-opus-4-7",
        "openai-codex/gpt-5.4"
      ]
    }
  }
}

Restart gateway. Chats work instantly.

PR fix notes

PR #73675: fix(bedrock): strip inferenceConfig.temperature for Opus 4.7 (#73663)

Description (problem / solution / changelog)

What

Fixes #73663 (Bug 1). Anthropic upstream rejects Bedrock Converse requests for the Opus 4.7 family with:

ValidationException: ... "temperature" is deprecated for this model.

OpenClaw's embedded agent runtime currently sends inferenceConfig.temperature for every Bedrock Claude call. The Bedrock SDK surfaces the nested upstream error as a ValidationException, which OpenClaw's failover classifier does not recognize as a surfaceable / failover-worthy error. The result: chats routed to amazon-bedrock/us.anthropic.claude-opus-4-7 (and the regional/global profile siblings) hang in state=processing until a diagnostic watchdog fires at ~140s. Sessions are effectively dead with no user-visible error and no failover to the configured fallback chain.

Reporter (@bstanbury) verified via direct boto3 probe that:

  • Bedrock routing is fine
  • Anthropic upstream is fine
  • Opus 4.6 accepts temperature
  • Opus 4.7 rejects temperature (upstream behavior, documented in invalid_request_error)

Fix

Strip payload.inferenceConfig.temperature for the Opus 4.7 family at the existing wrapStreamFn payload-patch boundary in extensions/amazon-bedrock/register.sync.runtime.ts. Mirrors the established Mantle-Anthropic check at extensions/amazon-bedrock-mantle/mantle-anthropic.runtime.ts:23:

function bedrockModelRejectsTemperature(modelId: string): boolean {
  return modelId.includes("claude-opus-4-7");
}

Applied across all three regional/global inference profile prefixes (anthropic.claude-opus-4-7, us.anthropic.claude-opus-4-7, global.anthropic.claude-opus-4-7) and on all three branches of the wrapped stream:

  1. No-cache-injection path (most non-app-profile Anthropic models)
  2. Cache-injection fast path (ARN heuristic match)
  3. Cache-injection slow path (opaque profile lookup via GetInferenceProfile)

Other inferenceConfig fields (maxTokens, etc) flow through unchanged. Opus 4.6 and earlier still send temperature.

Pre-implement audit

  1. Existing-helper check (vincentkoc #57341). Mantle-Anthropic's requiresDefaultSampling(modelId) at extensions/amazon-bedrock-mantle/mantle-anthropic.runtime.ts:23 is the same shape. Could not export-share across plugins because they live in separate extension boundaries; the new helper is module-local with the same one-line modelId.includes("claude-opus-4-7") body and a doc comment cross-referencing the mantle file. ✅
  2. Shared-helper caller check (steipete #60623). streamWithPayloadPatch is reused — same callback shape that already injects guardrails and cache points. No contract change for other callers. ✅
  3. Broader-fix rival scan (steipete #68270). Zero rival PRs reference #73663. Bug 2 (failover classifier should surface nested upstream errors inside ValidationException) is intentionally out of scope here — that is a separate fix in the failover state machine. ✅

Test changes

  • New test helper makeBedrockClaudeModel(modelId) (one-line, mirrors makeAppInferenceProfileDescriptor) so the Bedrock-Converse model descriptor is reusable.
  • New parameterized test pinning the strip across all three Opus 4.7 inference profile shapes — feeds payload.inferenceConfig.temperature and asserts the strip removes only temperature and leaves maxTokens intact.
  • New regression guard test for Opus 4.6 — confirms temperature survives so 4.6 callers are not affected.

Verified locally

npx oxlint extensions/amazon-bedrock/register.sync.runtime.ts extensions/amazon-bedrock/index.test.ts
# Found 0 warnings and 0 errors.

npx vitest run extensions/amazon-bedrock/index.test.ts
# Tests  26 passed (26)

lobster-biscuit: 73663-bedrock-opus-4-7-temperature

Sign-Off:

  • I have read and agree to the OpenClaw Contributor License Agreement.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/amazon-bedrock/index.test.ts (modified, +69/-0)
  • extensions/amazon-bedrock/register.sync.runtime.ts (modified, +46/-1)

PR #73689: fix(bedrock): strip inferenceConfig.temperature for Opus 4.7 (#73663)

Description (problem / solution / changelog)

What

Resubmits the fix for #73663 with all reviewer feedback from the closed PR #73675 already applied. The original PR was auto-closed by openclaw-barnacle for queue-cap reasons (>10 active hclsys PRs); the queue is now back at 10 and the closed-PR feedback is folded in.

Anthropic upstream rejects Bedrock Converse requests for the Opus 4.7 family with invalid_request_error: "temperature" is deprecated for this model.. The Bedrock SDK surfaces this as a ValidationException; OpenClaw's failover classifier does not currently surface the nested upstream error, so the embedded run hangs in state=processing until a watchdog fires at ~140s. Sessions are dead with no user-visible error and no failover.

Fix

Strip payload.inferenceConfig.temperature for the Opus 4.7 family at the existing wrapStreamFn payload-patch boundary in extensions/amazon-bedrock/register.sync.runtime.ts. Mirrors extensions/amazon-bedrock-mantle/mantle-anthropic.runtime.ts:23 (requiresDefaultSampling).

Now extracted as a module-level helper stripTemperatureFromInferenceConfig(payload) and reused at all three wrapStreamFn branches (no-cache, cache-injection-fast, cache-injection-slow). Helper guards against malformed inferenceConfig (string/number/null) so the in operator cannot throw TypeError and abort the streaming request.

function stripTemperatureFromInferenceConfig(payload: unknown): void {
  if (!payload || typeof payload !== "object") return;
  const inferenceConfig = (payload as { inferenceConfig?: unknown }).inferenceConfig;
  if (
    inferenceConfig &&
    typeof inferenceConfig === "object" &&
    "temperature" in inferenceConfig
  ) {
    delete (inferenceConfig as Record<string, unknown>).temperature;
  }
}

Closed-PR feedback applied

This branch was originally PR #73675 (auto-closed on queue cap before maintainer review). The aisle and greptile findings on that PR are now addressed:

  • aisle CWE-248 (Low) on #73675: TypeError/DoS risk from in operator on non-object inferenceConfig. Fixed by adding typeof inferenceConfig === "object" guard inside the helper. New regression test feeds inferenceConfig: "string" | null | 42 | undefined and asserts no throw.
  • greptile P2 (a): temperature-strip boilerplate duplicated across three branches. Fixed by extracting the helper and calling stripTemperatureFromInferenceConfig(payload) at each site.
  • greptile P2 (b): tests only exercised the no-cache-injection path. Fixed by adding a parameterized test for an Opus 4.7 application-inference-profile ARN that lands on the cache-injection fast path.

Pre-implement audit

  1. Existing-helper check (vincentkoc #57341). requiresDefaultSampling(modelId) already exists in mantle-anthropic.runtime.ts:23 for the same family. Cross-extension boundaries make a shared export awkward; the new helpers are module-local with cross-references in their doc comments. ✅
  2. Shared-helper caller check (steipete #60623). streamWithPayloadPatch is reused — same callback shape that already injects guardrails and cache points. No contract change for other callers. ✅
  3. Broader-fix rival scan (steipete #68270). Zero rival PRs reference #73663. Bug 2 (failover classifier surfacing nested upstream errors inside ValidationException) is intentionally out of scope here — that is a separate fix in the failover state machine. ✅

Verified locally

npx oxlint extensions/amazon-bedrock/register.sync.runtime.ts extensions/amazon-bedrock/index.test.ts
# Found 0 warnings and 0 errors.

npx vitest run extensions/amazon-bedrock/index.test.ts
# Tests  28 passed (28)

Tests cover:

  • Bare model IDs anthropic.claude-opus-4-7, us.anthropic.claude-opus-4-7, global.anthropic.claude-opus-4-7 (no-cache path)
  • Opus 4.7 application inference profile ARN (cache-injection fast path)
  • Opus 4.6 regression guard (temperature preserved)
  • Malformed inferenceConfig payloads (helper does not throw)

lobster-biscuit: 73663-bedrock-opus-4-7-temperature

Sign-Off:

  • I have read and agree to the OpenClaw Contributor License Agreement.

Closes #73675 (auto-closed for queue-cap reasons).

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/amazon-bedrock/index.test.ts (modified, +124/-0)
  • extensions/amazon-bedrock/register.sync.runtime.ts (modified, +52/-1)

Code Example

ValidationException: An error occurred (ValidationException) when calling the Converse operation:
The model returned the following errors:
{"type":"error","request_id":"req_...","error":{"type":"invalid_request_error",
 "message":"`temperature` is deprecated for this model."}}

---

import boto3
from botocore.config import Config

client = boto3.client(
    "bedrock-runtime",
    region_name="us-west-2",
    config=Config(connect_timeout=10, read_timeout=60, retries={"max_attempts": 1})
)

# Try WITH temperature — reproduces the failure
resp = client.converse(
    modelId="us.anthropic.claude-opus-4-7",
    messages=[{"role": "user", "content": [{"text": "reply with the single word PONG"}]}],
    inferenceConfig={"maxTokens": 10, "temperature": 0}
)

---

"agents": {
  "defaults": {
    "model": {
      "primary": "amazon-bedrock/arn:aws:bedrock:us-west-2:<account>:inference-profile/us.anthropic.claude-opus-4-6",
      "fallbacks": [
        "amazon-bedrock/us.anthropic.claude-opus-4-7",
        "openai-codex/gpt-5.4"
      ]
    }
  }
}
RAW_BUFFERClick to expand / collapse

Summary

On OpenClaw 2026.4.25, chats routed to amazon-bedrock/us.anthropic.claude-opus-4-7 never complete. The chat.send is accepted, the session transitions to processing, and then nothing happens — no embedded run start, no LLM attempt logged, and no failover fires. The diagnostic watchdog eventually flags stuck session ... state=processing age=143s queueDepth=1. Meanwhile the same gateway can successfully call Opus 4.6 (via ARN) to completion in ~1.7s.

Root cause: Bedrock Converse returns an upstream validation error from Anthropic:

ValidationException: An error occurred (ValidationException) when calling the Converse operation:
The model returned the following errors:
{"type":"error","request_id":"req_...","error":{"type":"invalid_request_error",
 "message":"`temperature` is deprecated for this model."}}

OpenClaw's embedded agent runtime unconditionally sends temperature for every Bedrock Claude call. Opus 4.7 rejects it at the Anthropic-upstream layer, the Bedrock SDK surfaces a ValidationException, and OpenClaw's runtime does not classify it as a surfaceable error in a way the failover chain will move past — the run just hangs until a watchdog eventually kills it. The user-facing UX is total silence.

Reproduction

  1. Configure primary model amazon-bedrock/us.anthropic.claude-opus-4-7 with any non-empty fallback chain (Opus 4.6, Codex, etc.).
  2. Ensure AWS credentials resolve (default profile, region us-west-2) and Bedrock is reachable.
  3. Send any chat message.
  4. Observe: [ws] chat.send logged, no embedded run start, no failover decision, eventually [diagnostic] stuck session ... state=processing age=143s queueDepth=1.

Proof that Bedrock + Opus 4.7 are reachable

Direct boto3 probe from the same gateway host (no AWS CLI installed — used the Python SDK):

import boto3
from botocore.config import Config

client = boto3.client(
    "bedrock-runtime",
    region_name="us-west-2",
    config=Config(connect_timeout=10, read_timeout=60, retries={"max_attempts": 1})
)

# Try WITH temperature — reproduces the failure
resp = client.converse(
    modelId="us.anthropic.claude-opus-4-7",
    messages=[{"role": "user", "content": [{"text": "reply with the single word PONG"}]}],
    inferenceConfig={"maxTokens": 10, "temperature": 0}
)

Result: ValidationException ... "temperature" is deprecated for this model. (0.5s).

Compare without temperature (not included in snippet — same call minus temperature): succeeds.

Compare Opus 4.6 with temperature via inference profile ARN: OK (1.7s) -> 'PONG'.

So:

  • Bedrock routing: ✅ fine
  • Anthropic upstream: ✅ fine
  • Opus 4.6 accepts temperature: ✅
  • Opus 4.7 rejects temperature: ❌ (upstream behavior, documented in invalid_request_error)

This is an upstream Anthropic model-policy change, not a Bedrock infrastructure issue.

Two separable bugs here

Bug 1 (primary): OpenClaw sends temperature to Opus 4.7 on the Bedrock path

The Bedrock Converse inferenceConfig should omit temperature for the Opus-4.7 family (us.anthropic.claude-opus-4-7, global.anthropic.claude-opus-4-7, anthropic.claude-opus-4-7).

Several options, in order of simplicity:

  1. Drop temperature entirely from Bedrock Converse payloads when the model id matches the Opus-4.7 pattern.
  2. Add a per-model omitTemperature: true flag in the Bedrock provider catalog, consulted by the payload builder.
  3. Bigger fix: a per-(provider, model) capability table that consulted at request build time, also useful for supportsAdaptiveThinking / reasoning_effort variants (see related issues below).

This mirrors what the GitHub Copilot path needed for output_config.effort on Opus 4.7 (see #69928 and #70322) — different parameter, same class of model-specific provider drift.

Bug 2 (hang / no failover): ValidationException with nested upstream error is not classified as a surface/failover-worthy error

Even before Bug 1 is fixed, the runtime should not silently hang. A ValidationException from Bedrock Converse that contains an Anthropic invalid_request_error body should:

  • be classified as a non-retryable schema error for this (provider, model),
  • immediately surface_error or candidate_failed in the fallover state machine,
  • log [agent/embedded] embedded run failover decision: ... reason=invalid_request from=amazon-bedrock/us.anthropic.claude-opus-4-7,
  • proceed to the next candidate in the fallback chain (Opus 4.6 → Codex).

Right now zero of that happens. The run is dispatched, something in the invocation path awaits a response that will never come, and the session stays in processing until a watchdog at ~120–140s fires a diagnostic. The rest of the pipeline is blissfully unaware.

Compare to the timeout path, which does failover correctly: earlier today we saw three clean failover decision: reason=timeout transitions off us.anthropic.claude-opus-4-6-v1 when Bedrock was slow — so the classifier just doesn't recognize invalid_request_error inside ValidationException as a failover trigger.

Impact

Severity: HIGH — every chat against Bedrock Opus 4.7 is effectively broken with no user-visible error, and no safe fallback behavior. A user has to either:

  • Manually demote Opus 4.7 from primary (what I did: swapped primary to the Opus 4.6 inference-profile ARN), or
  • Hit the watchdog timeout and see a generic error card with no useful message.

Anyone using Opus 4.7 as their primary on Bedrock right now is in one of these two states.

Workaround

Swap primary to Opus 4.6 via inference profile ARN; keep Opus 4.7 as a tertiary fallback in case upstream reverts.

"agents": {
  "defaults": {
    "model": {
      "primary": "amazon-bedrock/arn:aws:bedrock:us-west-2:<account>:inference-profile/us.anthropic.claude-opus-4-6",
      "fallbacks": [
        "amazon-bedrock/us.anthropic.claude-opus-4-7",
        "openai-codex/gpt-5.4"
      ]
    }
  }
}

Restart gateway. Chats work instantly.

Environment

  • OpenClaw: 2026.4.25 (aa36ee6)
  • Node: v22.22.0
  • OS: Ubuntu 25.10 on Mac mini 2012 (x86_64)
  • AWS region: us-west-2
  • Bedrock auth mode: aws-sdk (default profile credentials)
  • boto3 direct probe succeeds; OpenClaw path hangs

Related

  • #69928 — github-copilot + opus-4.7 output_config.effort rejected ([medium] only) — same class of "Opus 4.7 has narrower parameter acceptance than 4.6" bug on a different provider.
  • #70322 — github-copilot + opus-4.7 adaptive-thinking effort poisoning auth profile — similar classifier-doesn't-surface-the-error pattern.
  • #72540 — supportsAdaptiveThinking allowlist missing claude-opus-4-7 on the vertex-stream transport (already fixed for that transport, but the same per-model capability problem keeps appearing on other provider paths).
  • #71921 — Bedrock Claude models missing vision capability in registry — same "static model registry drifts from upstream capabilities" theme.

Suggested direction

Short term: either drop temperature for Opus-4.7-family model ids on the Bedrock Converse path, or special-case it in inferenceConfig construction. Either fixes the user-visible outage.

Longer term: the Bedrock (and Copilot, and vertex-stream) transports all keep re-discovering that Opus 4.7 has narrower acceptable-parameter surface than Opus 4.6. A shared per-(provider, model) capability table (omitTemperature, supportsAdaptiveThinking, supportedEffortValues, maxContextTokens, etc.) consulted at payload construction time would prevent the next round of the same class of bug.

Orthogonally: the failover classifier should recognize nested upstream invalid_request_error inside a ValidationException and surface_error + move to the next candidate, so a single parameter-shape drift at the upstream can never silently lock a user out.

Happy to test a fix on the affected host if needed.

extent analysis

TL;DR

To fix the issue, drop the temperature parameter from the inferenceConfig when calling the Bedrock Converse operation for Opus 4.7 models.

Guidance

  • Identify the model IDs that are affected by this issue, specifically the Opus 4.7 family (us.anthropic.claude-opus-4-7, global.anthropic.claude-opus-4-7, anthropic.claude-opus-4-7).
  • Modify the code to omit the temperature parameter from the inferenceConfig when calling the Bedrock Converse operation for these model IDs.
  • Consider implementing a per-model capability table to store parameters that are supported or omitted for each model, to prevent similar issues in the future.
  • Update the failover classifier to recognize nested upstream invalid_request_error inside a ValidationException and surface the error to move to the next candidate.

Example

if model_id in ["us.anthropic.claude-opus-4-7", "global.anthropic.claude-opus-4-7", "anthropic.claude-opus-4-7"]:
    inference_config = {"maxTokens": 10}  # omit temperature parameter
else:
    inference_config = {"maxTokens": 10, "temperature": 0}

Notes

The issue is caused by the Opus 4.7 model rejecting the temperature parameter, which is sent by the OpenClaw embedded agent runtime. The fix involves modifying the code to omit this parameter for Opus 4.7 models. Additionally, the failover classifier needs to be updated to handle nested upstream errors.

Recommendation

Apply the workaround by swapping the primary model to Opus 4.6 via inference profile ARN, and keep Opus 4.7 as a tertiary fallback. This will allow

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#retrieval issue#search optimization#API routing#API middleware#SSR setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Bedrock Opus 4.7 (us.anthropic.claude-opus-4-7) rejects requests with `temperature` field — causes silent run-dispatch hangs, no failover [2 pull requests, 2 comments, 3 participants]