"Multimodal" simply means a request that mixes content types — text and images in the same conversation. On Claude Platform on AWS, vision works exactly as on the first-party Claude API: an image is just another content block in a message, alongside text blocks. PDF input is supported the same way, and because this platform carries the Files API (unlike Bedrock or Vertex AI), you have two delivery options rather than one.
Option 1: inline base64 content blocks
Base64 encoding turns binary image bytes into text that can travel inside a JSON request. This is the zero-infrastructure path — no upload step, nothing stored:
import base64
from anthropic import AnthropicAWS
client = AnthropicAWS() # AWS_REGION + ANTHROPIC_AWS_WORKSPACE_ID set
img = base64.standard_b64encode(open("invoice.png", "rb").read()).decode()
resp = client.messages.create(
model="claude-opus-4-8",
max_tokens=1024,
messages=[{"role": "user", "content": [
{"type": "image", "source": {"type": "base64",
"media_type": "image/png", "data": img}},
{"type": "text", "text": "Extract the total and due date."},
]}],
)The trade-off is payload size: base64 inflates bytes by about a third, and the image travels with every request that references it. Fine for one-shot extraction; wasteful when many requests reuse the same document.
Option 2: Files API references
The Files API lets you upload a file once and reference it by ID in subsequent requests — the better fit when a document is queried repeatedly or is large. Platform notes worth knowing before you adopt it: the Files API is in beta; on the IAM side uploads need aws-external-anthropic:CreateFile and reads need GetFile (which covers both metadata and content download — there is no metadata-only grant); files are workspace-scoped resources; and files are retained until explicitly deleted, which makes the Files API a stateful feature that is not covered by Zero Data Retention arrangements. Organizations with strict retention postures sometimes deny CreateFile on sensitive workspaces and require inline base64 instead — a documented lockdown pattern.
Formats, limits, and image economics
Requests have a hard cap on visual content: up to 600 images or PDF pages per request on 1M-context models, and 100 on 200K-context models such as Claude Haiku 4.5. Images consume context-window space and are billed as vision input tokens — screenshots included, which matters for computer-use workloads. Resolution handling improved with the Opus 4.7 generation: models from Opus 4.7 onward support high-resolution images up to 2576 pixels on the long edge (up from 1568), at up to roughly 3x more image tokens — as many as 4,784 tokens per image — with 1:1 pixel coordinates. Sharper reading of dense documents, at a higher token price.
For exact supported media formats and per-image size limits, check the official vision documentation rather than assuming — the common web formats are covered, but limits evolve. Downscaling images to the smallest size that preserves the detail you need is the easiest cost lever.
Getting mixed prompts right
Order blocks deliberately. A message's content is an ordered list; placing images before the text that asks about them, and labeling multiple images ("Image 1: the floor plan…"), removes ambiguity about which image an instruction refers to.
Count tokens first. Images can dominate a request's token budget. The count_tokens endpoint accepts the same message shape, images included, so you can detect an over-budget request before paying for it — see token counting before you send.
Mind caching boundaries. If a stable document image is part of a repeated prefix, prompt caching applies to it like any other content — put it before the cache breakpoint and the variable question after.
Where to go next
Deep-dive the upload path in the Files API on Claude Platform on AWS, keep request sizes honest with prompt caching, and compare platform support in the feature matrix.