Reliable API Output Needs Two Different Stopping Rules
Output boundaries work best with separate responsibilities
A response that ends is not necessarily a response that finished. An API can stop generating because the model completed its answer, encountered a configured stop sequence, or exhausted its output allowance. Those endings need different treatment. Reliable integrations assign each control a clear job: stop sequences mark application boundaries, while maximum token limits place a ceiling on generation.
This walkthrough builds those controls around a simple task: generating a short support reply that another service will insert into an email. The same approach applies to summaries, extraction tasks, and conversational interfaces.
First define the answer your application needs
Start with the deliverable rather than a token number. For the support reply, specify a greeting, a direct answer, and one next action. Request a concise response in ordinary language. That instruction guides the model toward a useful length; the output limit protects against excessive generation.
Keep these responsibilities separate. A request for three sentences is a content instruction, not a guaranteed boundary. Likewise, a low token ceiling cannot ensure that the model includes all three required parts before generation stops.
Next confirm the selected endpoint supports stopping
Check the capabilities of the exact model and endpoint before choosing request controls. Parameter names, supported stop sequences, and output limits differ across providers and model families. An OpenAI-compatible interface does not guarantee that every optional parameter has identical behavior everywhere.
BestRelay forwards each request to the official model named in it, without substitution, across families including Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, and Grok. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDKs. That shared access is useful, but your integration should still validate the selected model's controls. Create a BestRelay account to try this workflow with your chosen model.
Choose an output ceiling with measured headroom
Generate representative replies with a generous initial allowance, then inspect their reported token usage and completeness. Include difficult cases: long customer questions, unusual terminology, and replies requiring several qualifications. Use the observed distribution to choose a ceiling that accommodates successful answers with reasonable headroom.
Tokens are not words, and their relationship changes with language and content. Some reasoning models also count internal reasoning within an output budget, depending on the API. A ceiling that comfortably fits the visible reply can therefore still be insufficient. Confirm the provider's accounting before interpreting an unexpectedly short response.
Add stop sequences only for explicit boundaries
A stop sequence makes sense when your workflow has a recognizable boundary beyond the desired content. For example, you might instruct the model to place a distinctive closing marker after the support reply and configure that marker as a stop sequence. APIs commonly omit a matched marker from returned text; verify the endpoint's documented behavior.
Choose a marker unlikely to appear naturally in the answer. Common punctuation, a blank line, or a familiar word can cut off legitimate content. Stop sequences generally match text rather than meaning, so test capitalization and whitespace instead of assuming equivalent forms will match. The model can also omit the marker, which makes completion checks necessary.
Inspect the termination reason before accepting output
Check the response's termination metadata alongside its text. A token-limit ending signals possible truncation, even when the last sentence looks plausible. Validate that the reply contains the required answer and next action before inserting it into an email.
For streaming responses, wait for the final termination information before marking the reply complete. If you implement application-side stopping, buffer enough trailing text to recognize a marker split across chunks. Your own string matching does not guarantee that upstream generation stops or that billing stops immediately.
Adjust budgets using failures and reported usage
Track truncation, premature stops, missing markers, and typical output usage. Raise the ceiling when valid answers repeatedly hit it; revise the prompt when replies become unnecessarily long. Change one control at a time so the results remain interpretable.
BestRelay bills pay as you go using provider-reported token counts, with cache reads and writes priced separately. Use those usage details when evaluating cost; a configured ceiling is not a prediction of actual charges. Members also earn referral commission when invited users top up, a separate account benefit that does not change the output budget your application needs.
Want to try the models discussed here? Sign up