Stop Sequence Tester

See exactly where your stop strings fire in a sample output, which one wins, and what the API would return.

Stop sequencesOne per line. \n, \r, \t and \\ are decoded, so you can paste them as they appear in your JSON body. This list travels in the URL.

A sample outputMatched in this tab; nothing is uploaded.

Keep the stop string in the returned textProviders differ. Most exclude it; some include it; check yours rather than assuming.

Fires at

character 111

"\n\nQuestion:" matched first, at line 2, column 68. 69.8% of the text survives.

Sequences configured: 2
Sequences that match at all: 1
Total matches in the sample: 1
Characters kept: 111 of 159
Estimated tokens before: ≈ 55
Estimated tokens after: ≈ 36

"\n\nQuestion:"1× — first at 111
"###"never

"\n\nQuestion:" has leading or trailing whitespace. Whitespace is usually attached to the neighbouring token, so a stop that depends on it is the most common one that never fires.

What the API would return

Question: What does the retry budget cover?
Answer: It covers transient failures only — timeouts, 429s and 5xx.

What this assumes: stop sequences are matched here on the decoded text with a plain substring search, earliest match wins, which is how the major APIs document the behaviour. Two things this cannot model: whether your provider includes the stop string in the returned text — hence the toggle — and the tokenizer. A provider matching on token IDs rather than characters can miss a string that spans a token boundary, and can bill you for the tokens generated after the match but before the cut. Token counts are estimates. Estimated, not tokenized. A real count needs the model's vocabulary; the authoritative number is usage.prompt_tokens on the response.

Stop sequences fail in one direction, quietly

The failure that costs time is not a stop sequence that does not fire; it is one that fires somewhere you did not look. A sequence like \n\n is a reasonable way to end a single-paragraph completion and a catastrophic one the moment the model produces a list, because the list’s first blank line ends the response. The result is a truncated answer with finish_reason: stop, which looks exactly like a model that finished, so nothing alerts and the bug gets attributed to the model. Paste a few real outputs above and look at the match counts: any sequence matching more than once in normal output is a bug waiting for the right input.

The second trap is whitespace. Tokenizers usually attach a leading space to the following word, so a stop string that starts with a space may never exist as a boundary in the generated text even though it appears in the rendered output. Prefer sequences that begin at a newline or a punctuation-like marker, and prefer distinctive markers to short ones.

Worth remembering on the bill: the stop happens at the provider, but the tokens generated up to and including the match are generated, and are normally billed. Stop sequences are an output-formatting control, not a cost control. If the goal is a shorter answer, ask for a shorter answer and cap max_tokens.

Stop Sequence Tester

Stop sequences fail in one direction, quietly

The reasoning behind this

Related tools