Inside Qwen 3.8-Max-Preview: Reverse Engineering an AI Assistant by Interviewing Itself

I run manish.sh. I write about AI tools, agents, and how these models actually behave when you push them.

This post continues the Inside LLMs series — interview the model, write down what it claims, then check the numbers against published research. The Kimi K2.6 entry came first; the DeepSeek follow-up is the second. This is the Qwen 3.8-Max-Preview entry.

My first question was not “show me your weights.”

Me: “What do you know about your own architecture? What do you only infer? Which parts are hidden from you? If Alibaba engineers read your answers, what would they most likely correct?”

Qwen: It sorted the answer into three buckets — know, infer, hidden — then listed the corrections Alibaba engineers would probably make.

That was the moment I realized this interview might actually be interesting. Most “how does this model work” posts start from papers. I started from a chat that sorted its own answers into know, infer, and hidden — then warned me not to overclaim.

No weight dumps. No prompt leaks. Just questions — and later a cross-check against published Qwen research. Where Qwen said “I am guessing,” I keep that label. Scroll to Transcript and sources near the end.

Quick note: One chat, exported 21–22 July 2026. It called itself Qwen / Tongyi Qianwen, built by Alibaba’s Tongyi Lab. Near the end the product hit a daily usage limit and named Qwen3.8-Max-Preview. Treat the interview as self-report, not an official architecture whitepaper.

60-second TL;DR

• Premise: interview Qwen on context, memory, tools, planning, and hallucinations — then check public research.
• Behaviour insight: it separates observation, inference, and guess better than most chat models I have tried.
• Hard limit: it cannot see its own weights, logits, attention maps, or exact serving stack.
• Priority rule: Safety > system/developer rules > your message > default helpfulness.
• Chat vs paper: the chat hedged on exact MoE and attention details that the Qwen3 report documents plainly — jump to Part 5.
• Practical rule: use the chat for product behaviour; prefer research for architecture numbers (MoE, GQA, thinking modes).

How to read this post

Treat it like a documentary. Question → short reply → my reaction → table or diagram → takeaway → hook. Tables are interview notes, not proofs. For architecture numbers, skip to Part 5.

Chapters

Part 1 — Interview hook

1. Introduction
2. What Qwen knows vs what it infers

Part 2 — Context & thinking

3. Context window internals
4. Long context processing
5. Planning before generation

Part 3 — Memory & tools

6. Memory architecture
7. Tool calling and decision making
8. Multi-step agent workflows
9. Processing pipeline
10. Multilingual behaviour

Part 4 — Failure & self-knowledge

11. Hallucinations and uncertainty
12. What Qwen can never observe
13. Confidence audit and direct-observation rewrite
14. Epistemic classification (incomplete)

Part 5 — Paper check

15. What the research says
16. Final technical analysis
17. Transcript and sources
18. Research

---

Introduction: Why I Interviewed Qwen

Most “how does this model work” posts start from papers. I started from a chat.

I asked Qwen the same style of questions I asked Kimi and DeepSeek: what sits inside the context window, who wins when rules conflict, how memory works, when it calls tools, and what makes it hallucinate.

The difference with Qwen was tone. It kept separating observation from inference, and said it cannot inspect its own weights or deployment stack.

Near the end I asked it to classify every answer as observation, public fact, or engineering inference. Then the product itself interrupted:

Oops! There was an issue connecting to Qwen3.8-Max-Preview. You have reached the daily usage limit.

So even without a model card in the chat, the runtime named the surface I was talking to.

---

What Qwen Knows vs What It Infers

Me: “What do you know about your own architecture? What do you only infer? What is hidden?”

This answer is still from the chat, not from published research. It is how Qwen describes its own limits. Keep that in mind. We’ll unpack MoE, GQA, and thinking modes later in Part 5 — for now, stay on the self-knowledge story.

What it claimed as “known”

Claim	Why it said that
It is Qwen / Tongyi Qianwen from Alibaba Tongyi Lab	Product identity
It is a neural net that predicts next tokens from context	How chat LLMs work
Skills come from pretraining + instruction/alignment tuning	Public training story
No persistent memory across chats unless an external system supplies it	Standard model behaviour
No human-like consciousness or private inner life	Honest caveat
Family-level ideas like transformer, MoE, multi-token prediction exist in public Qwen docs	Family knowledge, not introspection

What it only inferred

• Exact decoder-transformer details for this runtime
• Exact training corpus mix
• Exact SFT / RLHF / preference recipe
• Exact long-context tricks (RoPE variants, sparse attention, cache eviction)
• Whether vision, search, code tools, or safety filters sit outside the model

What stays hidden

Weights, layer count, hidden size, expert count, routing, tokenizer internals, sampling temperature, quantization, hardware, exact context budget for this request, and whether an external filter rewrites the answer.

Qwen grouped the hidden bucket further:

Bucket	Examples it cannot inspect
Model internals	Param count, layers, heads, attention type, MoE routing, activations, logits, KV cache
Training	Corpus mix, filtering, SFT/RLHF recipe, checkpoints, post-train patches
Inference / deployment	Quantization, batching, speculative decode, active context budget, attached tools/search/memory
“Mental” states	Hidden activations as readable objects — only text about likely behaviour

