Context and Cost Control
Prevent unbounded chat history from consuming credits unexpectedly.
Chat Completions is stateless. GLM 5 does not remember an earlier API call unless
your application includes that history again in messages.
That makes context management an application responsibility—and the most important cost control for long-running chats and agents.
How repeated history is billed
Consider a conversation whose input grows on every turn:
| Call | Messages sent | Input tokens billed |
|---|---|---|
| 1 | Current user message | 1,000 |
| 2 | Call 1 history + current message | 3,000 |
| 3 | Calls 1–2 history + current message | 7,000 |
| 20 | Complete accumulated history | 80,000 |
The model sees and processes every token included in each request. Earlier messages can therefore be billed repeatedly.
Do not append history forever
Long-running clients can move from tens of thousands to hundreds of thousands
of input tokens in a short period. Track usage.prompt_tokens, keep a bounded
history, and summarize or discard older turns before sending the next request.
Recommended strategy
Keep a token budget
Choose a maximum input budget for your application before sending a request. When history approaches that budget:
- Preserve the system message.
- Preserve the latest user request.
- Preserve complete assistant tool-call and tool-result pairs.
- Keep the most recent useful turns.
- Summarize or remove older turns.
A message-count limit alone is unreliable because one message can contain far more tokens than another.
Summarize old turns
Replace older history with a compact system-level summary:
[
{
"role": "system",
"content": "You are a technical assistant. Conversation summary: the user is deploying a Next.js API on Cloudflare, requires zero-downtime rollout, and has not yet configured rollback alerts."
},
{
"role": "user",
"content": "Now write the final deployment checklist."
}
]
Summaries can omit details, so retain recent messages and important identifiers verbatim.
Start a new conversation
If earlier context is no longer relevant, send only the current system and user messages. This is both cheaper and less likely to distract the model.
Control output reservation
Before a request reaches the model, GLM 5 reserves credits using:
- The estimated input.
- The requested maximum output when one is supplied.
- An internal 8,192-token billing estimate when no output cap is supplied.
The internal estimate does not truncate the response. If neither
max_completion_tokens nor max_tokens is supplied, the selected model uses
its default output behavior. For short answers, set a smaller explicit value:
{
"model": "glm-5.3",
"messages": [
{
"role": "user",
"content": "Return a five-item checklist."
}
],
"max_completion_tokens": 600
}
The reservation is reconciled against actual usage after completion. Unused reserved credits are returned, but a large maximum can still cause a low-balance request to fail its preflight reservation.
Model-specific context limits
GLM 5 does not enforce one global token context window across every model. Context and output limits can vary by model.
If the API returns context_length_exceeded, shorten or summarize the history,
reduce tool definitions, or set a smaller output maximum.
Monitor usage
A non-streaming response includes:
{
"usage": {
"prompt_tokens": 42215,
"completion_tokens": 186,
"total_tokens": 42401
}
}
Useful safeguards include:
- Warn at 50%, 75%, and 90% of the application's context budget.
- Log input and output tokens per request.
- Set per-user or per-workflow spend limits.
- Alert on repeated growth across consecutive requests.
- Stop automated loops after quota or validation errors.
Context caching: helpful, but not a guardrail
Some models and API systems can reuse an identical prompt prefix from an earlier request. This is commonly called prompt caching or context caching. It works best when the system prompt, tool definitions, and older messages remain byte-for-byte identical.
Caching can improve latency or cost efficiency, but it does not:
- Remove old messages from the request.
- Stop the context window from growing.
- Guarantee a cache hit after content changes or cache expiry.
- Make repeated tokens free.
Current GLM 5 behavior
GLM 5 currently reports prompt_tokens, completion_tokens, and
total_tokens. It does not expose a cached_tokens field or discount GLM 5
credits for cache hits. Manage history and enforce token budgets even if your
client supports context caching.
For comparison, Z.AI context caching
reports cached input separately and applies a lower cached-token rate. A similar
implementation in GLM 5 would need to record cached tokens, expose them in
usage.prompt_tokens_details.cached_tokens, and pass the discount through to
credit settlement.
Request-size limit
The JSON body limit is 4 MB. This transport and memory protection remains in place, but it is not a token context limit. Requests below 4 MB can still fail if they exceed the selected model's context limit.