Using AWS Bedrock with Cursor (BYOK)

Bring Your Own Key (BYOK) lets you point Cursor at a model provider you already pay for instead of Cursor's built-in model routing. AWS Bedrock is one of the most common choices because it hosts Anthropic Claude and other frontier models behind an AWS account you already control. This guide walks through what BYOK is, why Bedrock specifically, how to configure it in Cursor, how billing and cost control work, and how to fix the errors you are most likely to hit, including the confusing "Invalid signature in thinking block is bound to a different conversation".

What Is BYOK and When to Use It

BYOK means you supply your own provider credentials, and the provider bills you directly for the tokens you consume. In Cursor, the model still runs through Cursor's interface and features, but the inference request goes to your account instead of Cursor's.

You generally want BYOK when:

• You already have committed cloud spend. If your organization has an AWS commitment or enterprise discount, routing model traffic through Bedrock uses that spend instead of adding a new line item.
• Compliance requires a specific boundary. Bedrock keeps data inside your AWS account and region, which simplifies data residency and security review.
• Procurement prefers one vendor. Buying through AWS is often easier than adding a separate AI vendor to a contract.

BYOK is not always cheaper. Cursor's included and usage-based pricing can beat Bedrock for small teams, and you take on quota management yourself. Choose BYOK for control and compliance, not just for the price.

BYOK is per model provider, not per chat

In Cursor you enable providers in Settings > Models. Once Bedrock is enabled and your credentials are saved, your selected Bedrock model IDs become selectable wherever you pick models. You are not locked into Bedrock for other models.

BYOK vs Cursor's Built-In Routing

It helps to see the two paths side by side before you commit.

Dimension	Cursor's built-in models	BYOK with Bedrock
Billing	Cursor charges you	AWS charges you directly
Credentials	Managed by Cursor	You supply and rotate AWS keys
Quota	Managed by Cursor	You manage per-model quotas
Compliance	Cursor's boundary	Your AWS account and region
Setup effort	Zero	IAM, model access, provider config
Model list	Cursor-curated	Whatever your region exposes

If you are a solo developer optimizing for speed, stay on built-in routing. If you are in an organization where the AWS bill, region, and IAM policy all need to be yours, BYOK is the right answer.

Why AWS Bedrock

Bedrock is a hosted inference layer, not a model itself. It exposes Anthropic Claude, Amazon Nova, Meta Llama, Mistral, and others through a single AWS API. That single API is the reason it is attractive for enterprise use.

• Compliance and governance. Requests and data stay within your AWS account and region, under your existing controls and audit logs.
• Existing AWS spend. Model usage shows up on your AWS bill and can be covered by existing commitments.
• Data residency. You choose the region, which matters when regulations require data to stay in a country.
• Enterprise procurement. AWS is already an approved vendor in most large organizations.

The trade-offs are the mirror image: you own the quota, the IAM setup, and the troubleshooting.

Prerequisites

Before configuring Cursor, get the following in place on the AWS side.

AWS Account and Model Access

You need an AWS account with billing enabled. In the Bedrock console, model access is opt-in per model, so you must explicitly request access to the Anthropic Claude models you intend to use. Some models are granted automatically; others require an acceptance step or a short use-case form.

IAM Permissions

Create an IAM user or role for Cursor with the narrowest permissions that still work. At minimum, Cursor needs to invoke models and list them.

IAM permission	Why Cursor needs it
bedrock:InvokeModel	Sends a non-streaming request to a model
bedrock:InvokeModelWithResponseStream	Sends a streaming request, which is what the chat UI uses
bedrock:ListFoundationModels	Populates the model picker and validates model IDs

For Claude models on Bedrock, you also usually need bedrock:InvokeModel scoped to the model ARNs or, more simply, to the region's inference profiles. Keep the policy scoped and avoid attaching broad admin policies.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CursorBedrockInvoke",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-5-v1:0",
        "arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-sonnet-4-5-v1:0"
      ]
    },
    {
      "Sid": "CursorBedrockList",
      "Effect": "Allow",
      "Action": "bedrock:ListFoundationModels",
      "Resource": "*"
    }
  ]
}

Attach this policy to a dedicated IAM user or role for Cursor rather than reusing an existing admin identity. If your organization uses short-lived credentials, assume a role and refresh the session token periodically instead of creating a static key.

Verify Access Before Configuring Cursor

Prove the credentials work from the command line first. If the call fails here, it will fail in Cursor too, and you will have saved yourself a confusing round trip.

# Confirm the configured identity is the one you expect
aws sts get-caller-identity

# List the models your region exposes
aws bedrock list-foundation-models \
  --region us-east-1 \
  --query "modelSummaries[?contains(modelId, 'anthropic')].[modelId]" \
  --output table