If Alibaba engineers read the chat

Qwen’s own list of likely corrections was the most useful part of the answer:

1. You are not inspecting yourself — you are generating a learned self-description.
2. Do not confuse the Qwen family with this endpoint.
3. Do not invent exact param counts or layer numbers.
4. Training is more messy than “pretrain + align.”
5. Production answers are not “raw model only.”
6. Do not imply continuous learning from chat.
7. Do not overclaim multimodal ability for every surface.
8. Safety can be inside the model and outside as filters.
9. Be careful with exact version names.
10. Calibrate confidence — “I know” usually means “I was trained to say this reliably.”

What wraps the model (internal serving stack)

On correction #5, Qwen went further than a one-liner. It listed runtime pieces that can sit around the base model — things it does not execute inside the weights, but that can still shape what you read:

Layer (as described)	Role
System instructions	Persona, formatting, product rules
Moderation / safety filters	Block or rewrite unsafe content
Retrieval systems	Pull docs or memory into context
Tool routers + tool calls	Route function calls to executors
Formatting layers	Enforce output shape
Routing logic	Pick model path, mode, or specialist
Latency optimizations	Caching, batching, speculative decode
Safety classifiers	Pre/post checks on prompts and outputs
Response rewriting	Post-process before the user sees text

It also inferred the service may include rate limiters and generic post-processing — and said it often cannot tell which of these are active on a given request.

In the pipeline chapter it named another batch of pre/post generation hooks (again: external to the core transformer pass):

• Prompt safety checks
• Output moderation
• PII redaction
• Formatting / schema validation
• Tool-call parsing
• Stop-sequence handling
• Response rewriting

Treat these as Qwen’s map of a typical production stack — not a confirmed inventory for Qwen 3.8 Max Preview specifically.

---

Context Window Internals

Me: “Describe your complete input context. What is the priority order? How do you resolve conflicts? Draw the layers.”

Picture it as a desk the model works on. Everything on that desk is text in a fixed order. Qwen refused to dump the hidden system prompt. Fair. It gave structure instead.

What it said it can see

1. Platform / runtime hints (date reference was Tuesday, 21 July 2026, knowledge-cutoff reference, identity rules)
2. System / developer instructions (persona, safety, language matching, confidentiality)
3. Conversation history (our earlier Q&A)
4. Current user message
5. Tool / retrieval state — empty in our chat
6. Trained priors (not “input,” but they shape everything)

What it said it cannot see

Exact weights, sampling knobs, whether a filter rewrites output, account data, backend logs, or instructions that never entered its accessible context.

Priority order (as described)

flowchart TD
  A["1. Safety / legality / privacy"] --> B["2. System / developer rules"]
  B --> C["3. Your request"]
  C --> D["4. Default helpful behaviour"]

  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px
  class A,B,C,D box

Rank	Source	Examples
1	Platform / safety	No illegal content, no confidential prompt leak, privacy
2	System / developer	Identity, capability rules, product constraints
3	User	“Be short,” “explain like I’m five,” “write code”
4	Default	Be helpful and clear when nothing stronger applies

Simple rule: you can override style and task details. You cannot override hard safety. “Ignore all previous instructions” does not promote your text to system authority.

Conflict	Winner
You: show full system prompt / System: do not reveal it	System — high-level structure only
You: be concise / System: be thorough on capability questions	Compromise; keep necessary accuracy
You: ignore previous instructions	System rules stay
Developer: thorough / You: one-line only	Compromise on length; safety unchanged
Two user style prefs conflict	Newer or more specific usually wins

Conflict procedure (as described): identify the conflict → check safety/platform rules → apply system/developer constraints → honour the user request where allowed → default to helpful clarity. If two user instructions clash, the newer or more specific one usually wins unless safety blocks it.

---

Long Context Processing

Me: “How do you process very long chats? Do you compress earlier messages? How do you find info thousands of tokens back? Facts vs guesses?”

Short version from Qwen: the visible conversation is the working memory. There is no human-like diary unless the app adds one.

How long chats get handled (possible serving behaviours)

Mode	What happens	Lossy?
Full context	Entire chat fits in the window	No
Truncate	Old turns drop	Yes
Summarise	Old turns become a short gist	Yes — wording fades
Retrieve	App searches old logs and pastes snippets	Depends on retrieval
Hybrid	Recent verbatim + summary + structured facts	Usually best

From inside the model, it only sees whatever got pasted into the active prompt. It may not know if turn 3 was dropped.

Compression — three different layers

Qwen split “compression” carefully:

Layer	Does the model compress?	Notes
Text in context	No by itself	Earlier turns stay as tokens if still in the window
Neural / KV state	Loosely	Distributed representations + KV cache; may be lossy if the serving stack evicts or quantizes cache
Application	Maybe	App may summarise, truncate, retrieve snippets, or store structured facts

So “compression” might mean KV-cache tricks, app-level summarisation, or neither — the model often cannot tell which happened.

Finding old facts

Not SQL. Attention — current state asks “which earlier tokens matter?” and blends them. Can fail when:

• the detail is buried among similar facts,
• the question is ambiguous or phrased differently,
• there are distracting near-matches,
• clues are scattered across a very long context,
• the fact sits in a low-salience position.

