Claude structured outputs on Bedrock: what you still validate

Structured outputs for Claude on Amazon Bedrock make the model generate JSON that matches your schema, and strict tool use does the same for tool inputs. That removes parse errors and missing fields, but not every check: numeric ranges, string lengths, refusals and truncated responses still need handling in your own code.

What was released

Structured outputs for Anthropic Claude models were announced by AWS on 19 October 2026 in the AWS Machine Learning Blog. AWS describes the feature as generally available for all Claude models on both the bedrock-runtime and bedrock-mantle endpoints, wherever the model itself is offered. It works with batch inference, with cross-Region inference on bedrock-runtime, and with streaming, where structured responses arrive as typed events.

There are two mechanisms. A JSON Schema output format shapes the whole response, passed in the Anthropic-native request body as output_config.format with "type": "json_schema" and a schema object. Strict tool use sets "strict": true on a tool definition so the arguments Claude produces for that tool match its input_schema, with no extra fields.

What actually changed

Before this release, AWS notes, integrations needed custom parsing, retry logic and post-processing. AWS says enforcement now happens during token generation through constrained decoding: Bedrock validates the schema, compiles it into a grammar, and the model cannot emit tokens that would break it. The result is valid JSON, correct field types and every required field present.

The details that shape how you use it, all from the AWS announcement:

• Supported schema features: basic types, enum, const, anyOf and allOf with limits, internal $ref and $defs, common string formats such as date-time, email and uuid, and minItems of 0 or 1 only.
• Accepted but not enforced: recursive schemas, external references, minimum, maximum, multipleOf, minLength, maxLength, and any additionalProperties value other than false. The model can still return values that break these rules.
• Required: additionalProperties: false on every object.
• Latency: the first request with a new schema is slower while Bedrock compiles the grammar. Compiled grammars are cached for 24 hours per account; changing a schema's structure invalidates the cache, while changing only names or descriptions does not.
• Converse API: the schema counts towards the request payload size.

AWS does not list a separate charge for the feature, and notes that limiting output to schema fields can reduce output tokens.

What it means for teams building on Bedrock

Delete the retry loop, keep the business checks. Structured outputs remove the class of failures where JSON would not parse or a field was missing. They do not check that an amount is positive, that a quantity is within stock, or that a free-text field is short enough for your database column, because those constraints are accepted but not enforced. In CodeDTX's view, the clean split is to let the schema guarantee shape and keep a small validator for values, as described in our guide to validating AI agent output.

Check stop_reason on every response. AWS warns that a refusal or a max_tokens stop can still produce output that does not match the schema. Treat any stop_reason other than end_turn as a failed call and route it to your existing error path, rather than parsing it. This matters most in batch jobs, where a truncated record can pass silently into a downstream system.

Use strict tool use for agents that act. For agents whose tools write to records, send messages or move money, strict mode stops malformed or invented arguments reaching the tool. Pair it with the handling in when an AI agent tool call fails, since a well-formed call can still be the wrong call.

Plan for the first-request cost. Because each new schema is compiled on first use, latency-sensitive paths should warm the schema before traffic arrives and avoid generating schemas per request. Keep schemas stable and versioned: a structural edit means a recompile, and a schema built dynamically from user input never benefits from the cache.

Mind your schema design. Enums for fixed value sets, flat objects where possible and short descriptions keep schemas inside the supported subset and keep Converse payloads small. Recursive structures, such as nested comment threads, are not enforced, so flatten them or validate them yourself.

When not to switch yet

If your pipeline already validates with a schema library and retries rarely, the gain is mostly removing code, so there is no rush. Teams running Claude through a gateway that rewrites request bodies should first confirm output_config and the strict flag survive the hop. Workloads that depend on recursive schemas or numeric limits will still need their own validation either way. And if you call Claude both on Bedrock and through another provider, keep one schema definition and test both paths, because supported features and request formats can differ.

Frequently asked questions

Which Claude models support structured outputs on Bedrock?

AWS says structured outputs work with all Anthropic Claude models on Amazon Bedrock, on both the bedrock-runtime and bedrock-mantle endpoints, wherever the model is available. The announcement examples use Claude Sonnet 5.5 and Claude Haiku 5.5 through global inference profiles. AWS does not publish a per-Region list in the post, so confirm the model and Region you use before relying on it in production.

Do I still need to validate JSON from Claude on Bedrock?

You can stop checking that the response parses and that required fields exist, because constrained decoding guarantees both. You still need to check value rules such as minimum, maximum and string length, which Bedrock accepts in the schema but does not enforce. You also need to check the stop reason, because a refusal or a token limit can still return output that does not match the schema.

What is the difference between JSON Schema output and strict tool use?

JSON Schema output controls the shape of Claude's whole response, which suits data extraction, classification and API responses. Strict tool use applies a schema to the arguments Claude produces when it calls a tool, which suits agents and function calling. You can use both in the same application, for example strict tools while an agent works and a JSON schema for its final report.

Why is the first request with a new schema slower?

Bedrock compiles each new schema into a grammar before it can constrain generation, and that compilation adds latency to the first request. The compiled grammar is cached for your account, so later requests with the same schema skip the step. Changing the structure of the schema triggers a new compile, while editing only names or descriptions does not, so keep schemas stable and warm them before peak traffic.