# DeepInfra — gemma-4-31b grade card

OpenAI chat/completions · serves `google/gemma-4-31B-it` as gemma-4-31b · probed live 2026-07-27

HTML version: [https://inferencecanary.com/deepinfra/gemma-4-31b/](https://inferencecanary.com/deepinfra/gemma-4-31b/) · matrix: [https://inferencecanary.com/index.md](https://inferencecanary.com/index.md)

## Grades


| Axis | Grade | Basis |
|---|---|---|
| Harness | C− | A − 2 red − 1 yellow, per the published ladder |
| Billing | OK | Reported usage consistent with bytes on the wire. |
| Caching | Sometimes (1/3 hits) | Reused already-seen context on 1/3 cold→warm trials. Speed numbers: [https://inferencecanary.com/speed/index.md](https://inferencecanary.com/speed/index.md) |
| Faithfulness | 27/29 | Agreement with the reference provider over the 29-cell deterministic battery (temperature 0, thinking disabled). |

## Flags

- **[red · harness] Images in tool results: rejected, 500'd, or silently blinded on 7 of 11 providers** — The model reads images returned by tools — the reference provider delivers them, perception-judged, and three OpenAI-compat providers prove the standard shape works. Seven providers fail on schema choice, not model limits: four reject the request (400/422), SambaNova returns a deterministic 500, and AWS Bedrock (Responses) is the worst class — it returns 200 and the model never sees the image, answering confidently about content it never saw. Google's own shim rejects a capability Google's native protocol serves. (details: [/findings/index.md](https://inferencecanary.com/findings/index.md#tool-result-images))
- **[red · harness] DeepInfra validates tool_choice but does not enforce it** — Invalid values are rejected with 400/422 — every surface signal says the capability exists — but a valid constraint has zero effect on decoding: "required" returns prose with zero calls, and forcing a tool by name yields a call to a different tool. An application relying on forced tool calls silently gets prose. (details: [/findings/index.md](https://inferencecanary.com/findings/index.md#deepinfra-tool-choice-unenforced))
- **[yellow · harness] Tool results replayed out of order are mis-paired on most providers** — The chat dialect's contract is that a tool message is matched to its call by tool_call_id, in any order. After two parallel calls, replaying the results reversed swaps the data between them on these providers — the template renders by name, and these providers render positionally, dropping their own dialect's id contract. An async harness that appends results in completion order silently swaps payloads. One provider pairs correctly, proving the fix is implementable provider-side. (details: [/findings/index.md](https://inferencecanary.com/findings/index.md#tool-results-out-of-order))