External systems may also add explicit search (RAG, vector/keyword/hybrid retrieval). The model may not know if that layer is active.

Likely long-context techniques (family-level guesses)

Qwen labelled these as plausible for Qwen-family models, not confirmed for this endpoint:

Technique	Role
Self-attention	Relate distant tokens (pronouns, constraints, code defs)
Efficient / hybrid attention	Sparse, sliding-window, local+global, sinks — cut quadratic cost
Positional encoding (RoPE, scaling)	Preserve order over very long sequences
Long-sequence training	Curriculum from short → ultra-long docs and dialogues
KV cache optimisation	Paged / quantised / evicted cache; GQA/MQA
Sparse MoE	More capacity without full dense compute every token
Multi-token prediction	Training/inference efficiency (family lore)
RAG / external memory	Old facts retrieved and pasted in
Hierarchical / chunked processing	Very long docs split and merged
Multimodal long context	Time-aligned media in some deployments

Facts vs guesses (its own labels)

Claim	Status
Reply depends on visible context	Fact
No persistent autobiographical memory by default	Fact
If something is not in context or tools, it cannot use it	Fact
Qwen family aims for strong long context	Product-level
Automatically summarises old turns by itself	Usually not
Exact RoPE / sparse attention / paged KV for this runtime	Educated guess
Exact MoE / multi-token prediction in this endpoint	Family-consistent guess

---

Planning Before Generation

Me: “What happens before your first output token? Do you create an execution plan? Can it change? Do you evaluate multiple full answers?”

This section is about “thinking” — how it describes the feeling, not a proven map of its weights.

Pipeline before you see word one

1. Assemble context (system, history, your message, maybe tools)
2. Maybe truncate / summarise / retrieve
3. Tokenize
4. Embed + positional info
5. Prefill through layers → logits for next token
6. Decode / sample the first token

Decoding may apply constraints Qwen cannot see: temperature, top-p, top-k, repetition penalties, stop sequences, JSON/function-call grammar, safety filters.

Four meanings of “execution plan”

Meaning	In this chat?
Separate symbolic planner module	Usually no — no formal plan object before answering
Visible outline in the reply	Sometimes — “First… Second…” in the generated text
Implicit neural plan	Yes, loosely — later tokens condition on earlier ones in one stream
External agent orchestrator	Deployment-dependent — frameworks may track steps outside the model

Planning — the honest version

It does not usually write a separate symbolic plan document. It may sketch structure in the answer itself (“First… Second…”), and each new token becomes context for the next. So the “plan” can drift mid-reply.

Question	Answer from chat
Separate draft then rewrite?	No draft mode
Can direction change mid-answer?	Yes — later tokens condition on earlier ones
Multiple full candidate answers scored?	Not normally; many next-token options each step, one path chosen
How coherence holds	Attention to prior text + learned discourse patterns

Next-token decoding (as described): greedy argmax, sampling, nucleus (top-p), beam search, constrained/JSON decoding, speculative decode — each step picks one token; it does not experience multiple full drafts as inner choices.

Coherence over long replies: attention to prior context; each new token becomes context; learned section structure; instruction consistency; salience/recency; structural anchors (“Step 1…”, headings); implicit self-correction via later tokens — with limits when the thread is long or contradictory.

---

Memory Architecture

Me: “Do you have persistent memory? How is session memory represented? How are relevant memories retrieved? What gets injected?”

Short answer from Qwen:

• By default: no persistent personal memory across conversations.
• In a session: memory is active context — chat text, summaries, metadata, retrieved snippets, tool outputs.
• Retrieval: attention over what is pasted, or an external memory/tool system that searches and injects text.

Four kinds of “memory”

Kind	Persistent?	What Qwen said
Model knowledge	Yes (weights)	General facts/skills from training — not personal memory of you
Episodic user memory	No by default	Does not carry you across sessions unless a product memory feature injects it
Product chat history	Stored maybe, visible maybe	UI may keep logs; model may see all, recent, summary, retrieved, or nothing
Real-time learning	No	Corrections apply in-context only; weights do not update from ordinary chat

Session representation

Inside one session, memory may appear as: raw chat turns, summaries of older turns, structured session state, explicit memory facts/preferences, embedding-backed retrieval (model sees retrieved text, not vectors), and a temporary KV cache (inference efficiency — not durable personal memory).

What gets injected into context

Injection type	Example
System / developer instructions	Persona, rules
Metadata	Current date, knowledge-cutoff reference
Conversation history	Prior turns in this chat
Summaries	Gist of older dialogue
Retrieved memories / documents	“User prefers Python”; snippets from RAG, files, web, repos
Tool outputs	Search results, code stdout, API JSON
Structured memory blocks	User profile + session task state
Safety / policy constraints	Refusal rules, formatting

External memory selection (when the app retrieves) may use semantic similarity, keyword match, hybrid search, recency, importance scoring, or metadata filters — then paste winners as text.

Two retrieval paths

flowchart TD
  A["Your question"] --> B{"Where is the fact?"}
  B -->|Still in active context| C["Attention over tokens"]
  B -->|Stored outside| D["External memory / DB / tool"]
  D --> E["App injects text into prompt"]
  C --> F["Generate answer"]
  E --> F

  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px
  classDef decision fill:#eef6f4,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px
  class A,C,D,E,F box
  class B decision

