Amazon Bedrock is an AWS-operated managed service, so Anthropic API capabilities arrive there on AWS's schedule rather than Anthropic's. As of July 2026 the pattern is clear: everything you need for request/response and client-side tool workloads is supported, while server-side tools, Anthropic-hosted infrastructure endpoints, and some newest conveniences are not. The tables below map the major capabilities; the summary reflects the official documentation as of this writing, and availability changes, so verify anything load-bearing against the sources at the end.
Supported on Bedrock
| Capability | Status | Notes |
|---|---|---|
| Messages API, streaming, tool use | Supported | Core API; same request shape as first-party on the current surface |
| Vision (image input) and PDF input | Supported | Base64 content blocks; URL input sources are not supported |
| Prompt caching (5-minute and 1-hour) | Supported | Explicit cache_control breakpoints only — automatic caching is not supported |
| Extended and adaptive thinking | Supported | Manual budgets on older generations; adaptive on 4.7+ — see the model split |
| Structured outputs / strict tool use | Supported | |
| Token counting, citations, search-results blocks | Supported | |
| Fine-grained tool streaming | Supported | |
| Client-side tools: bash, text editor, memory | Supported | Computer use is beta everywhere, including Bedrock |
| Tool search | Supported (partial) | InvokeModel API only, not Converse |
| 1M-token context window | Supported | Fable 5, Opus 4.8/4.7/4.6, Sonnet 4.6; Sonnet 4.5 and older have 200K |
| Compaction and context editing | Beta | Beta across all platforms |
Not supported on Bedrock
| Capability | What to do instead |
|---|---|
| Message Batches API | AWS's own S3-based batch inference (50% discount, no tool calling or structured output), or a queue-and-worker pattern |
| Files API | Inline base64 content; stage files in S3 |
| Server-side tools: web search, web fetch, code execution, advisor | Client-side tool use with your own backend |
| Models, Admin, Compliance, Usage and Cost APIs | AWS-native equivalents (console, IAM, CloudTrail, Cost Explorer) |
| Agent Skills (Messages API), MCP connector, programmatic tool calling | Orchestrate client-side, or use 1P / Claude Platform on AWS |
| Claude Managed Agents, self-hosted sandboxes | 1P or Claude Platform on AWS (beta there) |
| Automatic prompt caching, cache diagnostics | Explicit breakpoints; monitor usage fields |
URL input sources, mid-conversation system messages, server-side fallback (fallbacks), inference_geo, fast mode | Handle client-side where applicable |
How to read the gaps
Three observations help teams plan. First, nothing in the request/response core is missing — a typical enterprise workload of summarization, extraction, classification, RAG (retrieval-augmented generation), and client-executed tools ports to Bedrock without redesign. Second, the gaps are mostly Anthropic-hosted services: batches, file storage, server-side tools, and managed agent infrastructure are things Anthropic runs on its own platform, and on Bedrock the equivalent responsibilities shift to AWS services or your code. Third, each gap has a documented workaround, linked in the table above — the cost is engineering effort, not feasibility.
If a roadmap depends heavily on the missing column — particularly Managed Agents, MCP connector, or server-side web tools — consider Claude Platform on AWS, the Anthropic-operated service that runs inside AWS with typically same-day feature parity with the first-party API. Many organizations run both: Bedrock for AWS-native governed workloads, Claude Platform on AWS where feature velocity matters.
Where to go next
The homepage feature matrix compares all four platforms side by side; the feature-gaps overview covers Vertex AI too; and Bedrock vs. Claude Platform on AWS helps when the gaps above are decision-drivers.