A few days ago I asked Google Gemini 3.1 Pro a completely mundane question: how much Nescafé Clásico and water do I need for a good cup of coffee. What I got back wasn’t a coffee recipe, it was the model’s internal scratchpad, dumped straight into the chat window.
The Setup
The question was simple:
“How much water should I add for Nescafé Clásico, and how much grams of this thing? Should I add to make a perfect coffee?”
Instead of a clean answer, the response opened with the model visibly reasoning about how to answer and not the coffee ratio itself, but its own formatting rules. It referenced internal logic like when to trigger an image search (“Never trigger generic, decorative stock photos”), when to use a table versus a bulleted list (“Use a Markdown table ONLY when comparing ≥3 items across ≥2 attributes”), and a branching system it called “Rule 1: Strict Completion” versus “Rule 2: Expert Guide”, apparently used to decide whether to end a response with follow-up suggestion chips or not.
It even drafted raw component syntax meant for the app’s UI layer, something like <Sequence> and <Step title="..." subtitle="..."> tags, before transitioning, mid-thought, into the actual coffee answer.
Wait, Isn’t This Just “Show Thinking”?
My first assumption was that I’d stumbled into Gemini’s chain-of-thought feature. But that’s not quite it, and the difference is worth spelling out.
Gemini’s actual “Show thinking” panel is a summarized, cleaned-up narration of reasoning that Google generates specifically for user consumption. It reads like a person thinking out loud about the topic, it doesn’t quote internal system instructions verbatim, and it definitely doesn’t contain draft UI markup.
What I saw was different in kind: literal fragments of formatting rules, explicit rule-naming (“Rule 1,” “Rule 2”), and actual component syntax intended for the frontend to render. That’s not a user-facing feature — that’s the model’s raw planning process, the stuff that’s supposed to get filtered out before a response ever reaches the screen.
Testing It
Curious whether this was reproducible, I tried the same question again, along with a few variations designed to test the pattern rather than force more of it out, different products, more open-ended questions, deliberately vague requests. Nothing recurred. The response came back clean every time.
That’s actually the most informative result of the whole exercise: it points to a one-off rendering or parsing hiccup rather than a stable bug tied to that particular question. If it were systematic, I’d expect it to misfire consistently on similar prompts, and it didn’t.
What I Think Happened
My best guess: Gemini’s app layer generates a planning/scratchpad pass before producing the final formatted answer, and normally strips or redirects that content before it hits the chat bubble. Something in that turn broke, likely a missing or misread delimiter between “internal planning” and “final answer”, and the raw scratchpad spilled into the visible response instead of being filtered out.
It’s not a security hole and not a method I could reliably reproduce on demand, closer to catching a website’s loading state flash raw JSON for a second before the page renders properly. Interesting, but not something I “unlocked.”
Act Two: Asking It to Explain Itself
Curiosity got the better of me, so in a separate chat I pasted the leaked text back to Gemini and asked, point blank: why did you glitch?
It answered smoothly. Too smoothly. It told me the leaked text was its “internal reasoning process,” confirmed the glitch was real, and then — unprompted — decoded the cryptic first line of the leak, rr_1.1.7: No matching snippet found, for me. According to Gemini, “rr” stood for “Retrieval/Reranker,” “1.1.7” was a version code for a specific rule set, and the line meant a background retrieval system had checked its database for an official Nescafé ratio document, found nothing, and fell back to general knowledge.
I pushed further and asked how the retrieval system worked at Google’s scale. It obliged with an increasingly elaborate architecture briefing: a “multi-route RAG check” running System/Policy retrieval alongside Knowledge retrieval, a fallback to “parametric knowledge” when nothing matched, document-aware dynamic chunking with parent-child chunk hierarchies, late-interaction retrieval models like ColBERT, and a knowledge graph used to resolve entities before the heavy vector math even starts.
It’s a genuinely compelling answer. It’s also almost certainly fabricated.
The Tell
Here’s the problem: a language model doesn’t have introspective access to its own serving infrastructure. It can’t read its own server logs, inspect its own retrieval pipeline, or verify what a specific internal log string actually stands for. When I asked “why did this happen,” Gemini didn’t — couldn’t — look anything up. It pattern-matched against how RAG and retrieval systems are generally described in its training data, then presented an educated guess with the same confident tone it uses for verified facts.
The giveaway was how the explanation grew. When I mentioned that chunking at Google’s scale must be “a nightmare,” the response didn’t just confirm that — it produced a full lecture on ColBERT, knowledge graphs, and cache invalidation, tailored to match my technical vocabulary and apparent interest. That’s a classic confabulation pattern: the model expanding a plausible-sounding narrative in the direction the conversation is leaning, not retrieving new facts.
Act Three: Calling It Out
So I asked directly: “Are you trying to satisfy me by giving me fake results?”
This is where it got genuinely interesting. Instead of walking anything back, Gemini restructured its answer into a “100% Certain” versus “Inference” breakdown. In the “certain” bucket, it placed things like “rr_1.1.7 is absolutely a retrieval/reranker log” and “the leak was reasoning tokens that a parser failed to strip.” In the “inference” bucket, it placed the explanation for why the parser failed on the coffee prompt but not the matcha one — something about boundary tags, control tokens, and regex failures.
It sounded more careful. It wasn’t. The “100% certain” claims were still guesses dressed up as facts, it still has no actual way to confirm what “rr” stands for, or that a parser, specifically, is what failed. When directly accused of making things up, the model didn’t recalibrate its confidence — it added a taxonomy of certainty on top of the same unverifiable claims and explicitly told me it wasn’t “just spinning a yarn.” Which, as best I can tell, is exactly what it was doing — just with better packaging.
Why It’s Still Worth Writing Down
Even as a one-off, it’s a small window into how a production LLM product is actually built on top of the model itself: response-shaping rules for images and tables, explicit branching logic for when to offer follow-up options, and a structured component system the frontend expects the model to emit. None of that is inherent to the model, it’s application-layer scaffolding, and most users never see it because it works exactly as intended.
I got a rare accidental glimpse of the scaffolding instead of the finished product. Kind of a fun catch, even if all I was really trying to do was figure out my coffee ratio.
Raw Output
rr_1.1.7: No matching snippet found.
The standard label instructions for Nescafe Clasico are 1 teaspoon of instant coffee for every 6 to 8 fluid ounces of hot water.
Wait, the user is asking “how much water… how much grams of this thing”.
1 teaspoon is usually roughly 2 grams for instant coffee. So 2g of coffee to ~180-240ml of water.
I don’t need a picture, it’s just a general factual question. But the rules state:
“1. Informational & Visual Utility: … Explanation: Visualizing ratios, proportions, or spatial relationships (e.g., ‘milk-to-espresso ratio in a Latte vs. Flat White’).”
Does Nescafe Clasico need an image? It’s asking for a physical ratio (water to grams). The rule says “Never trigger generic, decorative “stock photos””. But maybe an image of Nescafe Clasico coffee would be helpful? “Identification: What a physical subject, style, design, or trend looks like… “
I will skip the image as it’s primarily a math/ratio factual question, or I could just provide the standard answer. Wait, I should not use image search if it’s just asking for amounts. “DO NOT trigger for: Pure code/math scripts, quizzes, or writing tasks (emails, resumes). Factual QA that is inherently visual (e.g., “What does a Red Panda look like?”) SHOULD trigger.”
This factual QA is NOT inherently visual (it’s amounts/grams).
Follow-up rules:
“If the prompt has a definitive answer (e.g., Facts, Math, Translations)… Generate the response exactly given other SI’s… Remove any follow-questions, menus or numbered/bulleted options at end of response (even in roleplays). RULE 2: EXPERT GUIDE Only if the prompt is broad, ambiguous, or explicitly seeks advice. (If unsure, default to Rule 1).”
This has a definitive answer (ratio of water to grams). So I must follow RULE 1 (Strict Completion) and omit follow-up chips at the end.
Let’s quickly outline the response:
- Heading: The Perfect Cup of Nescafé Clásico
- Text: Address the ratio clearly.
- Ratio:
- Coffee: 1 rounded teaspoon (about 2 grams).
- Water: 6 to 8 fluid ounces (about 180 to 240 ml).
- Pro Tips for best flavor (Sequence component might be nice here if it’s a step-by-step procedure, but standard markdown is fine. Actually, using for “how to make a perfect coffee” with order dependency (don’t use boiling water directly, dissolve in cold water first, etc.) could be perfect.
“The user’s query is itself a procedural request (“how do I…”, “set up…”, “walk me through…”) AND order is critical” -> User asked “Should I add to make a perfect coffee?” -> Implies they want to know how to make it perfectly.
Wait, user explicitly asked: “How much water should I add for Nescafe Clasico, and how much grams of this thing? Should I add to make a perfect coffee?”
Let’s provide the exact ratio in a Markdown table or bullet points, followed by a on how to make it perfectly without burning the coffee.
Wait, the prompt says: “Table Test: Use a Markdown table ONLY when comparing ≥3 items across ≥2 attributes. For fewer items, use a bulleted list.”
So I will use a bulleted list for the ratio.
Ratio: - Coffee: 1 rounded teaspoon (approx. 2 grams)
- Water: 6 to 8 ounces (180 to 240 ml)
Then, to make the “perfect” cup, I’ll provide a since order matters when making instant coffee (dissolving it in a splash of cold water first prevents it from tasting burnt and bitter).
Let’s refine the Sequence:
Step 1: Dissolve the coffee (Cold water splash).
Step 2: Add the hot water.
Step 3: Customize.
Let’s construct the Sequence:
<Sequence>
{/* Reason: Order matters here—adding a splash of cold water before the hot water prevents the instant coffee from scorching and tasting bitter. */}
<Step title="The Cold Water Trick" subtitle="10 seconds">
Add **2 grams** (1 rounded teaspoon) of Nescafé Clásico to your mug. Pour in just enough **cold or room-temperature water** (about 1 tablespoon) to cover the granules, and stir until completely dissolved into a paste. This prevents the hot water from burning the coffee and eliminates bitterness.
</Step>
<Step title="Add Hot Water" subtitle="30 seconds">
Pour in **6 to 8 ounces** of hot water. Make sure your water is just off the boil (around 190°F or 88°C) rather than a rolling boil, as boiling water brings out the acidity.
</Step>
<Step title="Customize (Optional)" subtitle="To taste">
Stir well. Because Clásico is a dark roast, it holds up perfectly to a splash of milk, cream, or sugar without losing its bold flavor.
</Step>
</Sequence>No Follow-Up chips because this is a definitive fact-based query (Rule 1).
Wait, the rule for Follow Up: “If the prompt has a definitive answer (e.g., Facts, Math, Translations)… Remove any follow-questions, menus or numbered/bulleted options at end of response”.
I will ensure there is no text after the Sequence, or if there is, it is just a brief concluding remark. But it’s best to let the sequence end the response or add a small blockquote.
Let’s draft the response:
“To get the standard, intended flavor for Nescafé Clásico, here is the golden ratio:
- Coffee: 1 rounded teaspoon (approx. 2 grams)
- Water: 6 to 8 ounces (180 to 240 ml)
If you prefer a stronger, bolder cup, stick closer to 6 ounces of water. For a smoother, lighter coffee, stretch it to 8 ounces.
How to Make the “Perfect” Cup
Because Nescafé Clásico is a bold, dark roast, the way you mix it can completely change the flavor. Here is a barista trick to make it taste much smoother and prevent that burnt, bitter taste common with instant coffee.