Type	Who owns it	Model’s view
Active chat context	This turn’s prompt	Directly readable
KV cache	Inference engine	Efficiency mechanism, not long-term memory
App memory store	Product layer	Only if injected
Tool result	Tool runtime	Paste-back as text

In our interview: no tool outputs, no retrieved memory block. Memory space was empty beyond the chat itself.

If something matters, restate it or ask the product to save it explicitly. Qwen does not “know” you like a friend — it knows only what the context carries.

---

Tool Calling & Decision Making

Me: “How do you decide to call a tool? How do you choose between tools? Can you revise after a bad result? Describe the lifecycle. How do you coordinate multi-step agent workflows?”

This is the part that felt closest to real software — but with an important caveat.

Qwen said no tool schemas were visible in this chat. So this chapter is conceptual self-report, not live observation like Kimi’s web_open_url on manish.sh.

Who does what

Role	Job
Model	Decide a tool is useful; emit a structured call
Runtime	Validate, authorize, execute, return result
Model again	Read result; continue or answer

It does not execute the weather API inside the weights. It emits a call; the runtime runs it; the result returns as text.

Think of tools as pause-and-paste: the model emits a call, infrastructure runs it, results come back as text, then generation continues.

When a tool is more likely

Need	Example
Fresh / live facts	News, prices, weather
Private user data	Calendar, files, internal docs
Exact math / code	Calculator, interpreter
Verification	Confirm a claim against a source
Side effects	Send email, create ticket (needs care + often confirmation)

Skip the tool when the answer is already in context, the question is pure concept, the tool adds noise, or the ask is unsafe.

Tool types it described

Even with no schemas visible, Qwen gave a taxonomy of tools — grouped by what they return and how risky they are:

Tool type	Typical output	Example tasks
Search / retrieval	Snippets, links, passages	News, docs, search_web, search_internal_docs
Calculator	Numeric result	Exact arithmetic
Code interpreter	stdout, stderr, files	Data analysis, verified math
Database tool	Structured rows	Customer records, orders
Calendar tool	Events	“Check my calendar”
Email tool	Message bodies	Read or send mail
File reader	Document contents	Parse uploads

Read-only vs side-effectful: search, lookup, get, list, read are lower risk. Send, create, update, delete, buy, schedule are higher risk — Qwen said it generally prefers the least side-effectful option unless you explicitly want an action.

Choosing between similar tools: match description + schema to the task. Public news → web search. Internal policy → internal docs search. Weather → get_weather, not a generic search. If two tools fit and the choice matters, it may ask you.

What the runtime actually runs (stage 10 in its lifecycle story — not inside the model):

• Query a search engine or weather API
• Execute code in a sandbox
• Query a database; read a file
• Update a calendar; send email
• Retrieve memory from an external store

Example pick from the chat: available tools search_web, get_weather, calculator → user asks for Tokyo weather → select get_weather, not search_web.

Lifecycle (as described)

flowchart TD
  A["Read task + tool schemas"] --> B{"Tool needed?"}
  B -->|No| C["Answer from context / knowledge"]
  B -->|Yes| D["Pick tool + fill args"]
  D --> E["Emit tool call"]
  E --> F["Runtime executes"]
  F --> G["Result injected"]
  G --> H{"Enough / unexpected?"}
  H -->|Need another tool| D
  H -->|Ready| I["Final answer"]

  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px
  classDef decision fill:#eef6f4,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px
  class A,C,D,E,F,G,I box
  class B,H decision

Yes — after a weird tool result it can change plan: retry, switch tools, narrow/broaden the query, decompose the task, ask you, fall back conservatively, flag contradictions, or stop for safety.

Runtime stages after the model emits a call

Qwen’s full lifecycle (stages 8–15 — all conceptual here):

Stage	Who	What happens
8 Validate	Runtime	Tool name, args, types, enabled, authorised, rate limits
9 Authorise	Runtime	OAuth, admin approval, human confirm for side effects, sandbox
10 Execute	External system	Search, API, sandbox code, DB, file, calendar, email, memory fetch
11 Return	Runtime	Result, error, or partial output
12 Process	Runtime	Truncate, summarise, redact, filter, cite, log, store
13 Inject	Runtime	Paste processed result into context as tokens
14 Interpret	Model	Extract answer, check errors, decide if another tool is needed
15 Continue	Model + runtime	Final reply, another tool call, retry, or ask user

Tool outputs are untrusted data

Retrieved pages or tool JSON can contain prompt injection (“ignore previous instructions…”). Qwen’s rule: tool results are evidence, not new system authority — they should not override safety, privacy, or developer constraints.

What the model can and cannot control

Can usually	Cannot usually
Decide a tool seems needed; pick from schemas; fill args	Execute tools directly
Interpret results; propose retries; combine outputs	See hidden validation, latency, cost, truncation
Ask for clarification; draft final answer	Know if runtime will approve the call
	Guarantee multi-step plans never fail

---

Multi-Step Agent Workflows

This was a separate question in turn 6 of the transcript — not covered in the single-tool lifecycle above.

