# Structured output: repetition loop inside a JSON number literal runs to MAX\_TOKENS (Flash, Vertex)

**URL:** <https://discuss.ai.google.dev/t/structured-output-repetition-loop-inside-a-json-number-literal-runs-to-max-tokens-flash-vertex/175138>\
**Category:** Gemini API\
**Tags:** vertexai\
**Created:** [July 17, 2026, 9:58am UTC](https://discuss.ai.google.dev/t/structured-output-repetition-loop-inside-a-json-number-literal-runs-to-max-tokens-flash-vertex/175138 "2026-07-17T09:58:13Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![AmitPate](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/amitpate/32/137471_2.png) [@AmitPate](https://discuss.ai.google.dev/u/AmitPate)\
**Post date:** [July 17, 2026, 9:58am UTC](https://discuss.ai.google.dev/t/structured-output-repetition-loop-inside-a-json-number-literal-runs-to-max-tokens-flash-vertex/175138/1 "2026-07-17T09:58:14Z")

</div>

**Summary:** With structured output (`responseSchema` constrained decoding), Gemini Flash intermittently enters a token-repetition loop **inside a JSON number literal** and generates until `MAX_TOKENS`, returning unparseable JSON. This looks like the same family as earlier threads here (“Gemini 2.5 Flash gets stuck in infinite token repetition during structured JSON output”, “Gemini 2.5 Flash repeats tokens until max-tokens reached in structured output”) — but we captured a full raw artifact that pins the derail site to an unbounded number literal, which may help narrow it down. Also filed as [google-gemini/cookbook#1288](https://github.com/google-gemini/cookbook/issues/1288).

**Environment**

- Model: `gemini-3.5-flash` (also observed on `gemini-2.5-flash`) via **Vertex AI** , location `global`
- `generationConfig.responseMimeType: application/json` + `responseSchema` (OpenAPI subset), no thinking config, default temperature
- Input: ~18k tokens (system + user); schema: object with 3 array properties; array items contain string fields (some long: source code) and several **optional number fields** (`width`, `height`, `depth`, RGB components)

**Observed behaviour**

The model produced **14,200 characters of perfectly valid JSON** — including several multi-KB string fields, all completed correctly — then, while writing an _optional number property_ of a nested array item, emitted a digit sequence that never terminates:

```json
"tag": "plasma_bolt",
"primitive": "box",
"depth": 0.3,
"height": 0.1,
"width": 0.1523412323223241243124125215124124124124315352352...

```

The `width` value continues for **~61,000 characters of digits** (no other characters; the tail collapses into a repeating `523`/`235` cycle) until the response hits the 65,536 output-token cap and finishes with `finishReason: MAX_TOKENS`, `candidatesTokenCount: 65519`, `thoughtsTokenCount: 0`.

Because a JSON number’s digit sequence is grammatically unbounded under constrained decoding, once the model enters the digit loop no emitted token is ever invalid, so nothing can force termination — the failure mode is silent until the token cap.

**Reproduction characteristics**

- Intermittent per call (~1 in 3 for us with a triggering prompt), but strongly **content-dependent** : prompts whose responses populate the optional number fields fail near-consistently at the product level; prompts whose responses leave those arrays empty essentially never fail (0 in 40+ calls).
- Reproduced across weeks, multiple model versions, and many prompt variations; prompt-level mitigations do not help.
- The derail consistently happens late in generation (\>10k characters in), after long string fields have been written.

**Expected behaviour**

Either the constrained decoder bounds numeric literals to a sane length (JSON interop implies double precision anyway), or the repetition penalty/sampler recovers, or the response fails fast rather than burning 65k tokens.

Is this a known regression with a tracking bug? Happy to share the full 75KB raw response text and exact `generationConfig`/schema privately if useful.