In a production prompt for generating a single SQL query, what's the right way to make sure the model returns only the SQL without trailing commentary?

Suppressing trailing commentary on a generated SQL query is a layered problem, not a single-knob problem. Three controls work together. **Stop sequence.** This is the strongest tool. You tell the API that when the model emits a specific byte sequence (a closing fence like ```` ``` ````, or a sentinel like `END_SQL`), generation stops immediately at that point. The model literally does not get to sample any tokens past the sequence. In your few-shot examples, demonstrate the pattern: the SQL ends with the terminator on its own line. The model learns to emit the terminator after the SQL, and the API's stop logic cuts the response there. **max_tokens.** This caps the worst case. Size it for a realistic SQL length budget (say 500 tokens for a complex analytical query). It is a guardrail, not a primary control. If you size it tight enough to cut off commentary, you risk truncating long but legitimate SQL. If you size it loose enough to fit any SQL, it does not suppress commentary. **Post-hoc parser.** The safety net. Take the response, strip whitespace, parse out everything up to the first occurrence of the terminator (or until you have a complete SQL statement). This catches the edge cases where the model added leading commentary, did not emit the terminator, or wrapped the SQL in extra prose. The instruction in the system prompt (return only the SQL, no explanation) is necessary too. It is what makes the model prefer the terminator and avoid commentary in the first place. But on its own it is not a guarantee.

Production output control is layered because each layer fails differently and the layers compose. **Layer 1, stop sequence.** The strongest control. Specifying a stop sequence (`stop_sequences=['```']` on Anthropic, `stop=['```']` on OpenAI) terminates generation at the byte boundary, so commentary never gets sampled. Pair it with a few-shot example where the assistant emits the terminator after the SQL, which trains the pattern to be self-anchoring: the model wants to emit the terminator because that is what the demonstrations show. **Layer 2, max_tokens.** The cost and latency guardrail. Size it for a generous but realistic SQL length (200 to 500 tokens for analytical queries, 50 to 100 for simple lookups). It exists to bound the worst case if everything else fails. It is not a primary control because the only way to make it suppress commentary is to truncate; that hurts legitimate long outputs. **Layer 3, post-hoc parser.** The edge-case net. Strip whitespace, take content up to the first terminator (or up to the first complete statement). This catches the cases where the model added leading prose ('Here is the SQL:'), did not emit the terminator, or wrapped the output in extra formatting. The system-prompt instruction ('return only the SQL, no commentary') is the orientation layer that makes the model prefer the right shape. It is necessary but not sufficient on its own, because production has long tails. The failure-mode mapping: instruction alone leaks on one in twenty edge cases; stop sequence alone fails when the model never emits the sentinel; max_tokens alone either truncates or does nothing; parser alone is brittle if the model output is highly variable. The four together compose into a reliable extractor.