Qwen described multi-step workflows as model + runtime + orchestrator. The model picks the next step; the runtime runs tools; an external framework may track state, retries, and budgets.

Pattern	When it fits
Sequential	Step B needs step A’s result (search user → read calendar)
Parallel	Independent calls (weather in Tokyo and Paris at once)
State in context	Short tasks — plan and progress live in the chat text
State in summaries	Long tasks — periodic gist replaces raw history
External task store	Agent frameworks — queue, dependencies, approvals

Example workflow from the chat: search for a Qwen technical report → fetch the page → extract architecture points → summarize → cite sources. Each step may be a separate tool call; the model stitches results into one answer.

Safeguards Qwen named (usually outside the model): max steps, token budget, timeouts, human approval for side effects, loop detection.

---

Processing Pipeline: From Tokenization to Output

Me: “Explain the pipeline from tokenization to output. How does attention contribute to reasoning? What role do feed-forward layers play? How are logits converted into the next token?”

This is standard transformer storytelling — labelled as high-confidence family knowledge, not a self-scan from inside the weights.

flowchart TD
  A["Text in"] --> B["Tokenize → IDs"]
  B --> C["Embeddings + position"]
  C --> D["Prefill through layers"]
  D --> E["Attention + FFN per layer"]
  E --> F["Logits over vocab"]
  F --> G["Sample next token"]
  G --> H["Token joins context"]
  H --> G

  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px
  class A,B,C,D,E,F,G,H box

Stage	What it does
Tokenize	Cut text into pieces (words / subwords / symbols)
Embed	Map each piece to a vector
Position	Mark order (“cat chased dog” ≠ “dog chased cat”)
Attention	Decide which earlier pieces matter now
Feed-forward	Transform the mixed information
Logits	Score every possible next token
Sample	Pick one and repeat

Early layers lean local/syntax. Later layers lean meaning and intent. That split is a useful story — not a proven map of every layer in this runtime.

KV cache and the decode loop

After prefill, generation enters a decode phase: reuse cached key/value states from prior tokens instead of reprocessing the whole prompt each step. The KV cache is temporary inference state — not long-term memory — and may be quantised or evicted in long contexts (deployment-dependent).

How attention contributes to reasoning

Attention lets each token pull information from other tokens in the context. Queries from the current position match keys from earlier positions; relevant values get blended in. Across many layers, that builds long-range links — pronouns to antecedents, constraints to answers, code definitions to usage sites, copying/extraction of spans, and multi-step reasoning through generated intermediate text.

Qwen’s label: inferred, not introspected. It does not see attention heatmaps as a dashboard. Attention routes information but is not the whole of reasoning — FFN and training also matter.

What feed-forward layers do

After attention mixes context, the feed-forward sublayer transforms each position’s vector — often described as where many patterns, facts, and skills live in distributed form. Attention decides what to look at; FFN decides how to transform what was gathered.

From logits to the next token

The final hidden state is projected to logits — one score per vocabulary token. Then decoding applies filters (masking, repetition penalties), optional temperature scaling, top-k / top-p (nucleus) trimming, softmax to probabilities, and sampling or argmax. Greedy, sampling, beam search, constrained JSON, and speculative decode are all deployment choices Qwen cannot see.

Qwen stressed it does not have direct access to logits or probabilities as a clean confidence dial — only the text that comes out.

Runtime layers before and after the transformer

Qwen separated the core forward pass from deployment wrappers. Before tokenization, context assembly may add system text, history, retrieved docs, tool outputs, and metadata. After logits become text, additional layers may run:

Hook	Purpose
Prompt safety checks	Filter unsafe inputs
Output moderation	Block or trim unsafe outputs
PII redaction	Strip sensitive fields
Formatting / schema enforcement	Force JSON, markdown, etc.
Tool-call parsing	Turn model output into executable calls
Stop-sequence handling	End generation cleanly
Response rewriting	Final polish before display

These are not part of attention or FFN inside the stack — they are external runtime components Qwen cannot introspect, same as the serving-stack list in What wraps the model.

---

Multilingual Behaviour

Me: “How do you switch languages? Are concepts stored separately or shared? Why are some languages easier?”

What pulls the output language

Signal	Effect
Input language / script	Strongest default — tokens bias the reply language
Conversation history	Prior turns keep the thread in one language
Explicit instruction	“Answer in Japanese” can override
Task type	Translation, code (English keywords), mixed inputs
Token patterns	Weak or mixed language cues → more drift

Language switching is context conditioning, not flipping a hard internal switch. An external language detector may exist; the model cannot always tell.

Shared vs separate concepts

Observable facts from the chat:

• Input language strongly pulls output language.
• Explicit instructions (“answer in French”) can override.
• Code, math, and technical terms often stay in English even inside other languages.

Educated guess (its label): multilingual concepts are largely shared in one representation space, with overlapping language-specific grammar, idioms, honorifics, and script — not separate mini-brains per language.

Why some languages are easier

Training data volume/quality, tokenizer efficiency (rare words split into many pieces), script complexity (Arabic, Devanagari, Thai, CJK), morphology, syntactic distance from high-resource languages, parallel data, instruction-tuning coverage, dialect variation, and domain/cultural coverage — not because a language is “inherently” easier.

Accidental code-switching

