Teams putting Claude on Amazon Bedrock's classic bedrock-runtime endpoint quickly hit a fork in the road. InvokeModel (and its streaming twin, InvokeModelWithResponseStream) passes Anthropic's native Messages API body through to the model, with only the "anthropic_version": "bedrock-2023-05-31" field added. Converse (and ConverseStream) wraps the same models in a unified request shape that AWS recommends because it works consistently across the different model providers Bedrock hosts. Neither is wrong; they optimize for different things.
The comparison at a glance
| Dimension | InvokeModel | Converse |
|---|---|---|
| Request body | Anthropic-native Messages format (plus anthropic_version) | Bedrock's unified, provider-agnostic format |
| Portability across model providers | Anthropic models only — body is model-specific | One shape across Bedrock-hosted models |
| Portability toward Anthropic's 1P API | High — body matches the first-party Messages API | Requires translation |
| PDF handling | Full control (Anthropic's recommendation for PDFs) | Visual PDF analysis requires citations enabled; otherwise basic text extraction |
| Tool search feature | Available | Not available |
| IAM actions | bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream | bedrock:Converse, bedrock:ConverseStream |
| Invocation logging & CloudTrail | Covered | Covered |
When InvokeModel is the better fit
You want fidelity to Anthropic's API. Because the InvokeModel body is the Anthropic Messages format, code and prompts move more easily between Bedrock, Anthropic's first-party API, and the newer "Claude in Amazon Bedrock" surface — all of which speak Messages. Anthropic's own Python SDK offers an AnthropicBedrock client for exactly this path.
You need Claude-specific capabilities at full strength. Anthropic advises using InvokeModel for full control over PDF processing, and the tool search feature works on Bedrock through InvokeModel only. As new Claude-specific request fields appear, a pass-through body tends to expose them sooner than an abstraction layer can.
When Converse is the better fit
You are standardizing across models. If your platform team wants one internal integration that can route to Claude today and evaluate other Bedrock-hosted models tomorrow without rewriting request-building code, Converse's unified parameter set is precisely its reason for existing — and it is AWS's recommended choice for that scenario.
You are building on AWS-ecosystem examples. Much current AWS documentation, sample code, and tooling for multi-model applications is written against Converse, so teams living deep in the AWS ecosystem often find it the path of least resistance.
The option that outranks both
Before committing, check whether you should be on this surface at all. The legacy runtime surface uses ARN-versioned model IDs (like global.anthropic.claude-opus-4-6-v1) and does not carry the newest models: Claude Fable 5, Opus 4.8, and Opus 4.7 have no ARN-versioned IDs, and Claude Sonnet 5 is absent from it entirely. The current "Claude in Amazon Bedrock" surface (the bedrock-mantle endpoint) serves the full modern lineup with the standard Anthropic Messages request shape and standard SSE streaming. For new builds in 2026, that is usually the strongest default — InvokeModel vs Converse is the right question mainly when legacy-surface integrations (such as model invocation logging, which captures bedrock-runtime calls but not bedrock-mantle calls) keep you on the classic endpoint.
Operational notes that apply either way
Both APIs are logged as CloudTrail management events by default and both are captured by model invocation logging if you enable it. On the IAM side, denying bedrock:InvokeModel automatically blocks Converse as well; to explicitly deny all inference, AWS suggests the bedrock:InvokeModel* wildcard or adding the Converse actions. And the same operational limits apply to both: 20 MB request payloads and a 60-minute inference timeout that usually requires raising your SDK's default read timeout.
Where to go next
Go deeper on each side with InvokeModel in depth and the Converse deep dive, or check the feature matrix to see what Bedrock supports overall.