[Bug] GLM-5.3-Flash spontaneously emits Chinese text mid-response in English agentic contexts (survives context reset)

[ZinkDifferent]

Bug Report

Model: GLM-5.3-Flash (cloud, via Ollama provider, ollama-cloud endpoint)
Context: Long-running agentic assistant (Hermes Agent framework), English-only user, multi-hour sessions with tool use

Description

GLM-5.3-Flash spontaneously emits Chinese characters mid-response during English conversations, in two distinct patterns:

1. Inline CJK token bleed — isolated Chinese words embedded inside otherwise-English sentences. Observed twice in one session: 日志 (log/journal) and 黔.
2. Full Chinese sentences/lines replacing the expected English transitional text. Observed: 已验证托管，HTTP 200。正在使用 URL 引用重新触发两次生成 (intended: 'Hosted and verified, HTTP 200. Re-triggering two generations using URL references').

Reproduction

Frequency: 4 events across 2 independent sessions over 6 days (Aug 28 – Sep 3, 2026), model active roughly 16h/day in agentic loops.

Key observations:

• All prior context, system prompt, and user messages are entirely English
• No Chinese content referenced anywhere in the conversation
• Event 4 occurred in a FRESH session (full context reset + gateway restart) within 7 minutes of session start — this rules out context contamination/caching as the cause
• The affected turns were agentic tool-loop turns (long outputs, interleaved tool calls), not short chat turns
• Trigger content appeared Chinese-adjacent in at least one event (URLs on a .me domain, no .cn content in others)

Prior art

Issue #54 reported the identical defect on GLM-5.1 (closed as completed). This report documents that the defect class persists in GLM-5.3-Flash, the current flagship Flash tier served via Ollama Cloud.

Expected behavior

When system prompt and conversation are entirely English, the model should never emit CJK codepoints in responses, regardless of content associations or output length.

Environment

• Provider: Ollama Cloud (ollama-cloud), model glm-5.3-flash
• Framework: Hermes Agent (Nous Research) Discord gateway
• Sessions: multi-hour agentic workflows, 60M+ input tokens/month
• reasoning_effort: xhigh

Suggested fix

Strengthen language anchoring in the output path for GLM-5.3-Flash: when the active conversation language is English, enforce language consistency for the full response span, particularly in long agentic generations. Alternatively, document a supported decoding-level CJK filter for English-locked deployments.

Relevance

For agentic deployments serving English-only users (our case: a production assistant), any CJK leak is a hard correctness failure. We are currently evaluating a gateway-level output filter as a mitigation; filing this so the root cause gets tracked upstream.

[ZinkDifferent]

Update: the defect is not CJK-specific — it generalizes to foreign-language token bleed

Additional documented events beyond the CJK ones in the original report:

• German inline bleed: Kündigung (termination/cancellation risk) embedded mid-sentence in an otherwise-English financial analysis (Mercury-vs-Chase comparison), Aug 29 22:52 PDT. Notable: the user reads German fluently and still flagged it — the failure is the unprompted code-switch itself, not comprehension.
• CJK inline bleeds (from original report): 日志, 黔 — same session pattern.

Full observed history (6 days, 5 events):

1. 日志 inline in English response (Aug 29 ~01:00)
2. 黔 inline (Aug 29 01:15)
3. Kündigung inline, German, Latin script (Aug 29 22:52)
4. Full-Chinese transitional sentence (Aug 28, separate session)
5. Full-Chinese transitional line (Sep 3, post context-reset + gateway restart — rules out context contamination)

Refined pattern:

• Chinese is the most frequent bleed language, but Latin-script foreign words (German) bleed too — this is a general language-anchoring weakness in the output path, not a CJK tokenizer artifact
• Both script families appear in longer analytical/agentic output under heavy context; short replies have been clean
• The Latin-script case is arguably worse in practice: CJK characters are visually obvious in English text, but a German word inside an English sentence reads as a typo or gets past un-noticed by non-German readers

This strengthens the language-anchoring framing of the suggested fix: the model needs output-span language consistency for the conversation's dominant language, independent of script. A CJK-only filter would have missed event 3 entirely.

[Dovis01]

Hi @ZinkDifferent

Thanks for the detailed report and follow-up investigation, and sorry for the poor experience this caused in your long-running agentic workflows.

We’ve shared this issue, including the additional cross-language token-bleed cases, with the relevant internal platform/model teams for further investigation. The fact that the behavior can still occur after a fresh context reset, and is not limited to CJK output, is particularly useful signal.

We’ll continue to improve language consistency and output stability for long-context and agentic scenarios in future updates.

Thanks again for the thorough reproduction details and for helping us track this down.

[arkham2424]

Hi @Dovis01
I have this similar issue using GLM 5.3 as well, so its not an unique problem with GLM 5.3-Flash. Along with language switches, it has shown to have random train of thought unrelated to the session, in chinese.

Would appreciate if you could look into this as well.

[ytjohn]

In my testing, it happens after tool calls. Saying "reply in english" works for a turn or two, and same with putting that in AGENTS.md. The first turn will be in English, but once GLM 5.3-Flash starts performing tool calls, it will quickly flip to CJK on the subsequent turns.

I originally though this was a bad provider on openrouter, but I switched direct to z.ai and encountered the same behavior.