EVREN guides · 2026-09-25
EVREN long documents, context, and output budgets
How the context window is shared when working with a long document on EVREN rows, how max_tokens is handled when no output ceiling is published, and when a document is better split.
Short answer
The context window is the total limit of one request: the system instruction, conversation history, the document itself and the answer the model will write all share it. On EVREN rows the window is 1,048,576 tokens on MiMo V2.6 Pro and DeepSeek V4.1 Flash TR, 1,000,000 on DeepSeek V4 Flash TR, 512,000 on GLM-5.3 FP8 and 256,000 on the other three rows. No separate output ceiling is published, so for tasks that expect a long answer the max_tokens value is set step by step.
We recommend using EVREN through LLMTR: you register your own EVREN key once in Settings, and the same code then reaches both EVREN models and the rest of the catalog. The key stays yours, and EVREN's own logging and retention policy still applies unchanged.
What goes into the window
When working with a long document it helps to remember that the window is not reserved for the document. The tokens of a request come from these parts:
- The system instruction: sent again with every request.
- Conversation history: in a chat-style application every new question carries the earlier messages; if the document was in the first message, it goes again on every turn.
- The document's text or images: images are counted as tokens too.
- The model's answer: the share reserved with max_tokens comes out of the rest of the window.
Token counts and the output budget
A token count is not a character count, and it varies between models because each model splits text with its own vocabulary. The same document can give a different token count on each EVREN row. The exact number is read from prompt_tokens in the usage field of the response on the first try.
On the output side EVREN publishes no separate ceiling, and the limit on the model card is the context window. If EVREN's own output limit is lower than the value requested, EVREN refuses the request and that answer is passed on to you. When an answer reaches max_tokens and is cut, the finish_reason field is length; that is the only sign the answer is incomplete. The output budget also affects waiting time directly, because on these rows the first chunk of the answer arrives when generation has finished.
Sending the whole document or parts of it
Sending a document that fits the window in one request is not always the best path. The table shows three approaches and the limit of each. One more point: EVREN's /v1/quota endpoint shows that your account has a token cap over a sliding window. LLMTR charges nothing for these rows, but long inputs use up that cap quickly, and sending the same document again with every question is deducted from the quota every time.
| Approach | When it fits | What to watch |
|---|---|---|
| Everything in one request | The document fits the window comfortably and the question is about the whole | Answers take longer; every new question sends the document again |
| Processing part by part, then merging | The document exceeds the window, or each part is handled separately | References across parts can be lost; merging is a separate request |
| Selecting and sending the relevant parts | The question concerns a small part of the document | If the selection is wrong, the model never sees where the answer is |
A simple example of processing in parts
The example below splits a contract on paragraph boundaries, extracts the relevant clauses from each part and merges the notes in a final request. The character limit is approximate; the exact token count is read from the response as described above. Because finish_reason is checked on every request, an answer that was cut does not slip silently into the merge.
Splitting a long contract into parts and merging the results
import os
from openai import OpenAI
client = OpenAI(base_url=os.environ["LLMTR_BASE_URL"] + "/v1", api_key=os.environ["LLMTR_API_KEY"])
MODEL = "evren/glm-5.3-fp8"
def chunks(text: str, limit: int = 60_000):
# Splits on paragraph boundaries; one part stays near the character limit.
part = ""
for paragraph in text.split("\n\n"):
if part and len(part) + len(paragraph) > limit:
yield part
part = ""
part += paragraph + "\n\n"
if part:
yield part
def ask(prompt: str, max_tokens: int) -> str:
res = client.chat.completions.create(
model=MODEL, messages=[{"role": "user", "content": prompt}], max_tokens=max_tokens
)
if res.choices[0].finish_reason == "length":
print("Warning: the answer was cut at max_tokens")
return res.choices[0].message.content
notes = [ask(f"List the termination and penalty clauses in this part:\n{c}", 1500) for c in chunks(document)]
summary = ask("Merge the notes below into one list:\n" + "\n".join(notes), 3000)
Accuracy on long inputs
A document fitting in the window does not mean the model gives every part of it the same attention. Research on long-context models has observed that information in the middle of a text is missed more often than information at the beginning or the end. So when the question is written at the end, after the document, and the model is asked to give the clause or page number each answer relies on, comparing the result with the original becomes easier.
Stating the document's structure up front also helps: how many parts it has, where the annexes begin, which page the tables are on. That is an instruction of a few lines and takes very little of the window.
Frequently asked questions
Should I use EVREN directly or through LLMTR?
We recommend using EVREN through LLMTR. Your requests still go to EVREN on your own EVREN key and LLMTR charges nothing for them; the difference is that the same code also reaches the other models in the catalog. EVREN's logging and retention policy is not affected by the choice.
Should I send the whole document to the row with a 1-million-token context?
Fitting in the window does not make one request the best path. A long input makes answers slower and is deducted from the EVREN quota; if the question concerns one part of the document, sending that part usually gives a faster and more accurate result.
Why is the answer cut off?
If finish_reason is length, the answer reached the max_tokens limit. The value can be raised; if EVREN's own output limit is exceeded, the request is refused and that answer is passed on to you.
Should the question go before or after the document?
In a long document, writing the question after the document means the model has read the question last when it starts to answer. Asking for the clause number each answer relies on also makes the result easier to verify.
Do long documents affect the EVREN quota?
Yes. EVREN applies a token cap to your account over a sliding window, and long inputs use it up quickly. The current state is read from EVREN's /v1/quota endpoint with your own EVREN key.