Structured output: repetition loop inside a JSON number literal runs to MAX_TOKENS (Flash, Vertex)

Gemini API
1

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.

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:

"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.