[Bug]: Invalid model identifier for Claude Opus 4.6 via Bedrock

[territov]

Bug Description

When using Forge with the Bedrock provider, selecting Claude Sonnet 4.5 works correctly. However, selecting Claude Opus 4.6 fails with:

ERROR: ValidationException: The provided model identifier is invalid.

The model identifier being sent is anthropic.claude-opus-4-6-v1:0, but the correct Bedrock model ID is anthropic.claude-opus-4-6-v1 (without the :0 suffix).

Steps to Reproduce

1. Configure Forge to use the Bedrock provider
2. Set the model to Claude Opus 4.6
3. Attempt any prompt

Expected Behavior

Request succeeds using model ID anthropic.claude-opus-4-6-v1

Actual Behavior

Request fails with ValidationException because the :0 suffix is appended to the model ID

Error Logs

Forge Version

2.1.0

Operating System

macOS

OS Version

MacOS Tahoe 26.2

AI Provider

None

Model

claude-opus-4.6

Installation Method

Other

Configuration

I installed forge via `curl -fsSL https://forgecode.dev/cli | sh`

[territov]

After fixing the model identifier issue, via ~/forge/.config.json, requests to Claude Opus 4.6 via Bedrock fail on the second turn with:

ERROR: ValidationException: The model returned the following errors:
messages.1.content.1.thinking.signature: Field required

This indicates that when Forge replays conversation history, it's not including the required signature field in thinking content blocks. The Anthropic API requires this field to be preserved and sent back in subsequent turns.

This only affects models with extended thinking enabled (e.g., Claude Opus 4.6).

[majiayu000]

Hi, I've been looking into this and traced the root cause.

Proposed approach: Find the Bedrock model ID mapping/construction code in the Rust codebase (likely in a provider or model config module). Fix the mapping so Claude Opus 4.6 uses 'anthropic.claude-opus-4-6-v1' without the ':0' suffix. The ':0' suffix pattern likely comes from a generic version suffix applied to all Bedrock model IDs — need to either add an exception for Opus 4.6 or fix the suffix logic. Focus only on the model ID bug (not the secondary signature field issue mentioned in comments).

I'll open a draft PR shortly. Happy to adjust based on your preference.

[amitksingh1490]

Hi, I've been looking into this and traced the root cause.

Proposed approach: Find the Bedrock model ID mapping/construction code in the Rust codebase (likely in a provider or model config module). Fix the mapping so Claude Opus 4.6 uses 'anthropic.claude-opus-4-6-v1' without the ':0' suffix. The ':0' suffix pattern likely comes from a generic version suffix applied to all Bedrock model IDs — need to either add an exception for Opus 4.6 or fix the suffix logic. Focus only on the model ID bug (not the secondary signature field issue mentioned in comments).

I'll open a draft PR shortly. Happy to adjust based on your preference.

you can just update the modelid in provider.json

[amitksingh1490]

After fixing the model identifier issue, via ~/forge/.config.json, requests to Claude Opus 4.6 via Bedrock fail on the second turn with:

ERROR: ValidationException: The model returned the following errors:
messages.1.content.1.thinking.signature: Field required

This indicates that when Forge replays conversation history, it's not including the required signature field in thinking content blocks. The Anthropic API requires this field to be preserved and sent back in subsequent turns.

This only affects models with extended thinking enabled (e.g., Claude Opus 4.6).

can you tell me the version this is happening? can you check on lastest main. I have fixed it in #2710

[amitksingh1490]

After fixing the model identifier issue, via ~/forge/.config.json, requests to Claude Opus 4.6 via Bedrock fail on the second turn with:

ERROR: ValidationException: The model returned the following errors:
messages.1.content.1.thinking.signature: Field required

This indicates that when Forge replays conversation history, it's not including the required signature field in thinking content blocks. The Anthropic API requires this field to be preserved and sent back in subsequent turns.
This only affects models with extended thinking enabled (e.g., Claude Opus 4.6).

can you tell me the version this is happening? can you check on lastest main. I have fixed it in #2710

I tested this, its a bug I am fixing it.
Fixed in #2729