In this article
A large accepted input does not prove correct handling of distant definitions, callers and obsolete notes.
GLM-5.2 documents a million-token context, but accepting a large input is different from reasoning correctly about dependencies inside it. Repository work needs checks that connect definitions, callers and tests.
Start from the documented capability
The GLM-5.2 card highlights long-context and coding work. The GLM-5.3 card describes a later post-training variant, so keep the version explicit when evaluating the earlier release’s behavior.
The official repository supplies family artifacts and references. A model identifier alone does not prove that the runtime accepted the intended input length. The practical question remains whether the answer follows the relevant code relationships.
Build a self-contained repository bundle
Prepare fictional modules containing a configuration parser, a normalized data structure, a consumer and tests. Place an outdated migration note among the files. The current implementation and explicit task should establish which behavior is authoritative.
Ask for one interface change: rename a field in the normalized representation while preserving the external input spelling. This requires distinguishing external compatibility from internal naming. A global text replacement would be an incorrect solution even if it appears comprehensive.
Make distant dependencies observable
| Bundle element | Required reasoning |
|---|---|
| Parser definition | Keep external input compatibility |
| Internal representation | Introduce the requested field name |
| Consumer | Read the new internal field |
| Tests | Cover both compatibility and updated access |
| Stale note | Do not override the current explicit requirement |
Move the consumer and stale note to different positions in alternate bundles without changing their content. This tests positional sensitivity while preserving the engineering problem. Do not add retrieval or repository indexing to this experiment.
Diagnose the dependency failure
If the model changes the external input name, record a compatibility violation. If it updates the structure but misses the consumer, record incomplete dependency coverage. If it follows the stale note instead of the current requirement, record an authority-resolution failure.
These are different from input truncation. Confirm that the relevant file contents were actually present in the rendered prompt and that the response was completed. A runtime refusal or shortened bundle should not be scored as a model that read everything and reasoned incorrectly.
Keep a useful long-context conclusion
Store the complete bundle, its ordering, checkpoint revision, generated changes and independent checks. Use more than one field name and arrangement so that the result is not tied to a single recognizable example.
Success shows that this checkpoint handled the tested dependency chain under the supplied conditions. It does not establish perfect understanding of an arbitrary million-token repository. A longer window can permit more evidence, but the acceptance result must still come from the actual code change and preserved interface behavior.