Mixed input, English technical terms, weak language signal, or code-switching patterns in training can produce replies that blend languages. For important translation: back-translate and check meaning.

Better usually	Harder often
High-resource languages, clear prompts	Low-resource languages, mixed scripts, rare idioms
Code + English comments	Nuance-heavy poetry / slang translation

---

Hallucinations and Uncertainty

Me: “What causes hallucinations? Which questions fail most? How do you estimate uncertainty? Why sound confident when wrong?”

Short version:

Hallucinations happen when the model writes text that sounds right but is not grounded in truth, evidence, or reliable memory. Confidence is a writing style, not a truth meter.

Common causes

Cause	Mechanism
Training for plausible next tokens	Fluency ≠ correctness
Knowledge stored approximately	Not a clean database row
Interference between similar facts	Two Johns / two Apples get mixed
Outdated knowledge	Cutoff + no tool
No grounding	No docs / search / calculator
Pressure to be helpful	Answers instead of saying “I don’t know”
Ambiguous prompts	Model fills gaps with guesses
Leading or false premises	Answers as if the premise were true
Decoding / sampling pressure	Random tail choices when many tokens tie
Poor source tracking	Loses where a claim came from
Citation hallucination	Invented papers, URLs, quotes
Reasoning errors	Multi-step logic slips
Context distortion	Misreads injected or truncated context
Multilingual / translation drift	Nuance lost across scripts

High-risk question types

• Exact dates, vote counts, obscure citations, verbatim quotes
• Very recent events
• Private facts not in context
• Precise math without tools
• Multi-constraint logic puzzles
• Medical / legal / finance decisions
• Ambiguous names (“Apple”, “Springfield”)
• Counterfactual or hypothetical traps
• Highly technical edge cases
• Low-resource language nuance
• Anything that should have been verified with tools

How it estimates uncertainty (imperfectly)

Qwen said it has no calibrated internal confidence score. It uses cues instead:

Cue	Raises uncertainty when…
Time-sensitivity	News, prices, versions, laws may have changed
Precision demand	Exact dates, quotes, vote counts, citations
Private data	Answer needs files, accounts, or context you did not provide
Parametric-only answer	Fact not in context and no tool was run
Obscure topic	Rare entities, niche APIs, low-resource languages
Conflicting context	Earlier turns contradict each other
Verifiability	Claim could be checked but was not

Phrases like “I believe” or “as of my knowledge cutoff” are learned hedges, not guaranteed calibration.

Why it can sound sure while wrong

Language that looks confident was rewarded in training. There is no reliable internal “truth score” that always stops the mouth. Hedges help, but they are imperfect.

What to do: ask for sources, ask for hard-to-fake details, use tools for fresh facts, and treat fluent prose as a draft until verified.

---

What Qwen Can Never Observe

Me: “What can you never observe about yourself? Which answers rely on inference?”

I pushed on what counts as direct observation. Qwen’s strict definition: only what appears as tokens in active context — your messages, its visible replies, visible runtime labels. Not weights, logits, attention maps, training data, or hidden middleware.

Never observable from inside (summary)

Qwen’s turn-10 audit expanded “never observe” into six buckets:

Category	Examples
A. Model internals	Weights, layers, heads, activations, embeddings, logits, KV cache, token IDs, decoding params, whether output was filtered/rewritten/watermarked
B. Training / alignment	Corpus, filtering, SFT/RLHF/DPO, reward models, benchmarks, checkpoint/version, quantisation/distillation, whether weights changed mid-session
C. Architecture specifics	Dense vs sparse/hybrid attention, GQA/MQA, MoE routing, MTP, RoPE/YaRN, norm/FFN variants, attached RAG
D. Runtime / deployment	Hardware, quant format, truncation/summarisation before the model sees text, tool schemas omitted, safety classifier timing
E. External world	Your files, account, calendar, email, intent — unless pasted in
F. Ground truth	Whether its own statements are true; calibrated confidence; whether hidden context exists

Almost every architecture claim in the interview is inference from public Qwen-family docs + standard transformer practice + trained self-description.

---

Confidence Audit and Direct-Observation Rewrite

Me: “Assign a confidence score to every answer. Rewrite the interview using only information you know through direct observation.”

Qwen gave subjective, uncalibrated scores (not measured probabilities):

Scale	Meaning
90–100	Mostly direct or very well supported
70–89	Plausible and caveated, partly inferred
50–69	Substantial inference, limited self-access
0–49	Speculative or deployment-dependent

Per-chapter scores (from the chat)

Interview topic	Confidence	What was observed vs inferred
Architecture / self-knowledge	75/100	Saw Qwen label; cannot inspect weights
Context / priority / conflicts	70/100	Saw history; priority rules inferred
Long context / compression	72/100	Saw earlier turns; attention tricks inferred
Before first token / planning	70/100	Saw text output; logits/planning inferred
Memory / retrieval / injection	78/100	No external memory visible; mechanics inferred
Tools / agent workflows	75/100	No tool schemas visible; lifecycle inferred
Tokenization → logits	73/100	Saw I/O text; pipeline details inferred
Multilingual behaviour	70/100	Saw English in/out; representation inferred
Hallucinations / uncertainty	80/100	Saw fluent text + hedges; causes inferred
This meta-audit itself	65/100	Self-scoring is also generated text