If listing works but invoking fails, the problem is model access or the specific model ID, not the credentials.

Region Choice

Pick a region where the model you want is available and where your data is allowed to live. Cross-region inference is supported for some models through an inference profile prefix, so you may not be limited to a single region.

Configuring Bedrock in Cursor

Cursor exposes BYOK providers in the Models settings. The flow is the same shape for every provider.

1. Open Cursor Settings > Models.
2. Find the AWS Bedrock provider and enable it.
3. Enter your AWS access key ID, secret access key, and the region.
4. Choose the model IDs you want visible in the picker.
5. Save and return to a chat, then select a Bedrock model.

Credential Fields

Cursor needs a region-qualified configuration. A Bedrock provider block looks roughly like this:

{
  "provider": "bedrock",
  "aws_access_key_id": "AKIAIOSFODNN7EXAMPLE",
  "aws_secret_access_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
  "aws_region": "us-east-1",
  "models": [
    "anthropic.claude-sonnet-4-5-v1:0",
    "anthropic.claude-3-5-haiku-v1:0"
  ]
}

Prefer the long-lived IAM access key as a last resort for a developer machine. For a team, use a temporary session or an assumed role so keys are not stored in plaintext on disk.

Model IDs and Cross-Region Inference

Bedrock model IDs follow a predictable shape: vendor, family, version. Some models require an inference profile prefix, which routes the request across regions for availability and throughput.

# Direct model IDs (region-scoped)
anthropic.claude-sonnet-4-5-v1:0
anthropic.claude-3-5-haiku-v1:0

# Cross-region inference profile IDs (note the region prefix)
us.anthropic.claude-sonnet-4-5-v1:0
eu.anthropic.claude-sonnet-4-5-v1:0
apac.anthropic.claude-sonnet-4-5-v1:0

If a model returns an access error even though you enabled it, the model ID is almost always the cause: check whether it needs the us. or eu. prefix for the region you selected.

Access keys are secrets

Do not paste access keys into a chat, a rule file, or a shared screenshot. Store them where Cursor stores provider credentials, and rotate any key that you suspect has been exposed. The example keys above are AWS's public documentation placeholders, not real credentials.

Verifying the Connection in Cursor

After saving the provider config, confirm the wiring with a trivial prompt rather than a real task, so a failure is unambiguous.

1. Open a new chat and select one of your Bedrock model IDs from the model picker.
2. Ask for something small, like "reply with the word ready".
3. If the response comes back, the credentials, region, and model ID are all correct.
4. If it fails, re-run the CLI invoke test below and compare the error text with what Cursor shows.

# Invoke the model directly so you can see the raw error text
aws bedrock-runtime invoke-model \
  --model-id anthropic.claude-sonnet-4-5-v1:0 \
  --region us-east-1 \
  --body '{"anthropic_version":"bedrock-2023-05-31","max_tokens":16,"messages":[{"role":"user","content":"reply with the word ready"}]}' \
  --cli-binary-format raw-in-base64-out \
  /tmp/out.json && cat /tmp/out.json

Keeping a working CLI command for each model you use turns Cursor's error messages from ambiguous into decodable, because you already know what a successful invoke looks like.

Billing and Cost Control

With BYOK, AWS bills you for the tokens, not Cursor. That changes how you budget and monitor.

Model Pricing

Bedrock charges per input and output token, and the rate depends on the model. Input tokens are generally cheaper than output tokens, and long-context models cost more per token than small ones.

Model family	Relative input cost	Relative output cost	Notes
Claude Sonnet class	Medium	Medium	Strong general coding default
Claude Haiku class	Low	Low	Fast, cheap, good for small edits
Claude Opus class	High	High	Best reasoning, highest cost
Amazon Nova	Low	Low	Cost-effective alternatives

Cost Allocation and Monitoring

Tag your Bedrock usage so it is attributable, and watch the metrics rather than the invoice.

# Enable cost allocation tags on the resources that call Bedrock
aws resourcegroupstaggingapi tag-resources \
  --resource-arn-list arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-sonnet-4-5-v1:0 \
  --tags Project=cursor-byok Team=platform

In CloudWatch, track the Bedrock invocation metrics and set a billing alarm so a runaway agent does not quietly spend your monthly budget overnight.

# Quick cost sanity check: list recent Bedrock usage with Cost Explorer
aws ce get-cost-and-usage \
  --time-period Start=2026-10-01,End=2026-10-20 \
  --granularity DAILY \
  --metrics BlendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Bedrock"]}}'

Reducing Token Cost

BYOK puts the token meter in your hands, so a few habits pay off quickly:

