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 what tells the API to stop generating tokens at a specific byte boundary. For structured extraction (invoice fields, JSON records, code blocks) a distinctive marker like `END_INVOICE` is much safer than relying on a paragraph break or whatever the model produces naturally. **Reason one: paragraph breaks appear inside invoices.** Real invoice text has blank lines between addresses, between line items, between the header and the totals block. If you use a blank line as the terminator, generation cuts off the moment the model produces the first internal blank line, mangling the record. A custom marker that is structurally impossible inside real invoice text avoids this. **Reason two: few-shot examples train the model to emit the marker.** If every example in your prompt ends with `END_INVOICE`, the model learns that the right shape is to emit `END_INVOICE` after the fields. The marker becomes self-anchoring: the model wants to produce it because the examples show it. **Reason three: it decouples the termination contract from the format.** Adding a new field later (a payment_terms line) does not change the terminator. Format-specific terminators (a closing JSON brace, an end of paragraph) are tied to the format and have to be revisited every time the format changes. **Reason four: it composes across tasks.** If your prompt extracts an invoice and then a summary, distinct terminators (`END_INVOICE` and `END_SUMMARY`) make the boundaries unambiguous. Reusing one terminator across tasks creates ambiguity. Finally, the marker on its own does nothing unless you pass it to the API's `stop_sequences` parameter. The API parameter is what cuts generation at the boundary. The marker design is what trains the model to emit the boundary in the first place. Both together is the working pattern.

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 as the terminator means the first internal break ends generation prematurely. A multi-character marker like `END_INVOICE` or `</invoice>` is structurally impossible 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. The terminator becomes part of the output the model wants to produce, which gives you 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. The extraction can grow with new fields (payment_terms, currency, billing_period) while the termination contract stays stable. Format-coupled terminators have to be revisited every time the format changes. **Composability.** Distinct terminators per output type (`END_INVOICE`, `END_LINE_ITEM`, `END_SUMMARY`) let you compose prompts that handle multiple records without ambiguity. **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). 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 distinctive stop sequence eliminates all three because the API cuts generation at the boundary regardless.