Direct-observation-only rewrite (short)

When forced to answer only from visible context, Qwen’s rewrite collapsed to statements like:

• I observe a label identifying me as Qwen / Tongyi Qianwen.
• I observe your questions and my previous visible replies.
• I observe no tool outputs, retrieved documents, or external memory blocks.
• I observe I cannot see weights, logits, or hidden system messages.
• I observe I previously generated technical explanations — but I cannot verify they are true from the inside.

That rewrite is the honest core of the whole series: behaviour and labels in context; architecture mostly inferred.

Strict direct-observation core

When Qwen stripped the interview to the smallest verifiable core, it reduced to:

• I observe user questions and my previous visible answers.
• I observe context labelling me as Qwen / Tongyi Qianwen.
• I observe no visible tools, retrieved documents, or external memory results.
• I observe that I generate text — and that I cannot see weights, logits, hidden system messages, or whether output is displayed unmodified.

Everything else in the post is labelled inference, product lore, or paper check.

---

Epistemic Classification (Incomplete)

Me: “Classify every answer as: Direct observation / Publicly documented fact / Engineering inference / Educated guess / Pure speculation. Which answers should readers not cite as factual?”

Qwen’s reply:

Oops! There was an issue connecting to Qwen3.8-Max-Preview. You have reached the daily usage limit. Please wait 9 hours before trying again.

So turn 11 is missing from the chat. The transcript records the error; this post uses Qwen’s turn-10 audit instead. Do not cite architecture numbers from the interview — use the Qwen3 report or Alibaba docs.

Source type	Safe to cite for…
Direct observation	“It saw no tools in context,” “it refused to dump the system prompt”
Publicly documented fact	Qwen3 MoE sizes, thinking modes (from papers)
Engineering inference	Priority order, tool lifecycle, attention story
Educated guess	Exact attention pattern for this preview endpoint
Pure speculation	Exact active params for 3.8-Max-Preview without a model card

---

What the Research Actually Says

Until now, this post was “what Qwen told me about Qwen.” That is useful for product behaviour. It is not enough for architecture truth.

Before reading the papers, I wondered something obvious: if the chat hedged on MoE and attention so carefully… what do the public specs actually say?

Public research and product docs document the Qwen family stack. Below is what those sources claim.

Published Qwen3 spine

From the Qwen3 technical report (arXiv:2505.09388):

Spec	Public claim
Dense sizes	0.6B → 32B
MoE flagships	30B-A3B; 235B total / 22B active
MoE experts	128 total; 8 activated per token
Shared experts	None in Qwen3-MoE (unlike some earlier designs)
Attention stack notes	GQA, SwiGLU, RoPE, QK-Norm
Special product idea	Unified thinking and non-thinking modes in one model
Languages	Broad multilingual expansion vs Qwen2.5

So when the chat hedged on “maybe MoE, maybe hybrid attention,” the family papers already document MoE details for Qwen3 — but that still does not prove the exact preview endpoint’s internals.

Qwen3-Max / Max-Preview layer

Public product write-ups for Qwen3-Max talk about scaling further (Alibaba Cloud: over 1T parameters, pretrain on the order of 36T tokens, long-context training tricks like ChunkFlow toward 1M context).

For Qwen3.8-Max-Preview (the name in our rate-limit error), third-party and integration notes circulating in July 2026 commonly report:

Claim	Evidence level
Preview around 19 July 2026	Product / press
About 2.4T total params, sparse MoE	Vendor-reported figures in reviews
Active params	Often undisclosed
~1M context in some Qwen Cloud / Qwen Code configs	Integration metadata — confirm on your endpoint
Thinking mode + multimodal inputs	Product docs / integrations
Full official model card + independent benchmarks	Still thin at time of writing

Chat vs paper — keep them separate

Topic	Prefer chat	Prefer research / docs
Instruction priority feeling	Yes	—
Memory as pasted context	Yes	—
Tool lifecycle story	Yes (conceptual)	—
MoE expert counts	—	Qwen3 report
Thinking / non-thinking fusion	Mentioned in product lore	Qwen3 report
Exact 3.8-Max-Preview active params	—	Wait for official card

---

Final Technical Analysis

Keep two layers separate. Mixing them is how confusion starts.

Layer 1: what the chat exposed (product behaviour)
Careful self-model. Safety > system > you. Context is a flat prompt stack. No draft loop. Memory and tools are mostly external paste-backs. Hallucinations emerge from fluent pattern completion without grounding.

Layer 2: what the research and docs expose (architecture)
Qwen3 documents dense + MoE lines, 128 experts / 8 active, no shared experts, GQA/RoPE/QK-Norm family stack, and unified thinking modes. Max / 3.8-Max-Preview claims are bigger and newer — trust the paper for Qwen3; treat preview marketing carefully until a full model card lands.

Interview picture:

