In a few-shot prompt that extracts structured fields from invoices, why is a distinctive stop sequence (like a custom END_INVOICE marker) better than a paragraph break or the natural end of response?

A stop sequence is a string that tells the API to stop generating as soon as the model writes it. For structured extraction (invoice fields, JSON records) a distinctive marker like `END_INVOICE` is much safer than a paragraph break or whatever the model produces naturally. **Reason one: paragraph breaks appear inside invoices.** Real invoices have blank lines between addresses, line items, and the totals block. A blank-line terminator stops generation at the first internal blank line, cutting the record short. A custom marker is very unlikely to appear inside real invoice text. **Reason two: few-shot examples train the model to emit the marker.** If every example ends with `END_INVOICE`, the model learns to emit it too, so the marker becomes self-anchoring. **Reason three: it does not depend on the format.** Adding a new field later (a payment_terms line) does not change the terminator. A closing JSON brace, by contrast, has to change whenever the format does. **Reason four: it composes across tasks.** Distinct terminators (`END_INVOICE` and `END_SUMMARY`) keep the boundaries between record types clear. Finally, pass the marker to the API's `stop_sequences` parameter. That is what cuts generation. The examples teach the model to write the marker. You need both.

A distinctive stop sequence wins on four properties: collision safety, self-anchoring through few-shot, decoupling from the format, and composability across tasks. **Collision safety.** Paragraph breaks routinely appear inside invoice content (addresses, line items, descriptions). A blank-line terminator ends generation at the first internal break. A multi-character marker like `END_INVOICE` or `</invoice>` is very unlikely inside real text. **Self-anchoring.** When every few-shot example emits the terminator after the fields, the model learns the shape: extract fields, then emit the marker. This adds training-side reinforcement on top of the API-side stop. **Decoupling from the format.** A custom terminator does not change when you add a field such as payment_terms, so the termination contract stays stable. **Composability.** Distinct terminators per output type (`END_INVOICE`, `END_SUMMARY`) keep record boundaries unambiguous when prompts are composed. **The implementation pairs three pieces.** The marker design (what the sentinel looks like). The few-shot demonstration (every example ends with it). The API control (pass the marker to `stop_sequences` on Anthropic or `stop` on OpenAI; OpenAI's o3 and o4-mini do not support `stop`). The marker alone does not enforce anything; the API alone does not train the model to emit it. **The natural-end alternative fails three ways.** The model adds trailing commentary. `max_tokens` truncates mid-record. The model rambles when unsure about a field. A stop sequence removes the first, because the API cuts generation as soon as the marker appears. It cannot prevent truncation or rambling before the marker. A sensible `max_tokens` budget and a parser fallback cover those.