,

Claude Fable 5.1 Bedrock Tutorial: Setup to First Call

Illustration: Claude Fable 5.1 on Bedrock — setup to first API call

This Claude Fable 5.1 Bedrock tutorial takes you from a cold AWS account to a working Converse API call with the correct data retention mode configured — no hand-waving, no “and then magic happens.” By the end you’ll have requested model access, made a real call, explicitly set aws_review retention, and verified it actually took effect against AWS’s own launch documentation. Grab a terminal and let’s go.

Prerequisites

  • An AWS account with permissions to request Bedrock model access (or an admin who can grant it).
  • AWS CLI v2 installed and configured (aws configure) with credentials for the account/region where Bedrock is available.
  • Python 3.10+ with boto3 installed (pip install boto3) if you’re following the SDK steps.
  • An IAM user or role with bedrock:* permissions scoped appropriately for a dev/test environment — tighten this before production.
  • Roughly 20 minutes.

Steps

  1. Request Bedrock access to Claude Fable 5.1. Model access in Bedrock is opt-in per model, per account, per region. Open the Bedrock console, go to Model access, and request access to anthropic.claude-fable-5-1-v1:0. You can also do this from the CLI:

    aws bedrock list-foundation-models \
      --by-provider anthropic \
      --query "modelSummaries[?contains(modelId, 'fable-5-1')]"
    

    Because Claude Fable 5.1 is a Covered Model, approval may take longer than a standard model grant while Anthropic and AWS confirm your account meets the access requirements — don’t assume instant approval the way you might for an established model. If you’d rather access the model through Anthropic’s own hosted surface instead of Bedrock, the equivalent path is requesting access via Claude Platform on AWS, which uses a separate API key and console rather than Bedrock’s IAM-based model grants — this tutorial sticks with Bedrock since it’s the path most AWS-native shops will want for a single IAM boundary and one CloudTrail trail to audit.

  2. Attach an IAM policy scoped to the model. Don’t hand out account-wide Bedrock access. Scope the policy to the specific model ARN:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "bedrock:InvokeModel",
            "bedrock:InvokeModelWithResponseStream",
            "bedrock:Converse",
            "bedrock:ConverseStream"
          ],
          "Resource": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-fable-5-1-v1:0"
        }
      ]
    }
    

    Save that as fable-access-policy.json and attach it to your role:

    aws iam put-role-policy \
      --role-name your-app-role \
      --policy-name Fable51Access \
      --policy-document file://fable-access-policy.json
    
  3. Make your first Converse API call. Verify access with a simple CLI call before you write any application code:

    aws bedrock-runtime converse \
      --region us-east-1 \
      --model-id "anthropic.claude-fable-5-1-v1:0" \
      --messages '[{"role":"user","content":[{"text":"Say hello and confirm which model you are."}]}]' \
      --inference-config '{"maxTokens":200,"temperature":0.3}'
    

    A successful response confirms both that your access was approved and your IAM policy is correctly scoped. If you get AccessDeniedException, recheck step 1 (access not yet approved) before you start debugging IAM.

  4. Call it from Python with boto3. For anything beyond a smoke test, drive the call from your application code:

    import boto3
    
    client = boto3.client("bedrock-runtime", region_name="us-east-1")
    
    response = client.converse(
        modelId="anthropic.claude-fable-5-1-v1:0",
        messages=[
            {"role": "user", "content": [{"text": "List three risks of long-running unsupervised code agents."}]}
        ],
        inferenceConfig={"maxTokens": 800, "temperature": 0.3},
    )
    
    print(response["output"]["message"]["content"][0]["text"])
    
  5. Explicitly configure the aws_review data retention mode. Claude Fable 5.1’s Covered Model status means you need to set your data retention posture deliberately rather than relying on whatever your account defaulted to. In the Bedrock console, go to the model access detail page for Claude Fable 5.1 and select the data retention mode under the model’s governance settings, choosing aws_review to enable the up-to-30-day human safety review workflow within the AWS boundary. From the CLI, confirm and set it against the model’s access configuration:

    aws bedrock get-foundation-model-availability \
      --model-id "anthropic.claude-fable-5-1-v1:0"
    
    aws bedrock put-model-invocation-logging-configuration \
      --logging-config '{
        "cloudWatchConfig": {
          "logGroupName": "/bedrock/fable-5-1-invocations",
          "roleArn": "arn:aws:iam::123456789012:role/BedrockLoggingRole"
        },
        "textDataDeliveryEnabled": true
      }'
    

    Enabling invocation logging alongside the aws_review setting gives you your own record of what was sent, independent of AWS’s retention window — worth having for your own audit trail, not just AWS’s.

  6. Illustration: Claude Fable 5.1 on Bedrock — setup to first API call
  7. Verify the retention setting is actually active. Don’t trust the console click — confirm it in the model’s access configuration and cross-check against your CloudTrail events:

    aws cloudtrail lookup-events \
      --lookup-attributes AttributeKey=EventName,AttributeValue=Converse \
      --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
      --query "Events[?contains(Resources[0].ResourceName, 'fable-5-1')]"
    

    Pair that with a check of the Bedrock model card documentation for the retention behavior tied to your account’s configured mode, so you’re not guessing at what “active” actually means for your data.

  8. Run a tool-enabled call to confirm agentic behavior works end to end. A quick smoke test with tool use confirms your full harness — access, IAM, retention, and the toolConfig contract — is wired correctly before you build anything bigger on top:

    tool_config = {
        "tools": [
            {
                "toolSpec": {
                    "name": "run_tests",
                    "description": "Run the project's test suite and return pass/fail counts.",
                    "inputSchema": {"json": {"type": "object", "properties": {}}}
                }
            }
        ]
    }
    
    response = client.converse(
        modelId="anthropic.claude-fable-5-1-v1:0",
        messages=[{"role": "user", "content": [{"text": "Run the test suite and summarize failures."}]}],
        toolConfig=tool_config,
        inferenceConfig={"maxTokens": 500, "temperature": 0.2},
    )
    
    print(response["output"]["message"])
    

Troubleshooting the common failures

  • AccessDeniedException on your first Converse call: almost always means the model access request from step 1 hasn’t finished processing. Covered Model approvals can take longer than a standard grant — check the Bedrock console’s Model access page for a pending status before touching IAM.
  • ValidationException mentioning an unsupported field: usually a stale SDK. Claude Fable 5.1 shipped with updated boto3 models — run pip install --upgrade boto3 and retry before assuming a payload problem.
  • CloudTrail shows no Converse events at all: confirm you’re querying the same region you called the model in. Bedrock model access, IAM policies, and CloudTrail trails are all regional, and it’s easy to request access in one region and test in another.
  • Retention mode looks unset in the console: the setting lives under the model’s governance tab, not the general account settings page — a common place people look first and come up empty.

What you built

You now have Bedrock model access approved for Claude Fable 5.1, an IAM policy scoped tightly to that model’s ARN, a working Converse call from both the CLI and boto3, the aws_review data retention mode explicitly configured instead of left to default, and a CloudTrail-backed way to prove which mode was active for any given call. That’s the actual foundation a production agentic workload needs — everything from here is building your session harness and tool integrations on top of a base you’ve verified rather than assumed.

At Enkompass (enkompass.net), this is our home turf. We’ve shipped production Bedrock and SageMaker workloads that actually move the needle, not just demo well. We’ve run this exact Claude Fable 5.1 access-and-retention setup for clients who needed the audit trail airtight on day one, not discovered after the fact. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.

Ready when you are

Let’s map your route to AWS

A free 60-minute architecture review with a senior engineer. No slides, no SDR, just a plan.