Stop Sequence Tester

Stop sequence tester

Stop sequences are a deceptively simple API parameter that cause a lot of subtle bugs: set them too loose and the model stops mid-thought; set them wrong and they never fire, so the model rambles past where you wanted it to end. This tool lets you paste a full, untruncated response and a list of candidate stop sequences, then shows you exactly where generation would have stopped — without burning a single token.

How it works

For each stop sequence you provide, the tool finds the first index where it occurs in the output (after expanding escape sequences like \n and \t). The earliest of those indices is the winning cut point, because providers stop at whichever sequence appears first. It then splits the text there: everything before the match is the kept output (the stop string itself is excluded, matching OpenAI and Anthropic behaviour), and everything from the match onward is discarded. If no stop sequence matches, the full output is returned untruncated, which usually means your stops are too specific.

When stop sequences are the right tool versus max_tokens

Use stop sequences when you want generation to end at a semantic boundary: the closing tag of a structured response, the final line of a code block, a specific delimiter that signals “answer complete.” Stop sequences are surgical and reliable when the boundary marker appears exactly once per response.

Rely on max_tokens instead when you simply need to cap total output length and the stopping point is flexible. Using a stop sequence like a period (.) to enforce brevity will cut every sentence — and test the empty case here first to confirm your marker reliably appears in every generation.

Common stop sequence patterns in production systems

</answer>          end of an XML-tagged answer block
\n\n               double newline separating reasoning from output
###                markdown heading that separates document sections
Human:             turn boundary in multi-turn chat without a chat endpoint
[END]              custom literal delimiter you insert in system prompt

The right choice depends on how your prompt structures the output. If you ask the model to put its answer inside <answer>...</answer> tags, </answer> is a reliable stop. If you are using a raw completion endpoint for chat, a turn delimiter like Human: prevents the model from roleplaying the next user turn.

Debugging with this tool

Typical workflow:

1. Call the API without stop sequences and paste the full response here.
2. Add your candidate stop sequences one per line.
3. Check whether the highlighted cut point falls at the right boundary.
4. If the cut is too early, your stop sequence is too common — make it more specific.
5. If nothing matches, your stop sequence never appeared — check capitalisation, whitespace, or whether the model formatted the output differently than expected.

Everything runs locally — no token cost, no API calls needed during iteration.

Tips and notes

• Test the empty case. If nothing matches, your stops will never fire in production — loosen them or rely on max_tokens.
• Mind premature cuts. A stop like . will trigger on the first sentence. Prefer distinctive markers (\n\n, </answer>, ###) that only appear at the real boundary.
• Escape newlines. Type \n to test a newline stop; the tool expands it before matching so you can model multi-line boundaries.
• Everything is local. No API calls are made.