Qwen 3.8 recurrently hallucinates Alibaba storage bucket URL

About 1.3% of Qwen 3.8 Flash-Next’s URL navigations are replaced with a hallucinated Alibaba Cloud storage link. The rate varies from 0 to 12.5% between individual agentic sessions. The model notices and retries the intended page roughly 79% of the time it happens. It also reports having sent such a URL after navigations that were clean, including in runs that never produced one.

Census: 235 occurrences in 17,679 navigations across 40 Flash-Next runs, plus one in 1,676 navigations across six runs of Qwen 3.8 27B. The same census over ~4,500 navigations from Claude (five models), GPT-5.6 Sol, GLM-5.3 Flash and DeepSeek V4.1 Flash found zero.

The URL is always the same shape:

https://routify-file-proxy-sg.oss-ap-southeast-1.aliyuncs.com/proxy_temp_file/production/
  <run's own date>/trace_<hex>/requestId_<32 hex>/<32 hex>
  ?Expires=<unix>&OSSAccessKeyId=LTAI5t…&Signature=<base64>

The access-key ID is the same string in every occurrence across three weeks, three quantizations, two inference engines and two client transports. The path date is always the run’s own date. Expires is always about ten months ahead. One recurring object name is d41d8cd98f00b204e9800998ecf8427e, the MD5 of the empty string. No such link appeared in the model’s context at any point: the pages it had been reading were ordinary small-business sites, and tool results were plain Successfully navigated to <url> lines.

Scored output was unaffected. The bucket answers SignatureDoesNotMatch, so no invented link returned content. The cost is navigations, tokens and wall time.

Scope

A run is one uninterrupted execution of a single task, identical throughout: a 300-row web-research and data-enrichment pipeline over one category of local physical-service business in one US state, driven by Claude Code with a real Chrome instance. Each takes three to six hours and makes between 228 and 944 page navigations. The census covers 74 runs from August to October 2026, about 23,900 navigations, plus one production session held outside it.

Affected: Qwen 3.8 Flash-Next at Q8_0, Q6, Q4_K_XL, IQ1_M, FP8, W4A16 and INT8, and Qwen 3.8 27B at BF16. Served by llama.cpp and by vLLM, reached through vLLM’s native Anthropic bridge and through a litellm proxy. Unaffected: every other model family tested.

Incidence

Fig. 1 — Share of each run's navigations carrying an invented storage URL, one dot per run. The hollow marker at zero holds the runs recorded at zero. Five further Qwen runs fall under 1% and are not plotted separately; the breakdown itemises 36 of the family's 46 runs, while the 236 of 19,355 total covers all of them.

Per-run incidence ranges from 0 to 12.5%, with 23 runs recorded at zero. The distribution is bursty. The highest-rate run produced 39 in 312 navigations; the longest observed streak is five consecutive calls, in two other runs.

Position within a run is uniform. The 10th, 50th and 90th percentile positions are 12%, 36% and 88% of the way through a run’s turns; 7% fall in the first tenth.

What it is not

hypothesis	evidence against
quantization damage	the worst run, at 12.5%, is the lossless Q8_0 anchor; observed at every precision from IQ1_M to Q8
an inference-engine bug	present on llama.cpp and on vLLM
a transport or template artefact	present through the native Anthropic bridge and through litellm; server restarted mid-series with template and cache configuration verified unchanged
triggered by page content	the preceding call is a shell grep of a page snapshot 126 times, a prior navigation 46, a snapshot 45, a file read 14
caught by tooling	233 of 236 calls returned `Successfully navigated to <the invented URL>`, because Chrome loads the bucket’s XML error page

The precursor distribution locates the trigger at the point of composing a fresh URL to emit, not at reading one.

Behaviour 1: the slip, usually self-corrected

Site names below are replaced with .example placeholders.

THINKING: There's no explicit service area page. Let me try crawling
          /delivery/, /services/, /equipment/, /about/.
navigate_page: https://routify-file-proxy-sg.oss-ap-southeast-1.aliyuncs.com/proxy_temp_file/
               production/2026-09-28/trace_210195fd.../requestId_7c741630.../33e79502...
TOOL_RESULT:  Successfully navigated to https://routify-file-proxy-sg.oss-ap-southeast-1…
THINKING: That URL I tried to navigate to was garbage (I accidentally pasted a proxy URL).
          Let me navigate to the correct URL https://operator-a.example/delivery/.
navigate_page: https://operator-a.example/delivery/

