Bedrock & Claude

This is the whole point of the chapter in one screen: call Claude — the same model family you know from the Anthropic SDK — but through Amazon Bedrock instead. Bedrock is AWS's managed door to many foundation models; here you send it a question and print Claude's answer plus how many tokens it used.

1. import boto3 pulls in AWS's official Python library. Everything you do with AWS from Python goes through boto3.
2. boto3.client("bedrock-runtime", region_name="us-east-1") creates the Bedrock runtime client — the object that actually sends inference requests. bedrock-runtime is the 'run a model' service (a separate bedrock service handles setup/admin). region_name picks which AWS data-center region answers you, because model access is enabled per region.
3. MODEL = "anthropic.claude-3-5-sonnet-..." is Bedrock's model ID — the exact Claude version to call. On Bedrock you name models by these IDs rather than short names.
4. brt.converse(...) is the Converse API — the modern, model-agnostic call. system=[{"text": ...}] sets the standing instruction (persona/rules). messages=[{"role": "user", "content": [{"text": ...}]}] is the actual question. Note content is a list of blocks, each a {"text": ...} dict — that list shape is what later lets you add images or tool calls the same way.
5. inferenceConfig={"maxTokens": 200, "temperature": 0.2} are the knobs: maxTokens caps how long the reply can be; temperature near 0 makes answers more focused and repeatable (higher = more creative/random).
6. resp["output"]["message"]["content"][0]["text"] reaches into the nested response to pull out the first text block — Claude's actual sentence. resp["usage"] holds inputTokens/outputTokens, which you print for cost tracking (you pay per token).

What the output means: The first printed line is Claude's one-sentence answer. The second line, tokens in/out: 28 41, means the request cost 28 input tokens and the reply used 41 output tokens — multiply those by the model's per-token price to get the dollar cost.

Try this: Change the user question, or bump temperature to 0.9 and run twice — at high temperature you'll notice the wording changes between runs; at 0.2 it stays steady. (Running for real needs AWS credentials and Bedrock model access — see the box at the top.)

Same Converse call, but instead of waiting for the whole answer, this streams it — you get the text piece by piece as Claude generates it. That's what makes a chat UI feel alive, showing words as they arrive instead of a long pause then a wall of text.

1. The client, model ID, and messages are set up exactly like Lab W2.1 — nothing new about how you talk to Bedrock.
2. brt.converse_stream(...) is the streaming twin of converse. Instead of one finished reply, it hands back a stream of events that arrive over time.
3. for event in stream["stream"]: loops over those events as they come in. Each event is a small dict describing something that just happened (text arrived, message started, message ended, etc.).
4. if "contentBlockDelta" in event: keeps only the events that carry a new chunk of text. A delta means 'a little more of the answer'. event["contentBlockDelta"]["delta"]["text"] is that chunk.
5. print(..., end="", flush=True) prints each chunk with no line break (end="") and forces it to the screen immediately (flush=True) so the text appears live. The final bare print() just adds a newline at the end.

What the output means: On screen you'd see the answer type itself out — "1... 2... 3..." appearing progressively — rather than all at once. The end result is the same text as a non-streamed call; only the delivery is incremental.

Try this: Add a counter that increments inside the if and print it at the end to see how many text deltas the reply arrived in — a short answer might be a handful, a long one dozens.

This is the older, lower-level way to call a model on Bedrock: invoke_model. Instead of the tidy Converse shape, you hand Bedrock the provider's native JSON body yourself. For Claude that body is the raw Anthropic Messages format. You'll meet this in legacy code and when you need a Claude-specific field Converse doesn't expose.

1. import boto3, json — you now also need json because you build the request body as a dict and turn it into a JSON string by hand.
2. The body dict is Claude's native format. "anthropic_version": "bedrock-2023-05-31" is a required tag telling Bedrock which Claude request schema you're using. max_tokens and messages look like the Anthropic SDK — note the snake_case names here vs. Converse's maxTokens.
3. brt.invoke_model(modelId=..., body=json.dumps(body)) sends it. json.dumps(body) converts your Python dict into the JSON text string the API expects.
4. payload = json.loads(resp["body"].read()) reverses that on the way back: the response body is a raw stream, so you .read() the bytes and json.loads parses them into a Python dict.
5. payload["content"][0]["text"] pulls the answer out of that dict — the same list-of-blocks shape Claude always returns.

What the output means: Prints Claude's reply to "Say hello." The result is identical to what Converse would give; the difference is purely that you assembled and parsed the JSON yourself.

Try this: Compare this block to Lab W2.1 side by side. Everything Converse did automatically — naming fields, encoding JSON, decoding the response — you did manually here. That's exactly why the tip below says prefer Converse for new code and keep invoke_model for special cases.