# Together AI — 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/togetherai/gemma-4-31b/](https://inferencecanary.com/togetherai/gemma-4-31b/) · matrix: [https://inferencecanary.com/index.md](https://inferencecanary.com/index.md)

## Grades


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

## Flags

- **[red · harness] Four providers drop replayed reasoning: the model never sees its own prior thinking** — The gemma-4 chat template renders reasoning replayed on model turns, and the model card mandates preserving thinking across tool-call turns — the reference provider reproduces this live. These four providers delete it before templating: on a continuation after a tool call, the model re-derives or invents instead of recalling, and no error is raised. AWS Bedrock's Responses dialect is the sharpest case: it defines an explicit input item for replayed reasoning, accepts it without error, and never renders it to the model. (details: [/replayed-reasoning-dropped/index.md](https://inferencecanary.com/replayed-reasoning-dropped/index.md))
- **[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))