# AWS Bedrock (Responses) rejects temperature

medium · inference · probed live 2026-08-01 · affects AWS Bedrock (Responses) ·
HTML version: [https://inferencecanary.com/aws-responses-temperature](https://inferencecanary.com/aws-responses-temperature)

`temperature` is a standard sampling parameter of the Responses dialect; `temperature: 0` in
particular is what makes runs reproducible. Bedrock's Responses lane rejects the parameter
with a 400 `unsupported_parameter` error — deterministic sampling is unreachable, so every run
on this lane is stochastic.

## What to send

([https://inferencecanary.com/assets/repro/temperature.responses.json](https://inferencecanary.com/assets/repro/temperature.responses.json))

```json
{
  "model": "google.gemma-4-31b",
  "input": [
    {
      "role": "user",
      "content": "Reply with just 'ok'."
    }
  ],
  "store": false,
  "temperature": 0,
  "max_output_tokens": 16
}
```

## What comes back

Verbatim:

```json
{
  "error": {
    "code": "unsupported_parameter",
    "message": "Unsupported parameter: 'temperature' is not supported with this model.",
    "param": "temperature",
    "type": "invalid_request_error"
  }
}
```

The identical body minus the `temperature` line succeeds — that pair is the repro. The
rejection is why this suite's own probes omit `temperature` on this lane, and why single-run
verdicts on it need repetitions.

## Why it matters

Evals and regression tests need determinism; applications porting request bodies across
Responses-dialect providers must special-case this one or accept stochastic output on it.

## Run it yourself

```
curl "https://bedrock-mantle.us-west-2.api.aws/openai/v1/responses" \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d @temperature.responses.json
```

Expected: 200 (the parameter is part of the dialect). Received: 400 `unsupported_parameter`.
Delete the `temperature` line and the same request succeeds.