• Right-size the model. Use a Haiku-class model for small edits and reserve the Opus-class model for genuinely hard reasoning.
• Keep context tight. A bloated context window is the largest hidden cost; start a new chat when the thread drifts.
• Batch small edits. Several tiny prompts cost more than one well-scoped prompt that covers the same changes.
• Trim the rules. Every always-applied rule is tokens sent on every request, so keep .cursor/rules lean.
• Watch the first week. Review Cost Explorer daily for the first week, then weekly, so you learn your real baseline before it surprises you.

Fixing the "Invalid signature in thinking block" Error

This is the most confusing Bedrock error in Cursor because it sounds like an API key problem but is almost always a conversation-state problem. The full message reads:

Invalid `signature` in `thinking` block is bound to a different conversation

Root Cause

Claude's extended thinking produces encrypted reasoning blocks that carry a signature bound to the exact conversation and turn they were created in. When those blocks are replayed into a new request, the signed content no longer matches and the provider rejects the whole request. This happens when:

• an extended-thinking block from an earlier turn is resent in a later turn,
• a proxy or gateway caches and replays the request body,
• conversation state is stale or duplicated, for example after switching models mid-thread.

Fixes

Work through these in order:

1. Start a new chat. The signature is bound to the conversation, so a fresh chat is the reliable reset.
2. Disable extended thinking for the model while you debug, then re-enable once the flow is clean.
3. Update Cursor. Signature handling for thinking blocks has been fixed in newer builds; an out-of-date client is a common cause.
4. Remove intermediate proxies or gateways that might cache or rewrite request bodies between Cursor and Bedrock.
5. Lower the temperature and shorten the thread so fewer thinking blocks accumulate in context.

Fresh chat first, everything else second

Ninety percent of the time, starting a new chat resolves the signature error immediately. If it reproduces in a brand-new chat, then look at proxies and client version.

Throttling and resource_exhausted Errors

Bedrock applies per-account, per-model throughput quotas. When you exceed them you get a throttling or resource_exhausted error rather than a clean failure.

ResourceNotFoundException / ServiceQuotaExceededException:
You have exceeded the rate of requests allowed for this model.

This is a quota problem, not a credentials problem. Two fixes:

• Spread load across models or regions. Cross-region inference profiles exist precisely to pool capacity.
• Request a quota increase in the AWS Service Quotas console for the Bedrock model you are using.

# List the Bedrock service quotas you can request increases for
aws service-quotas list-service-quotas \
  --service-code bedrock \
  --query "Quotas[?contains(QuotaName, 'Claude')].[QuotaName,QuotaCode,Value]" \
  --output table

The error usually clears on its own once burst traffic subsides, but if it is chronic, the quota request is the fix.

Access, Region, and Proxy Errors

Access Denied When Model Access Is Not Granted

AccessDeniedException: You don't have access to the model with the specified model ID

Two causes dominate here:

• Model access was never granted in the Bedrock console. Open the console and request access to that specific Anthropic model.
• The IAM policy is too narrow or the model ID is wrong. Confirm the policy grants bedrock:InvokeModelWithResponseStream and that the model ID string matches a model you actually enabled.

Wrong Region

If Cursor's configured region does not host the model, or the model ID needs a cross-region prefix, requests fail even though the key is valid. Confirm the region in Cursor matches the region in the console where you enabled model access.

Streaming Failures Behind Corporate Proxies

Streaming is the default for chat. Corporate proxies and TLS-inspecting firewalls often break text/event-stream responses, which shows up as a chat that hangs or returns a partial answer.

• Whitelist the Bedrock regional endpoints (for example bedrock-runtime.us-east-1.amazonaws.com).
• Make sure the proxy does not buffer streamed responses; look for a "streaming" or "chunked transfer" setting.
• If the proxy is unavoidable, confirm whether Cursor can bypass it for the Bedrock host.

Troubleshooting Quick Reference

Symptom	Likely cause	Fix
Invalid signature in thinking block	Thinking blocks replayed across conversations	Start a new chat, disable extended thinking, update Cursor
resource_exhausted / throttling	Per-model quota exceeded	Spread across regions, request quota increase
AccessDeniedException	Model access not granted or policy too narrow	Enable model in console, widen IAM policy
Model not found / no access in one region	Wrong region or missing inference profile prefix	Match region, use us. / eu. prefix
Chat hangs with no stream output	Proxy buffering text/event-stream	Whitelist Bedrock endpoints, disable proxy buffering
Model picker empty	bedrock:ListFoundationModels missing	Add the permission, re-save credentials
Auth error after key rotation	Stale credentials saved in Cursor	Re-enter the access key and secret in Models settings
Works locally, fails in CI	Region or profile not passed in the pipeline	Set the region and profile in the CI environment

Once the flow is stable, keep a short note of your region, model IDs, and quota limits next to the provider config. When an error appears six months later, that note turns a two-hour investigation into a two-minute fix.