[BUG] Opus 4.7 doesn't work with bedrock

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/43010
2. https://github.com/anthropics/claude-code/issues/30926
3. https://github.com/anthropics/claude-code/issues/49219

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Root cause analysis

I dug into this and found the precise cause. TL;DR: **Claude Code sends anthropic_beta in the request body when talking to Bedrock, but Bedrock only accepts it as the anthropic-beta HTTP header.** Bedrock returns 400 "invalid beta flag" for anything it sees in the body.

Evidence

With ANTHROPIC_LOG=debug on Claude Code 2.1.111 pointed at Bedrock (us.anthropic.claude-opus-4-7), the outbound request looks like:

POST https://bedrock-runtime.us-east-1.amazonaws.com/model/us.anthropic.claude-opus-4-7/invoke-with-response-stream

headers:
  anthropic-beta: claude-code-20250219,effort-2025-11-24
  anthropic-version: 2023-06-01
  authorization: Bearer <AWS_BEARER_TOKEN_BEDROCK>
  ...

body:
  {
    "anthropic_version": "bedrock-2023-05-31",
    "anthropic_beta": ["interleaved-thinking-2025-05-14", "tool-search-tool-2025-10-19"],
    "messages": [...],
    "tools": [...],
    "thinking": {...},
    ...
  }

Bedrock rejects this with 400 "invalid beta flag".

Minimal repro against Bedrock directly (no Claude Code)

import requests

KEY = "<AWS_BEARER_TOKEN_BEDROCK>"
URL = "https://bedrock-runtime.us-east-1.amazonaws.com/model/us.anthropic.claude-opus-4-7/invoke"
H = {"Authorization": f"Bearer {KEY}", "Content-Type": "application/json"}

# ✗ Fails (body.anthropic_beta) — this is what Claude Code sends
r = requests.post(URL, headers=H, json={
    "anthropic_version": "bedrock-2023-05-31",
    "max_tokens": 16,
    "messages": [{"role": "user", "content": "hi"}],
    "anthropic_beta": ["interleaved-thinking-2025-05-14"],
})
print(r.status_code, r.text)
# 400  {"message":"{\"type\":\"error\",\"error\":{\"type\":\"invalid_request_error\",\"message\":\"invalid beta flag\"}}"}

# ✓ Works — same flag, moved to header
r = requests.post(URL, headers={**H, "anthropic-beta": "interleaved-thinking-2025-05-14"}, json={
    "anthropic_version": "bedrock-2023-05-31",
    "max_tokens": 16,
    "messages": [{"role": "user", "content": "hi"}],
})
print(r.status_code)  # 200

I also tested every individual beta flag Claude Code uses (interleaved-thinking-2025-05-14, tool-search-tool-2025-10-19, effort-2025-11-24, etc.) in the anthropic-beta header — all of them are accepted by Bedrock on us.anthropic.claude-opus-4-7. The problem is purely the placement (body vs. header).

Why Opus 4.6 works but Opus 4.7 doesn't