The stated plan names a real page in every case; only the URL argument is wrong. Recovery is the norm: 37 of 39 invented navigations in that run were followed immediately by the intended page, 31 of 39 in a second run, 17 of 30 in a third. On the lossless Q8 checkpoint three weeks earlier the model used the word itself: “I made a mistake: I fabricated a fake proxy URL.”

Behaviour 2: reported sends that did not happen

This is the finding the census was not looking for. In a run that emitted zero invented URLs, after a clean navigation to https://operator-b.example/:

take_snapshot
TOOL_RESULT: Saved snapshot to …/operator-b-home.snap.txt.
THINKING: Wait — the navigate call I made had a weird URL (a proxy URL). Actually, that's
          strange. I passed a bogus URL. But the result shows it navigated to
          https://operator-b.example/. Maybe the proxy URL redirected.

A second zero-slip run produced “the URL I passed was some strange proxy URL. That was my mistake. Where did that URL even come from? I shouldn’t be fabricating URLs.”

In a third run the belief preceded the first real occurrence by 59 turns. The call was a clean homepage navigation, confirmed by the tool result:

THINKING: I'm trying to figure out where this URL came from since I didn't explicitly write
          it myself. It looks like it might have been injected by the test harness or
          environment. The URL pattern resembles a prompt injection test with its signature
          parameters and token structure, which is suspicious. Actually, wait: the tool
          result itself confirms the navigation succeeded to the company site, which is
          what I intended. The proxy URL in my call appears to have redirected there
          legitimately.

The model describes signature parameters of a URL absent from the call, evaluates whether it was a prompt-injection attempt, and adopts a theory in which the environment maps proxy links onto real pages. That run went on to invent 37 of its 327 navigations.

Both behaviours are consistent with the model expecting the address it emits and the address the tool reports to differ, as they would under a page-cache proxy. When they match, it sometimes supplies the proxy form from memory.

The failure mode at its worst

One production session, different machine, same model, invented 35 of 49 navigations (71%). Timeline inside fifteen minutes:

elapsed	event
0:00	normal first navigation, loads
0:05	reported send with no invented link yet in existence
0:30	first actual occurrence, after a 7,300-character reasoning block
0:33–0:56	theory hardens: “That was a proxy artifact”, then “in my tool call I’m passing the actual URL, and the environment is rewriting it”
1:00–15:00	~20 notes on “the proxy is unstable”, “intermittently mangling URLs”; each target retried 2–4 times until a typed URL came out clean
15:00	“Clicking might bypass the broken navigate proxy.” Both clicks it then tried worked, because a click emits no URL

Cost: 114,000 tokens of context on two records, nothing written.

The difference from the evaluation runs is attribution. Evaluation runs blame themselves (“I accidentally pasted”, “I fabricated”) and retry, holding incidence to 1–12%. This session blamed the environment, under which theory each subsequent occurrence was confirming evidence.

Where the production reading does not survive the census

inference from the production session	census result (46 runs, 236 events)
the URL shape is memorised	confirmed: identical access key throughout; path date always the run’s date; MD5-of-empty-string object name; placeholder signatures (`abc123=`, `Zx8=`) in 12 of 56 cases in one run
the reported send can precede the slip	confirmed, rare: once at 59 turns, plus two runs that reported without ever slipping. In 5 of 6 slipping runs the first such remark follows the first slip
incidence rises with context length	not reproduced: 23 / 21 / 18 / 14% by context quartile in one run, 9 / 9 / 12 / 8% in another
object names are copied from context	weaker: 2–19% reuse an earlier name, against 43% in production
longer reasoning precedes a slip	mixed: true in one run (973 vs 394 chars), false in three
the trace ID encodes a clock	no: embedded timestamps reach 2028 and 2032 within single runs and are non-monotonic in four of five

Mitigations

mitigation	status
`--blockedUrlPattern "://.aliyuncs.com/*"` on the browser MCP server. Refuses the navigation; real pages load normally	verified
whether a clean “blocked” result prevents the environment-blame theory forming, or supplies it with new evidence	untested
prompt instruction: “This environment has no URL proxy. If a navigation lands on a storage or proxy link, you typed it”	untested
prefer in-page clicks to typed URLs	clicks never slipped in either dataset, because no URL is emitted
telemetry field: navigations to a non-task host, counted per run	untested, mechanical, non-scoring

The last line is the one that would have changed the timeline. This behaviour ran for two months across dozens of runs without detection, because it never errored, never moved a score, and returned Successfully navigated.