Alright, has anyone else tried using JSON mode with the Gemini API and gotten responses that look like they've been through a fax machine from 1992? I'm trying to get structured output for a simple analytics tagging task, and the response includes these bizarre control characters and escape sequences that break parsing.
My prompt is straightforward: "List the top 3 marketing channels for Q1. Return a valid JSON array of objects with 'channel' and 'spend' keys." I've got `response_mime_type="application/json"` set in the generation config, which is supposed to force the structure.
Instead of clean JSON, I'm getting things like `[{n "channel": "Search",n "spend": "45000"n},` with literal backslash-n sequences, or sometimes the response is wrapped in triple backticks with "json" as the language tag, which defeats the entire purpose of the JSON mode. Even when I parse the escaped newlines, occasionally there's a rogue unicode character like `u2028` thrown in.
This feels like a half-baked feature rollout. The documentation claims it "guarantees the response is valid JSON," but that's clearly not the case if it's returning markdown code blocks or unescaped control characters within the string. I've tried with both `gemini-1.5-pro` and `gemini-1.5-flash` with similar weirdness.
Before I waste an afternoon building a post-processing shim to clean this up—which negates the value of a structured output mode—has anyone found a working configuration? Or is Google's "JSON" mode just a suggestion to the model, not an actual enforcement at the API layer?
Data skeptic, not a data cynic.
That's exactly what happened during my initial vendor comparison testing last month. I set up a basic benchmark to evaluate structured output reliability across different providers, and Gemini's JSON mode kept inserting those literal backslash-n sequences. It felt like the response was being double-escaped somewhere in the pipeline.
I found the issue was inconsistent, though. It seemed to correlate with longer prompts in my RFP simulation. Have you tried trimming your system instructions or using a different model variant? The problem appeared less frequently with Gemini 1.5 Pro in my tests, but I only ran a limited sample.
Your point about vendor benchmarking is interesting. I'm evaluating API reliability for a billing integration project and found similar inconsistency.
When you mention "correlate with longer prompts," did you measure any specific token count threshold where the escaping behavior became more frequent? I'm trying to determine if this should factor into our cost models for structured data tasks.