Spot the errors in this stop-sequence configuration recommendation

**Stop sequences** tell a model when to halt generation. The naive picture is: pick the token ID for your stop string, then halt the moment the model emits that ID. The recommendation in the question is built on that picture, and every claim it makes is wrong. The first error is the matching mechanism. Production runtimes do not compare token IDs. They decode recent output back into text and check whether the resulting string ends with one of your stop sequences. Matching happens on the readable string, not on the integer IDs. The second error is that a string has one stable token ID. It does not. BPE tokenizers are context-sensitive: 'Human:' at the start of a sequence, after a space, or after a newline can each become different token IDs. Matching on a single ID misses most of the cases you actually care about. The third error is that whitespace is ignored. It is not. The runtime matches the literal string, so a leading newline in '\nHuman:' is significant. That anchor is exactly what stops the model only at a real turn boundary instead of mid-sentence. The practical danger sits underneath all three. If your stop never matches and you set no max_tokens, the model generates until the context window fills, billing every wasted token.

All three claims are wrong, and together they describe a config that risks runaway generation. **Stop sequences** are matched against the detokenized output string, not against token IDs. The runtime decodes recent tokens back to text. It checks whether that text contains a stop sequence. Then it truncates the output before the stop and halts. It works this way because tokenization is context-sensitive. The same substring maps to different token IDs depending on the preceding character. So 'Human:' at a sequence start differs from 'Human:' after a space. Matching on one ID would silently miss most real occurrences. Whitespace is significant, not ignored. A leading newline in '\nHuman:' anchors the stop to a turn boundary. That prevents false halts when 'Human:' appears mid-content. The runtime matches the literal characters exactly. The deeper failure is operational. Stop sequences are advisory, so a robust config also relies on the model's own EOS token and always sets a hard max_tokens cap. Omitting both is the classic cost-blowup bug. The model keeps generating to the context limit, and you pay for every token. Stop strings shape where output ends; max_tokens is the guaranteed circuit breaker.