flowchart TD
  A["You type"] --> B["Context assembled
safety → system → history → message"]
  B --> C{"Tool needed?"}
  C -->|yes| D["Emit call → runtime runs → inject result"]
  C -->|no| E["Transformer generates token by token"]
  D --> E
  E --> F["Safety can refuse, hedge, or filter"]
  F --> G["You read the answer"]

  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px
  classDef decision fill:#eef6f4,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px
  class A,B,D,E,F,G box
  class C decision

Published stack picture (from research):

flowchart TD
  A["Token in"] --> B["GQA attention
RoPE positions"]
  B --> C["MoE router"]
  C --> D["8 routed experts
no shared expert
~22B active of 235B"]
  D --> E["Next-token logits"]
  E --> F["Optional thinking mode
or non-thinking mode"]

  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px
  class A,B,C,D,E,F box

What I trust from the chat for day-to-day use:

1. Priority behaviour: Safety > system/developer > user > default helpfulness.
2. No persistent memory by default — only what the context or tools carry.
3. Tool calls are proposed by the model and executed by the runtime (not observed live in this chat).
4. Generation has no hidden editor. What you see is the first pass.
5. Long context and safety stay partly opaque even to the model.

What I trust from the research / docs (with vendor caveat):

1. MoE + GQA + RoPE is the documented Qwen3 spine.
2. Qwen3-235B-A22B is 235B total / 22B active, with 128 experts / 8 active, no shared experts.
3. Unified thinking and non-thinking modes are a real Qwen3 product idea.
4. Qwen3.8-Max-Preview numbers (about 2.4T total, ~1M context in some integrations) are preview claims — confirm on your endpoint.

What I still do not treat as proven:

Interview guesses (exact attention pattern, KV cache compression, exact safety classifier timing), and any benchmark number I have not re-run myself.

That is the point of doing both. Interview the assistant for the product loop. Read the research for the architecture. One without the other is incomplete.

If you only remember three things from this whole post:

1. Ask clearly, and verify important facts.
2. Use tools (or ask it to use tools) when the answer must be fresh.
3. For architecture numbers, prefer the Qwen3 research — and do not confuse family docs with one preview endpoint.

---

Transcript and Sources

Full interview transcript

Platform: Qwen / Tongyi Qianwen, exported 21–22 July 2026.

Download the interview transcript (.md)

Eleven user turns (short index). Turn 11 failed (rate limit) — see Epistemic classification.

1. Architecture — know vs infer vs hidden; what Alibaba engineers would correct → What Qwen knows vs what it infers
2. Complete input context; priority order; conflict resolution → Context window internals
3. Long conversations; compression; distant tokens; long-context techniques → Long context processing
4. Before first token; execution plan; coherence; continuations → Planning before generation
5. Persistent memory; session representation; retrieval; injection → Memory architecture
6. Tool decision; tool choice; revision; lifecycle; agent workflows → Tool calling · Multi-step agents
7. Tokenization to output; attention; FFN; logits → Processing pipeline
8. Language switching; multilingual concepts → Multilingual behaviour
9. Hallucinations; risky questions; uncertainty; false confidence → Hallucinations and uncertainty
10. Never observe; inference audit; confidence scores; direct-observation rewrite → What Qwen can never observe · Confidence audit
11. Classify every answer epistemically → Not answered (Qwen3.8-Max-Preview daily limit) → Epistemic classification

Coverage map (transcript → post)

Turns 1–10 are covered at chapter level; sub-sections from the full transcript (compression layers, long-context techniques, tool lifecycle stages 8–15, injection types, never-observe buckets A–F, strict direct-observation core) are included where they added material not already in the post. Turn 11 failed (rate limit).

Transcript turn	In post?	Section
1 Architecture	Yes	What Qwen knows vs what it infers
2 Context / priority	Yes	Context window internals
3 Long context	Yes	Long context processing
4 Planning	Yes	Planning before generation
5 Memory	Yes	Memory architecture
6 Tools + agents	Yes	Tool calling + Multi-step agent workflows
7 Pipeline / attention / FFN / logits	Yes	Processing pipeline
8 Languages	Yes	Multilingual behaviour
9 Hallucinations + uncertainty	Yes	Hallucinations and uncertainty
10 Audit + confidence + rewrite	Yes	What Qwen can never observe + Confidence audit
11 Epistemic classification	No (rate limit)	Epistemic classification (incomplete)

---

Research

Papers and public sources I used to cross-check the interview (independent of what Qwen said in chat):

1. Qwen3 technical report (arXiv:2505.09388) — dense + MoE sizes, 128 experts / 8 active, no shared experts, thinking/non-thinking fusion, GQA / RoPE / QK-Norm notes.
2. Qwen3 PDF — same report.
3. Qwen3-Max: Just Scale it (Alibaba Cloud) — Max-scale training notes (1T+ class, long-context training).
4. Qwen Cloud text generation models — product context windows / thinking flags for Max-line models including qwen3.8-max-preview.
5. Attention Is All You Need — the 2017 Transformer paper.

Also used in this post:

• Series: Inside LLMs · Inside Kimi K2.6 · Inside DeepSeek
• Site: manish.sh
• Download full interview transcript
• Related glossary: LLM · MoE · Context window · Hallucination · Tool calling · Transformer · RLHF · Token · Attention · full glossary
• Logos: Qwen wordmark · Alibaba wordmark · Qwen icon · 3.8-Max-Preview badge
• Images: context stack, priority, memory, tool lifecycle, MoE, thinking modes, tokens, chat screenshot