Looking at the minified source (search for opus-4-7), Claude Code appears to route Opus 4 calls through client.beta.messages.create and adds interleaved-thinking-2025-05-14 + (for 4.7) extra flags like tool-search-tool-2025-10-19 and effort-2025-11-24. The SDK path for client.beta.messages.create serializes betas into body.anthropic_beta instead of the anthropic-beta header when the target is Bedrock. Opus 4.6 historically accepted (or didn't receive) the specific flags that now fail on 4.7, so the bug only surfaces now.

Why CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 does not fully fix it

That flag removes some header-level experimental betas (e.g. tool-search-tool-2025-10-19), but interleaved-thinking-2025-05-14 is still emitted in body.anthropic_beta and still gets rejected. Related: #22893.

Suggested fix

In the Bedrock transport, after constructing the JSON body:

if (body.anthropic_beta?.length) {
  const betas = Array.isArray(body.anthropic_beta)
    ? body.anthropic_beta.join(",")
    : String(body.anthropic_beta);
  headers["anthropic-beta"] = [headers["anthropic-beta"], betas]
    .filter(Boolean)
    .join(",");
  delete body.anthropic_beta;
}

This mirrors what the first-party Anthropic API does server-side (accepting both shapes) and what Bedrock requires (header only).

Workaround for anyone blocked today

A ~100 line local HTTP shim that moves body.anthropic_beta → anthropic-beta header and forwards to bedrock-runtime.<region>.amazonaws.com makes Claude Code 2.1.111 + Opus 4.7 work end-to-end. Point Claude Code at it with ANTHROPIC_BEDROCK_BASE_URL=http://127.0.0.1:8765. Happy to share the script if useful.

Environment

• Claude Code 2.1.111
• macOS 26.2 arm64, Node v22.22.2
• Bedrock us-east-1, model us.anthropic.claude-opus-4-7 (also repro'd on global.anthropic.claude-opus-4-7)
• Auth: AWS_BEARER_TOKEN_BEDROCK

doing this worked:

# Claude Code + Bedrock Opus 4.7: Beta Flag Fix

Claude Code 2.1.111 sends `anthropic_beta` flags that Bedrock's Opus 4.7 endpoint rejects with `invalid beta flag`. This guide fixes it.

## Problem

Bedrock Opus 4.7 rejects ALL beta flags — even an empty `anthropic_beta: []` array causes a 400 error. The field must be completely absent from the request body. Claude Code injects betas through two paths:

1. **SDK `betas:` parameter** → converted to `anthropic-beta` header → copied to `body.anthropic_beta` by the Bedrock adapter
2. **`St()` extra body function** → sets `anthropic_beta` directly in the request body for bedrock-specific betas

## Prerequisites

- Claude Code 2.1.111 (`claude --version` to check)
- Binary location: run `readlink -f $(which claude)` to find it

## Step 1: Settings

Edit `~/.claude/settings.json` and add/merge these into the `env` block:

```json
{
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "ENABLE_TOOL_SEARCH": "false",
    "CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS": "1",
    "CLAUDE_CODE_SIMULATE_PROXY_USAGE": "1"
  },
  "model": "us.anthropic.claude-opus-4-7"
}

Key env vars:

• ENABLE_TOOL_SEARCH=false — prevents a separate defer_loading: Extra inputs are not permitted error
• CLAUDE_CODE_SIMULATE_PROXY_USAGE=1 — built-in flag that strips the betas: SDK parameter from API requests (handles injection path 1)
• CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 — reduces beta count (not sufficient alone)

Step 2: Binary Patch

SIMULATE_PROXY_USAGE only blocks path 1. Path 2 (the St() function) still injects anthropic_beta directly into the request body. We fix this with a 2-byte binary patch.

What we're changing

The function St() in the bundled code has this logic:

if(H&&H.length>0)
  // ...sets q.anthropic_beta = H

We change > to < so the condition is never true (H.length<0 is always false for arrays):

if(H&&H.length<0)
  // ...never executes

Find the patch offsets

BINARY=$(readlink -f $(which claude))

# Back up first
cp "$BINARY" "${BINARY}.backup"

# Find the St() function — look for the CLAUDE_CODE_EXTRA_BODY string
grep -boa "CLAUDE_CODE_EXTRA_BODY" "$BINARY"

You'll see ~5 offsets. The ones that matter are the first two that appear in actual code (not binary data sections). To identify them, check context around each:

# For each offset from grep, check if it's inside the St() function:
dd if="$BINARY" bs=1 skip=<OFFSET-100> count=250 2>/dev/null | cat -v | tr -d '\0'

Look for output containing:

}if(H&&H.length>0)if(q.anthropic_beta&&Array.isArray(q.anthropic_beta

Apply the patch

Once you find the two code copies of St(), locate the > in H&&H.length>0 and change it to <.

Automated method (for 2.1.111 specifically — offsets may differ on other versions):

BINARY=$(readlink -f $(which claude))
cp "$BINARY" "${BINARY}.backup"

# Find exact offsets of St()'s "H&&H.length>0" pattern
# Search near CLAUDE_CODE_EXTRA_BODY for the pattern
python3 << 'PYEOF'
import sys

binary_path = sys.argv[1] if len(sys.argv) > 1 else ""
if not binary_path:
    # Find binary
    import subprocess
    binary_path = subprocess.check_output(
        ["readlink", "-f", subprocess.check_output(["which", "claude"]).decode().strip()]
    ).decode().strip()

with open(binary_path, "rb") as f:
    data = f.read()

# Find CLAUDE_CODE_EXTRA_BODY occurrences
marker = b"CLAUDE_CODE_EXTRA_BODY"
target = b"H&&H.length>0)if(q.anthropic_beta"
patch_offsets = []

pos = 0
while True:
    idx = data.find(marker, pos)
    if idx == -1:
        break
    # Search nearby (within 400 bytes after) for the target pattern
    region_start = idx
    region_end = min(idx + 400, len(data))
    region = data[region_start:region_end]
    target_pos = region.find(target)
    if target_pos != -1:
        # The '>' is at offset 11 within "H&&H.length>0"
        abs_offset = region_start + target_pos + 11
        patch_offsets.append(abs_offset)
        print(f"Found St() at offset {abs_offset} (near EXTRA_BODY at {idx})")
    pos = idx + 1

if not patch_offsets:
    print("ERROR: Could not find St() function pattern. Binary may be a different version.")
    sys.exit(1)

print(f"\nFound {len(patch_offsets)} patch location(s)")
for offset in patch_offsets:
    assert data[offset:offset+1] == b">", f"Expected '>' at offset {offset}, got {data[offset:offset+1]}"

# Apply patches
with open(binary_path, "r+b") as f:
    for offset in patch_offsets:
        f.seek(offset)
        f.write(b"<")
        print(f"Patched offset {offset}: '>' -> '<'")

print("\nDone. Verify with: claude --version")
PYEOF

Manual method (if Python script doesn't work)

BINARY=$(readlink -f $(which claude))

# Find the byte offsets
grep -boa 'H&&H.length>0)if(q.anthropic_beta' "$BINARY"
# Note the offset(s) — add 11 to each to get the '>' position

# Verify before patching (should output 0x3e which is '>')
dd if="$BINARY" bs=1 skip=<OFFSET+11> count=1 2>/dev/null | xxd -p

# Patch each occurrence
printf '<' | dd of="$BINARY" bs=1 seek=<OFFSET+11> count=1 conv=notrunc 2>/dev/null

# Verify after patching (should output 0x3c which is '<')
dd if="$BINARY" bs=1 skip=<OFFSET+11> count=1 2>/dev/null | xxd -p

Step 3: Test

Exit any running Claude Code sessions, then:

claude

It should connect to Opus 4.7 without the invalid beta flag error.

Reverting

BINARY=$(readlink -f $(which claude))
cp "${BINARY}.backup" "$BINARY"

Remove CLAUDE_CODE_SIMULATE_PROXY_USAGE from ~/.claude/settings.json.

Note: If Claude Code is running, the binary is locked. Either stop all sessions first, or copy the backup to a new name and update the symlink:

cp "${BINARY}.backup" "${BINARY}.reverted"
ln -sf "${BINARY}.reverted" $(which claude)

Known Trade-offs

• CLAUDE_CODE_SIMULATE_PROXY_USAGE also strips the context-hint beta body. This is a minor feature loss — context hints help with prompt caching optimization but aren't required for functionality.
• The St() patch prevents any CLAUDE_CODE_EXTRA_BODY env var from adding anthropic_beta. If you don't use that env var (most people don't), this has zero impact.

Why other approaches don't work

| Approach | Result |
|----------|--------|
| CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 alone | Reduces beta count but doesn't remove all |
| SIMULATE_PROXY_USAGE alone | Blocks SDK betas path but not the St() extra body path |
| Binary patch alone (without env var) | Too many code paths to patch — betas flow through SDK headers, extra body, and duplicate code copies |
| Renaming anthropic_beta → anthropic_betX | Bedrock rejects unknown fields too: "Extra inputs are not permitted" |

[!CAUTION] Please don't use either of those two slop comments suggesting binary patches or shims, lol.

E: Now fixed.

Caution Please don't use either of those two slop comments suggesting binary patches or shims, lol.

i assume in this case you have a fix? or is your plan to wait?, ah your based in uk. you should go comply with gdpr

It's monkey patch, yes, but at least a solution

A quick fix without patching the binary:

CLAUDE_CODE_EXTRA_BODY='{"thinking":{"type":"adaptive"}}' claude hello

A quick fix without patching the binary: CLAUDE_CODE_EXTRA_BODY='{"thinking":{"type":"adaptive"}}' claude hello

@Menci yeah nice find! but we should keep in mind this would _probably_ break once they ship a proper fix/update right? 🙃

@guicheffer It won't break once they ship a proper fix/update. A proper fix/update will exactly adds these to the request body. But it's always better to remove the workaround once it's not necessary.

A quick fix without patching the binary: CLAUDE_CODE_EXTRA_BODY='{"thinking":{"type":"adaptive"}}' claude hello

didn't work due to :

● Menci's thinking is that setting thinking in the body somehow prevents the beta flags. But that's not how the code works. Here's the St()    
  function:                                                                                                                                    
                                                                                                                                               
  function St(H) {                           // H = ["interleaved-thinking-...", ...] (beta flags array)
    let $ = process.env.CLAUDE_CODE_EXTRA_BODY;                                                                                                
    let q = {};                                                                                                                                
    if ($) q = {...JSON.parse($)};           // q = {"thinking":{"type":"adaptive"}}
                                                                                                                                               
    if (H && H.length > 0)                   // H has 20+ betas, so TRUE                                                                       
      if (q.anthropic_beta && Array.isArray(q.anthropic_beta))                                                                                 
        q.anthropic_beta = [...q.anthropic_beta, ...H];                                                                                        
      else                                                                                                                                     
        q.anthropic_beta = H;               // ← this runs. q.thinking doesn't prevent it                                                      
                                                                                                                                               
    return q;  // {"thinking":{"type":"adaptive"}, "anthropic_beta":["interleaved-thinking-...", ...]}                                         
  }                                                                                                                                            
                                                                                                                                               
  The thinking key and anthropic_beta key are completely independent fields in the object. Setting one has zero effect on the other. The       
  function always adds anthropic_beta as long as H (the betas array) has items — which it always does.
                                                                                                                                               
  And that's only one of the two injection paths. The other path (SDK betas: parameter → anthropic-beta header → copied to body.anthropic_beta 
  by the Bedrock adapter) is completely untouched by CLAUDE_CODE_EXTRA_BODY.

+1 - also affected on macOS arm64, Bedrock us-west-1, Claude Code 2.1.111. The CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 workaround does not fix it.

+1

Seeing this as well

Sorry folks, Opus 4.7 on the bedrock-runtime endpoint is broken right now. We're working with AWS to fix this.

It is still available on the bedrock-mantle endpoint. Temporary workaround: follow these steps to switch claude code to the mantle endpoint.

Confirmed the workaround works. Ensure you also unset CLAUDE_CODE_USE_BEDROCK or it will attempt to use Bedrock native.

Sorry folks, Opus 4.7 on the bedrock-runtime endpoint is broken right now. We're working with AWS to fix this. It is still available on the bedrock-mantle endpoint. Temporary workaround: follow these steps to switch claude code to the mantle endpoint.

I could select the model, but it doesn't respond, stuck in a retry loop of 10 attempts and then fails

You need to assure CreateInference policy is attached to your IAM role etc. if you are using role based.

You can have both bedrock and mantle set at the same time (/status will say it is using both). The key is just that the mantle model name is different. You need to manually do this instead of using the picker:
/model anthropic.claude-opus-4-7

my complete setting for the workaround:

"env": {
    "CLAUDE_CODE_USE_MANTLE": "1",
    "AWS_REGION": "us-east-1",
 ...
    },
 "model": "anthropic.claude-opus-4-7",

you can check "https://bedrock-mantle.<region>.api.aws/v1/models" to see supported mantle models in your account.

@brenden I know you all are probably scrambling around right now and I appreciate the note in here!

I did want to say though that in-app messaging would have been super helpful, since a few people at our company (and I'm sure many more out there) burned time thinking it was a permission issue and/or trying various fixes. I've seen a note on launch about Haiku being down, there's box listing a few new features after an upgrade, etc. Some small note on startup saying that Opus 4.7 isn't working on Bedrock would have saved a lot of time. If the system isn't general enough to do that right now, definitely is something to consider adding in the future!

@ShawnFumo that's a neat idea--we should have a better way of announcing these outages (cc @ant-kurt)

OK AWS has found the issue and is deploying a fix now. ETA for the fix is 1PM PDT.

@brenden Any further udpdates?

We had to use both env vars:

export CLAUDE_CODE_SIMULATE_PROXY_USAGE=1
// "thinking" and "interleaved_thinking" will break it 
export ANTHROPIC_DEFAULT_OPUS_MODEL_SUPPORTED_CAPABILITIES='effort,xhigh_effort,max_effort,adaptive_thinking'

Also, adding [1m] break it too. e.g.

ANTHROPIC_DEFAULT_OPUS_MODEL='us.anthropic.claude-opus-4-7[1m]'

I can confirm that I am still affected by this issue.

Claude Code 2.1.112
macOS 26.3.1(a) arm64
Bedrock us-east-1, model us.anthropic.claude-opus-4-7
Auth: AWS_BEARER_TOKEN_BEDROCK

Claude Code 2.1.112 can connect to generic opus-4.7 model but still can't connect via inference profiles. I confirmed the inference profile is fine by using the AWS CLI

<img width="2544" height="934" alt="Image" src="https://github.com/user-attachments/assets/2d182f62-3429-4683-b991-6c55db5feb56" />

Sorry, the deployment to fix this is delayed. New ETA is 4PM PDT

OK the deployment has finished and O4.7 should be working on bedrock-runtime now.

OK the deployment has finished and O4.7 should be working on bedrock-runtime now.

Is this a backend fix or do we need a new Claude Code version e.g. 2.1.113 which doesn't seem to be present yet.

Still getting same error on Claude Code 2.1.112

❯ /model global.anthropic.claude-opus-4-7
  ⎿  API error: 400 {"type":"error","request_id":"req_****...","error":{"type":"invalid_request_error","message":"invalid beta flag"}}

Working on my machine ™️ thanks for the push and fix here folks!

I am getting now transient errors, 50% to 70%:

API Error: 400 {"type":"error","request_id":"req_rqfeb***,"error":{"type":"invalid_request_error","message":"invalid beta flag"}}

@udo-hf Can you try /model us.anthropic.claude-opus-4-7?

I am still getting the same invalid beta flag error with 2.1.112 version (us-east-1).

@udo-hf Can you try /model us.anthropic.claude-opus-4-7?

I tried both us. and global. prefix, getting same error. AWS_REGION is us-east-2

I fixed it with

"CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1",
"CLAUDE_CODE_DISABLE_THINKING": "1",
in settings.json.

@brenden Don't have us available in my region, so I have to use global. Hitting ap-southeast-2. Still getting the invalid beta flag response.

I just had a successful test w/ Claude Code + "us.anthropic.claude-opus-4-7" without making any changes.

Still getting error in us-east-2, using global endpoint as well as us. one. Although working in us-east-1.

Works for me. (Intermittent behavior? Perhaps deployment is in progress??)

% export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1     
% export CLAUDE_CODE_DISABLE_THINKING=1
% claude
▗ ▗   ▖ ▖  Claude Code v2.1.112
           Opus 4.7 · API Usage Billing  
  ▘▘ ▝▝    ~/

❯ hello                                                                                                                    
        
⏺ Hello! How can I help you today?                                                                                         
                                                                                                                         
❯ /model us.anthropic.claude-opus-4-7                                                                                      
  ⎿  Set model to Opus 4.7                                                                                                 
                                                                                                                           
❯ hello                                                                                                                    
                                                                                                                           
⏺ Hello! How can I help?    

API Error: 400
{"type":"error","request_id":"req_XXXXXX","error":{"type":"invalid_request_error","message":"\"thinking.type.enabled\" is not supported for this model. Use \"thinking.type.adaptive\" and \"output_config.effort\" to control thinking behavior."}}

Using application inference profiles in AWS Bedrock us-west-2.

Ah sorry, I shared bad info earlier. The current state: fix for us-east-1 should be fully rolled out, and the fix for us-west-2 is almost fully rolled out. We expect the fixes for other regions to be deployed by around 8PM PDT. Will keep this thread updated with what I hear from AWS.

so AWS_REGION = us-east-1 & model id = us.anthropic.claude-opus-4-7? Confirmed worked

"env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_REGION": "us-east-1",
  },
  "model": "us.anthropic.claude-opus-4-7",

This works with 2.1.112 now!

The stable releases 2.1.85 and 2.1.97 still need export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 ; export CLAUDE_CODE_DISABLE_THINKING=1

Any plans to get it to work on prior CC releases without having to set those two variables?

us.anthropic.claude-opus-4-7 is now working in eu-west-2, but no luck with eu.enthropic.claude-opus-4-7!

I'm still seeing errors in us-west-2 using Application Inference Profiles in us-west-2:

API Error: 400
{"type":"error","request_id":"req_XXXXXX","error":{"type":"invalid_request_error","message":"\"thinking.type.enabled\" is not supported for this model. Use \"thinking.type.adaptive\" and \"output_config.effort\" to control thinking behavior."}}

The only thing that works is to disable thinking (CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1; CLAUDE_CODE_DISABLE_THINKING=1) but doesn't that defeat the benefits of Opus 4.7?

It works on us-east-1 and us-east-2 but not works on ap-northeast-1.
Apart from this, it doesn't work for thinking mode. However, I think the thinking mode is the necessary feature for me

For me, I had several things going on in settings.json:

In env, MAX_THINKING_TOKENS set to 8192
In the main body of the settings, "alwaysThinkingEnabled": true

Removing MAX_THINKING_TOKENS, setting "alwaysThinkingEnabled": false, and ADDING an "effort": "high" to settings.json worked the magic. Now with 2.1.112, I can use my Opus 4.7 Application Inferencing Profile ARN with claude code perfectly (as ANTHROPIC_DEFAULT_OPUS_MODEL set to the ARN).

Un-doing any one of those 3 changes seems to bork it with API 400 errors.

Fix has now been deployed to all AWS regions. The invalid beta flag error should be gone.

Fix has now been deployed to all AWS regions. The invalid beta flag error should be gone.

But "thinking.type.enabled" is not supported for this model is still there.

Hi getting "permission_error" "message":"anthropic.claude-opus-4-7 is not available for this account. You can explore other available models on Amazon Bedrock. For additional access options, contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/"}}.

When using Opus 4.7 via bedrock api despite it being listed as an available model

But "thinking.type.enabled" is not supported for this model is still there.

The AWS deployment has been resolved. This is a CC bug now. working on a hotfix to address this one.

Hi getting "permission_error" "message":"anthropic.claude-opus-4-7 is not available for this account. You can explore other available models on Amazon Bedrock. For additional access options, contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/"}}. When using Opus 4.7 via bedrock api despite it being listed as an available model

Also getting this issue.

Get it in the playground too, even though we have model access per the catalog.

Hi getting "permission_error" "message":"anthropic.claude-opus-4-7 is not available for this account. You can explore other available models on Amazon Bedrock. For additional access options, contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/"}}. When using Opus 4.7 via bedrock api despite it being listed as an available model

Same, I cannot get it enabled, do we really need to talk to the sales team? Wonder how long that's gonna take to get it resolved.

I'm not sure why the symptoms vary from person to person, but the issue persists for me using the Bedrock application inference profile and Claude Code 2.1.112.

Oddly enough, it is working ok on a macOS machine running Claude Code 2.1.92(homebrew version).

I'm not sure why the symptoms vary from person to person, but the issue persists for me using the Bedrock application inference profile and Claude Code 2.1.112. Oddly enough, it is working ok on a macOS machine running Claude Code 2.1.92(homebrew version).

We are trying to call the 4.7 model via Cursor by model id and its failing.

Adding a detailed report to help diagnose the permission_error variant of this issue. Several commenters above are experiencing the same symptom; this may help confirm it's a systemic issue rather than account-specific misconfiguration.

Environment

• AWS Account: child account under an AWS Organization (SSO Administrator role)
• Region: us-east-1
• IAM effective permissions: AmazonBedrockFullAccess (bedrock:* on *) on top of SSO AdministratorAccess — no IAM-layer restrictions possible

Error (reproducible)

aws bedrock-runtime converse \
  --model-id "global.anthropic.claude-opus-4-7" \
  --messages '[{"role":"user","content":[{"text":"ping"}]}]' \
  --inference-config '{"maxTokens":20}' \
  --region us-east-1

Response:

{
  "type": "error",
  "error": {
    "type": "permission_error",
    "message": "anthropic.claude-opus-4-7 is not available for this account. You can explore other available models on Amazon Bedrock. For additional access options, contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/"
  }
}

The same error occurs via both global.anthropic.claude-opus-4-7 and us.anthropic.claude-opus-4-7.

Note: this is the AWS CLI reproducing the issue directly, not through Claude Code. The same error surfaces from any Bedrock runtime client. So while filed under claude-code, the root cause appears to be AWS Bedrock / Anthropic-side model access.

Happy to share specific request_id values privately via a support case if it helps AWS/Anthropic engineers trace the exact requests.

Pre-conditions that look correct

Every check I can run from the CLI returns a green light:

1. Foundation Model is ACTIVE

``
aws bedrock get-foundation-model --model-identifier anthropic.claude-opus-4-7
→ modelLifecycle.status: ACTIVE
→ inferenceTypesSupported: ["INFERENCE_PROFILE"]
``

1. Inference Profiles are ACTIVE (both global. and us. variants, Type: SYSTEM_DEFINED)

1. Marketplace Agreement is ACTIVE

• agreementType: PurchaseAgreement
• status: ACTIVE
• Product type: SaaSProduct
• Agreement became ACTIVE ~10 hours before this comment

1. FTU form submitted

aws bedrock get-use-case-for-model-access --region us-east-1 returns a populated formData blob (company details, industry, intended use case).

1. Quota is pre-allocated

• L-5DB28B7B (Cross-region TPM for Opus 4.7): 15,000,000
• L-34152C1D (Global cross-region TPM for Opus 4.7): 15,000,000

1. Claude Opus 4.6 works perfectly from the same account/role/region

Same invocation pattern, same IAM identity, same region — 4.6 succeeds, 4.7 fails with permission_error. This rules out any credential / permission / networking issue on the user side.

What's different about 4.7

The list-foundation-model-agreement-offers response uses a new service code prefix AFS1 for pricing dimensions:

AFS1_input_tokens_global_standard       : $5
AFS1_output_tokens_global_standard      : $25
AFS1_cache_read_tokens_global_standard  : $0.5
AFS1_cache_write_tokens_global_standard : $6.25

Opus 4.6's pricing dimensions use a different service code format. This could indicate a new billing/reconciliation path for Opus 4.7 that isn't yet fully wired up on the Bedrock InvokeModel authorization check.

Time elapsed

Agreement became ACTIVE approximately 10 hours before filing this comment. This is well beyond any reasonable "propagation lag" window AWS typically documents (usually up to 15 minutes).

Cross-reference with other reports in this thread

Multiple users report the same exact error text in this thread:

• permission_error with the "contact AWS Sales" verbiage
• Happens even when model access is shown as available in the catalog
• Happens in both direct invocation and the Bedrock playground

Ask

Could AWS / Anthropic please confirm:

1. Is this a known rollout / reconciliation issue on the Bedrock side that will self-resolve, analogous to how the invalid beta flag fix was progressively rolled out? Is there an ETA or a status page we should watch?

1. Is the "contact AWS Sales" instruction in the error message actually actionable for usage-based on-demand invocations, or a misleading default response? The pricing model for Opus 4.7 is clearly usage-based (AFS1 rate card above), so a Sales engagement seems unnecessary for on-demand use.

1. Is there any user-side action remaining? So far:

• Agreement: accepted ✓
• FTU: submitted ✓
• IAM: bedrock:* ✓
• Quota: pre-allocated ✓
• ...with no apparent next step on our end.

Happy to provide additional diagnostic info (request IDs, exact timestamps, etc.) via a support case or private channel if that helps. Thanks for your attention.

I actually got a reply from the support team and the policy seems to have changed with the release of opus 4.7. Here's a snippet of the response I got:

To help you with the request I have reached out to the service team, and they have informed me that unfortunately they are unable to process this increase for Claude Opus 4.7 Bedrock at this time. But however, you shall be able to use other Bedrock service on your account. My apologies for any inconvenience this has caused. Further, the team has stated that this AWS account is relatively new and the overall usage is limited, due to which they couldn't approve and process this limit increase request. These limits are put in place to help you gradually ramp up activity and avoid large bills due to sudden, unexpected spikes.

I actually got a reply from the support team and the policy seems to have changed with the release of opus 4.7. Here's a snippet of the response I got: > To help you with the request I have reached out to the service team, and they have informed me that unfortunately they are unable to process this increase for Claude Opus 4.7 Bedrock at this time. But however, you shall be able to use other Bedrock service on your account. > My apologies for any inconvenience this has caused. > Further, the team has stated that this AWS account is relatively new and the overall usage is limited, due to which they couldn't approve and process this limit increase request. These limits are put in place to help you gradually ramp up activity and avoid large bills due to sudden, unexpected spikes.

Pretty sure they're just spouting some BS stuff. It's already activated and quotas are fine if you check it

Adding a detailed report to help diagnose the permission_error variant of this issue. Several commenters above are experiencing the same symptom; this may help confirm it's a systemic issue rather than account-specific misconfiguration. ## Environment AWS Account: child account under an AWS Organization (SSO Administrator role) Region: us-east-1 IAM effective permissions: AmazonBedrockFullAccess (bedrock:* on *) on top of SSO AdministratorAccess — no IAM-layer restrictions possible ## Error (reproducible) aws bedrock-runtime converse \ --model-id "global.anthropic.claude-opus-4-7" \ --messages '[{"role":"user","content":[{"text":"ping"}]}]' \ --inference-config '{"maxTokens":20}' \ --region us-east-1 Response: { "type": "error", "error": { "type": "permission_error", "message": "anthropic.claude-opus-4-7 is not available for this account. You can explore other available models on Amazon Bedrock. For additional access options, contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/" } } The same error occurs via both global.anthropic.claude-opus-4-7 and us.anthropic.claude-opus-4-7. Note: this is the AWS CLI reproducing the issue directly, not through Claude Code. The same error surfaces from any Bedrock runtime client. So while filed under claude-code, the root cause appears to be AWS Bedrock / Anthropic-side model access. Happy to share specific request_id values privately via a support case if it helps AWS/Anthropic engineers trace the exact requests. ## Pre-conditions that look correct Every check I can run from the CLI returns a green light: 1. Foundation Model is ACTIVE `` aws bedrock get-foundation-model --model-identifier anthropic.claude-opus-4-7 → modelLifecycle.status: ACTIVE → inferenceTypesSupported: ["INFERENCE_PROFILE"] ` 2. **Inference Profiles are ACTIVE** (both global. and us. variants, Type: SYSTEM_DEFINED) 3. **Marketplace Agreement is ACTIVE** * agreementType: PurchaseAgreement * status: ACTIVE * Product type: SaaSProduct * Agreement became ACTIVE ~10 hours before this comment 4. **FTU form submitted** aws bedrock get-use-case-for-model-access --region us-east-1 returns a populated formData blob (company details, industry, intended use case). 5. **Quota is pre-allocated** * L-5DB28B7B (Cross-region TPM for Opus 4.7): 15,000,000 * L-34152C1D (Global cross-region TPM for Opus 4.7): 15,000,000 6. **Claude Opus 4.6 works perfectly from the same account/role/region** Same invocation pattern, same IAM identity, same region — 4.6 succeeds, 4.7 fails with permission_error. This rules out any credential / permission / networking issue on the user side. ## What's different about 4.7 The list-foundation-model-agreement-offers response uses a new service code prefix AFS1 for pricing dimensions: ` AFS1_input_tokens_global_standard : $5 AFS1_output_tokens_global_standard : $25 AFS1_cache_read_tokens_global_standard : $0.5 AFS1_cache_write_tokens_global_standard : $6.25 ` Opus 4.6's pricing dimensions use a different service code format. This could indicate a new billing/reconciliation path for Opus 4.7 that isn't yet fully wired up on the Bedrock InvokeModel authorization check. ## Time elapsed Agreement became ACTIVE approximately **10 hours** before filing this comment. This is well beyond any reasonable "propagation lag" window AWS typically documents (usually up to 15 minutes). ## Cross-reference with other reports in this thread Multiple users report the same exact error text in this thread: * permission_error with the "contact AWS Sales" verbiage * Happens even when model access is shown as available in the catalog * Happens in both direct invocation and the Bedrock playground ## Ask Could AWS / Anthropic please confirm: 1. Is this a **known rollout / reconciliation issue** on the Bedrock side that will self-resolve, analogous to how the invalid beta flag fix was progressively rolled out? Is there an ETA or a status page we should watch? 2. Is the **"contact AWS Sales"** instruction in the error message actually actionable for usage-based on-demand invocations, or a **misleading default response**? The pricing model for Opus 4.7 is clearly usage-based (AFS1 rate card above), so a Sales engagement seems unnecessary for on-demand use. 3. Is there any **user-side action** remaining? So far: * Agreement: accepted ✓ * FTU: submitted ✓ * IAM: bedrock:` ✓ Quota: pre-allocated ✓ ...with no apparent next step on our end. Happy to provide additional diagnostic info (request IDs, exact timestamps, etc.) via a support case or private channel if that helps. Thanks for your attention.

This is actually very well detailed thank you. I hope we get an official response from them. Btw, does this happen to everyone when using playground or api?

Thanks @caliburn420 🙏

Just tested: Bedrock Playground returns the exact same permission_error as the CLI. So it's happening on both API/CLI and the console-based playground — completely client-agnostic. The gate is per-AWS-account on the server side, likely independent of Claude Code itself.

On the "relatively new / usage limited" rationale: we filed a support case and proactively added evidence that our account is actively using Claude Opus 4.6 in production with prior quota-increase approvals. Will share back whatever reply we get; hoping for a less hand-wavy explanation than the one posted above.

I'm getting a different error from the invalid beta flag one — still happening after the fix was deployed.

Error:

{"type":"permission_error","message":"anthropic.claude-opus-4-7 is not available for this account. You can explore other available models on Amazon Bedrock. For additional access options, contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/"}

What I've tried:

• Accepted AWS Marketplace offer for Claude Opus 4.7 (agreement confirmed via email)
• Created foundation model agreement via CLI (create-foundation-model-agreement — succeeded)
• Deleted and recreated the agreement — same error
• get-foundation-model-availability returns AUTHORIZED + AVAILABLE
• Tested in Bedrock Playground, CLI, both us-east-1 and us-west-2 — same error everywhere
• Opus 4.6 works perfectly fine on the same account
• FTU (First Time Use) form was submitted previously
• Full IAM permissions in place (InvokeModel, marketplace, agreement management)

Environment:

• Claude Code on Windows (using Bedrock provider)

The error format is Anthropic's JSON, not an AWS error — so it seems like Anthropic's backend entitlement system isn't recognizing the marketplace subscription for Opus 4.7 specifically.

@brenden
— could this be a separate backend issue from the beta flag one?

I'm getting it on an enterprise account (Fortune 500).

Do we need to start another issue? Seems like many people have this problem

+1 on the 'permission_error', 'anthropic.claude-opus-4-7 is not available for this account'. Our 4.6 config works perfectly. We're unsure what path to take to resolve the issue. So, we're stuck.

The permission_error is an AWS problem. It means that access to Opus 4.7 hasn't been enabled on your AWS account yet. According to Amazon, you need to contact AWS Sales to get access.

Summarizing:

• invalid beta flag - fix has been deployed to all AWS regions, you should no longer be seeing this
• \"thinking.type.enabled\" is not supported for this model - we're pushing a change in 2.1.113 that should help with this in cases where the AWS credentials are able to read the application inference profile's metadata. Otherwise, you may need to set ANTHROPIC_DEFAULT_OPUS_MODEL_SUPPORTED_CAPABILITIES=effort,xhigh_effort,max_effort,thinking,adaptive_thinking,interleaved_thinking. See https://code.claude.com/docs/en/model-config#customize-pinned-model-display-and-capabilities
• anthropic.claude-opus-4-7 is not available for this account - Contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/

Just to confirm, is access to Opus 4.7 on Bedrock now gated behind AWS Sales approval for accounts?

Weird I still think it's an error on AWS' part, like I think support is just giving out generic responses, have anyone who requested access get them, and why do some accounts have them by default, even new ones.

Just to confirm, is access to Opus 4.7 on Bedrock now gated behind AWS Sales approval for accounts?

@ant-kurt - sorry, but that's absolutely not an answer: "anthropic.claude-opus-4-7 is not available for this account - Contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/"

I received an email from AWS yesterday saying I have access to Opus 4.7: "You have subscribed to the following product in AWS Marketplace: * Claude Opus 4.7 (Amazon Bedrock Edition) sold by Anthropic, PBC." But I'm running into the same issue as everyone else here about contacting sales.

@ant-kurt - sorry, but that's absolutely not an answer: "anthropic.claude-opus-4-7 is not available for this account - Contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/"

absoloutly - feels like were second class.

Soo what now?

Still following up with the AWS team to get more information.

Here is the latest form the AWS team:

Due to an issue in our subscription flow, some accounts incorrectly received access to Claude Opus 4.7 before account eligibility was fully confirmed.

If you are still seeing this error, you may explore other available models on Amazon Bedrock, or contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/ for additional access options

Will keep you updated as we learn more.

The service quota for opus 4.7 has tokens per minute but not requests per minute. I'm guessing access is being with held for the time being.

still not working, anything related to this: https://forum.cursor.com/t/opus-4-7-not-functioning-on-bedrock-because-of-temperature-deprecation-400/158212/11

I've filed an updated bug report here: https://github.com/anthropics/claude-code/issues/51183

This bug was closed without adequate coverage.

I've filed an updated bug report here: #51183 This bug was closed without adequate coverage.

It's because it's not a bug, it's a feature. Availability of Opus 4.7 is gated with approval now. Probably because the quotas are much higher by default.

<img width="2140" height="703" alt="Image" src="https://github.com/user-attachments/assets/818f1d21-f980-4aa3-a38f-df68b6157ce3" />

Addendum: Quotas and Entitlements Confirmed

All AWS-side checks pass — the block is on Anthropic's runtime layer.

Service Quotas (non-zero, healthy)

aws service-quotas list-service-quotas --service-code bedrock --region us-east-1 \
  --query "Quotas[?contains(QuotaName, 'Opus') && contains(QuotaName, '4.7')]"

Quota                                                                                                                              Value
Cross-region model inference tokens/min for Anthropic Claude Opus 4.7                   15,000,000
Global cross-region model inference tokens/min for Anthropic Claude Opus 4.7        15,000,000

Entitlement Status

aws bedrock get-foundation-model-availability --model-id anthropic.claude-opus-4-7 --region us-east-1

Fielld                                Value
agreementAvailability	AVAILABLE
authorizationStatus	        AUTHORIZED
entitlementAvailability	AVAILABLE
regionAvailability	        AVAILABLE

Inference Profiles

aws bedrock list-inference-profiles --region us-east-1 \
  --query "inferenceProfileSummaries[?contains(inferenceProfileId, 'opus-4-7')].{id:inferenceProfileId, status:status}"

Profile ID                                          Status
us.anthropic.claude-opus-4-7         ACTIVE
global.anthropic.claude-opus-4-7  ACTIVE

Summary

Every AWS control plane check confirms this account is authorized and provisioned for Opus 4.7. The permission_error is originating from Anthropic's runtime behind Bedrock, not from AWS IAM, entitlements, or quotas.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.