How do you keep chain-of-thought reasoning out of the user-facing answer?

## What the question is really about Chain-of-thought only helps because the model generates intermediate text before committing to an answer; those tokens condition what comes next. That creates a product problem: the thing that makes the answer better is exactly the thing you usually do not want a customer to read. A moderation verdict, a pricing decision or a support reply should arrive as a clean result, not as a paragraph of the model second-guessing itself. So the requirement is *generate but do not display*, and the mistake to avoid is *do not generate*. ## The two-section contract The standard shape is one response containing two clearly delimited sections. A delimiter is any unambiguous marker the model can reproduce and your code can search for — an XML-style tag pair, a fenced block, a rare sentinel line. Reasoning goes first, the answer goes last, and the instruction says explicitly that nothing but the answer may appear inside the answer delimiter. Why that order is non-negotiable: an autoregressive model produces tokens left to right. If the verdict is emitted first, the deliberation that follows cannot influence it; the model then writes a defence of a choice it has already made. That reads convincingly and is empirically no better than answering with no reasoning at all — sometimes worse, because a wrong answer arrives wrapped in a plausible justification that makes review harder. ## Parsing it reliably Extraction should be exact and fail closed: - Search for the answer delimiter specifically. Do not fall back to "take the last line" or "take everything after the last blank line" — on a malformed response those fall back to the reasoning text and leak it to the user. - Constrain the answer's *shape* as well as its position when you can (a label from a fixed set, a number, a short JSON object). That turns a parse failure into an obvious validation failure instead of a silently wrong value. - On a miss, retry once with the format restated, then fall back to a safe default or route to a human. Never render unparsed output. - Track the miss rate as a metric. A rising rate is usually the first visible sign that the prompt drifted, the input got longer, or the model version changed. Some providers return deliberation on a separate channel from the visible answer, which removes the parsing problem entirely for that provider — but the design decision is the same, and a prompt-level contract is what keeps the behaviour portable when it is not available. ## The costs people forget Hidden reasoning is not free on any axis: - **Tokens.** Generated output is billed whether or not it is shown. A reasoning block that triples output length triples the output cost of every request that uses it. - **Latency.** The user waits for the reasoning to finish before the answer exists. If the interface streams, the visible part cannot begin until the reasoning section closes, so time-to-first-useful-token gets worse even though total wall time only grew moderately. - **Length control.** Without an explicit cap ("under 80 words", "at most five bullets") reasoning sections grow over time as prompts get edited, and cost grows with them silently. A practical mitigation is to ask for *brief* reasoning. On classification-shaped work, a short structured deliberation — name the applicable rules, judge each — often captures most of the accuracy benefit at a fraction of the tokens of an open-ended narration. ## Retention and privacy Teams routinely log the hidden section for quality sampling, and that is a genuinely good practice: it is the only artefact that explains a bad output. But it is user data. It quotes the input, often verbatim, and it can contain speculation about the person that you would never render — inferred intent, guessed circumstances, tentative accusations. Treat it with the same retention window, access controls, redaction and deletion behaviour as the conversation itself, and do not pipe it into a support tool with weaker access rules than the message store. ## What good looks like A reviewer wants to hear: reasoning first inside a delimiter, answer last inside its own delimiter, strict extraction that fails closed, a length cap on the reasoning, and an explicit decision about whether the hidden text is logged and under what policy. If the interviewer pushes on cost, the honest answer is that hiding changes nothing about billing or latency — it changes only what the user sees.