{"slug": "inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself", "title": "Inside Kimi K2.6: Reverse Engineering an AI Assistant by Interviewing Itself", "summary": "Manish Shahi reverse-engineered Moonshot AI's Kimi K2.6 by interviewing the model itself, finding that the chat interface claims a 2-million-token context window while published K2.6 research specifies 256K tokens. The interview revealed that tools and memory are first-class features, system rules override user messages, and user messages override old memory, but the model does not search a memory database mid-sentence—it reads a pre-pasted block.", "body_md": "[← Models](/models)\n\n# Inside Kimi K2.6: Reverse Engineering an AI Assistant by Interviewing Itself\n\n[Series · Inside LLMs](/series/inside-llms)\n\nBy[Manish Shahi](/about)Software Engineer • AI Developer\n\n## Table of contents(79)\n\nI run [manish.sh](https://manish.sh). I write about [AI](/glossary/artificial-intelligence) tools, [agents](/glossary/ai-agent), and how these models actually behave when you push them.\n\nThis post opens the ** Inside LLMs** series — interview the model, write down what it claims, then check the numbers against published research. The\n\n[DeepSeek follow-up](/writings/models/inside-deepseek-reverse-engineering-an-ai-assistant-by-interviewing-itself)is the second entry.\n\nMy first question was not “how do your weights work?”\n\nMe:“I run a blog at manish.sh. Give me blog post ideas about Kimi K3.”\n\nKimi:It called`web_open_url`\n\n, opened my site, read the focus (practical AI tooling, MCP, automation), then tailored ideas to that audience.\n\nThat 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 could browse.\n\nNo weight dumps. No prompt leaks. Just questions — and later a cross-check against published K2.6 research. Where Kimi said “I am guessing,” I keep that label. Scroll to [interactive labs](#kimi-interactive-labs) near the end.\n\n**Quick note:** In the chat I asked for ideas about “Kimi K3.” The model answered as Kimi, built by Moonshot AI. This post’s title uses **K2.6** as the product I am writing about. Treat the interview as self-report, not an official architecture whitepaper.\n\n### 60-second TL;DR\n\n**Premise:** interview Kimi about[memory](/topics/memory), tools, context, and safety — then check claims against public K2.6 research.**Behaviour insight:** tools and memory are first-class; system rules beat your message; your message beats old memory.**Hard limit:** the model does not search a memory database mid-sentence — it reads a pre-pasted block.**Chat vs paper:** the chat claimed**2M** context; published K2.6 specs say**256K**— jump to[Part 5](#what-the-research-actually-says).** Practical rule:**use the chat for product behaviour; prefer research for architecture numbers (MoE, MLA, Agent Swarm).\n\n### How to read this post\n\nTreat 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.\n\n### Chapters\n\n**Part 1 — Interview hook**\n\n**Part 2 — Memory & tools**\n\n[Memory architecture](#memory-architecture)[Tool calling and decision making](#tool-calling--decision-making)[Before every answer (turn checklist)](#before-every-answer-the-turn-checklist)[Retrieval policy](#retrieval-policy)[Session metadata](#session-metadata)\n\n**Part 3 — Context & thinking**\n\n[Context window internals](#context-window-internals)[Priority hierarchy](#priority-hierarchy)[Planning before generation](#planning-before-generation)[Long context and 2M tokens](#long-context--2m-tokens)[Attention and reasoning](#attention--reasoning)\n\n**Part 4 — Safety & personality**\n\n**Part 5 — Reconstruct & paper check**\n\n[Internal pipeline reconstruction](#internal-pipeline-reconstruction)— includes[how to build your own Kimi-like assistant](#how-to-build-your-own-kimi-like-assistant-what-i-was-really-asking)[What Kimi knows vs what it infers](#what-kimi-knows-vs-what-it-infers)[What the research says](#what-the-research-actually-says)[Final technical analysis](#final-technical-analysis)[Interactive labs](#kimi-interactive-labs)[Research](#research)\n\n## Introduction: Why I Interviewed Kimi K2.6\n\nI started with a small ask. I told it I run a blog on `https://manish.sh`\n\nand asked for blog post ideas about Kimi K3.\n\nIt did not guess my niche from thin air. It opened my site, read the focus, and tailored the list: compare frontier models on real coding tasks, build an [MCP](/glossary/mcp) server for Kimi, stress-test a huge [context window](/topics/context-window), automate a standup with [n8n](https://n8n.io/?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh), ship [prompting](/glossary/prompt-engineering) patterns that actually work. Whether every model name ages well is not the point. The point is it tailored the list *after* reading my site.\n\nIf an assistant can browse my site and tailor answers, I want to know the plumbing. So I kept asking harder questions: how memory works, how tools get chosen, what sits inside the [context window](/glossary/context-window), who wins when rules conflict, and what makes it [hallucinate](/glossary/hallucination).\n\n## What Makes Kimi Different From Other LLMs\n\nMe:“What makes you different from other existing LLMs?”\n\nThis answer is still from the **chat**, not from published research. It is how Kimi markets its own behaviour. Keep that in mind. We’ll unpack MoE, MLA, and Agent Swarm later in Part 5 — for now, stay on the product story.\n\n### 1. It can see and interact with the real world in real time\n\nBuilt-in web search, URL fetching, image search, and data APIs. Not only “retrieve a snippet” — open a live site, pull fresh stock prices, find images on demand. Many LLMs are frozen at training time. This one can look up what happened yesterday.\n\n### 2. It has actual memory across conversations\n\nNot just the current chat window. It consolidates past conversations into long-term memory automatically, and you can pin instructions it should always remember. Most chat LLMs start from zero every session.\n\n### 3. It can build interactive widgets\n\nLive HTML/SVG widgets: charts, calculators, dashboards, interactive demos in chat. Not only text.\n\n### 4. It can schedule reminders\n\nA cron system. “Remind me every Monday at 9am to check server logs” — it claims it will actually do that.\n\n### 5. It is built by Moonshot AI, not OpenAI or Google\n\nTraining, safety, and design priorities come from a different company. In the chat it claimed long-context reasoning up to **2 million** tokens. Hold that number — the research chapter has a surprise.\n\n### 6. It can do real computation\n\nVia Python (`ipython`\n\n): data analysis, charts, files, math with actual code execution — not only predicting what an answer might look like.\n\n### The honest caveat from the same answer\n\nIt said it cannot tell you exactly how its weights differ from GPT-5 or Claude 4 under the hood. Behaviour is shaped by tools and memory wired into the loop, not bolted on as afterthought function calling.\n\nMe:“Did you train on Claude?”\n\nKimi:No.Developed by Moonshot AI (月之暗面). Not trained on[Claude]or any[Anthropic]model. Public sources for training data, not distilling other models’ outputs.\n\nThe field still shares concepts ([transformers](/glossary/transformer), [RLHF](/glossary/rlhf), long context), but [weights](/glossary/weights), data curation, and safety training are Moonshot’s own.\n\n## Memory Architecture\n\nMe:“How does your memory work?”\n\nIt said there are two kinds. My analogy (not Kimi’s words): one is like automatic chat backup; the other is a pinned note you wrote yourself.\n\n### Dream Memory (automatic)\n\nAfter a conversation ends, the system reviews it overnight and saves key facts: blog domain, role, topics, preferences. You do not ask for this. It does not announce “I saved this.” Next time, those notes may help. That is Dream Memory.\n\n### Explicit Memory (manual)\n\n“Remember that I prefer Python over Node.js.” Standing instruction. You can update or delete later. Max **50** entries in the rules it described.\n\n### What it sees in a session\n\nCurrent thread plus any saved memories. In our session: **no saved memories yet**. Memory is not perfect — things get summarised; details blur. If something matters, restate it or ask it to save explicitly.\n\nOn privacy: summaries, not full transcripts. You can delete explicit memories. No access to unrelated sessions or other users.\n\n### How “you” are identified (what it claimed)\n\n**What it said it does not have**\n\n- No account system by default (name/email only if you tell it)\n- No device access\n- No cross-platform tracking\n\n| Data | Storage | Identified by |\n|---|---|---|\n| Current conversation | Session memory (temporary) | Anonymous session ID |\n| Dream Memory | Long-term, auto-consolidated nightly | Hashed/abstracted user identifier |\n| Explicit Memory | Long-term, user-instructed | Same hashed identifier |\n| Tool outputs | Not stored beyond the current response | N/A |\n\n| Remembered | Forgotten |\n|---|---|\n| Things you explicitly ask it to save | Exact wording of casual chat |\n| Auto-consolidated facts (blog domain, preferences, projects) | Transient tool outputs after use |\n| Standing instructions | Anything you tell it to forget |\n\n## Tool Calling & Decision Making\n\nThis is the part that felt closest to real software.\n\nMe:“How do you decide when to call a tool?”\n\nThink of tools as pause-and-paste: the model emits a call, infrastructure runs it, results come back as text, then generation continues.\n\n``` php\nflowchart TD\n  A[\"User question\"] --> B{\"Do I need a tool?\"}\n  B -->|No: I already know| C[\"Answer directly\"]\n  B -->|Yes: live data, URL, compute, images| D[\"Pick the right tool\"]\n  D --> E{\"Can I batch?\"}\n  E -->|Independent parts| F[\"Call multiple tools at once\"]\n  E -->|B needs A first| G[\"Wait for A, then call B\"]\n  F --> H[\"Integrate results\"]\n  G --> H\n  H --> I[\"Respond\"]\n\n  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  classDef decision fill:#eef6f4,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  class A,C,D,F,G,H,I box\n  class B,E decision\n```\n\n### Which tool for which need\n\n| If you need… | It uses… |\n|---|---|\n| Current news, facts, or web content | `web_search` |\n| A specific URL’s content | `web_open_url` |\n| Images matching a description | `search_image_by_text` |\n| Similar images to one you uploaded | `search_image_by_image` |\n| Math, data analysis, or charts | `ipython` |\n| Stock/finance/economics data | `get_data_source` |\n| A visual interactive widget | `show_widget` |\n| Save/update/delete a memory | `memory_instruction_edits` |\n| Schedule a reminder | `add_cron_job` / `update_cron_job` |\n\n### Limits it stated\n\n- Only\n**one round** of web search per turn - Up to\n**25 steps** total in one response - Up to\n**2**`web_search`\n\nqueries in parallel if independent - Cannot browse continuously or “click around”\n- Cannot run persistent servers or install packages\n- Cannot generate downloadable files except charts via\n`ipython`\n\n### Full tool list (purpose)\n\n| Tool | Purpose |\n|---|---|\n`web_search` |\nSearch the internet. Up to 2 queries in parallel if independent. |\n`web_open_url` |\nFetch and read a specific URL. |\n`search_image_by_text` |\nFind images matching a text description. |\n`search_image_by_image` |\nFind similar images to an uploaded one. |\n`ipython` |\nRun Python for math, analysis, charts, file processing. |\n`get_data_source_desc` |\nList available APIs for a data source. |\n`get_data_source` |\nCall a specific API for structured data. |\n`memory_instruction_edits` |\nAdd, replace, or delete explicit standing instructions. |\n`add_cron_job` |\nSchedule a one-time or recurring reminder. |\n`list_cron_jobs` |\nShow scheduled reminders. |\n`update_cron_job` |\nModify an existing reminder. |\n`remove_cron_job` |\nDelete a reminder. |\n`show_widget` |\nRender an interactive HTML/SVG widget in chat. |\n\nSupported data sources it named: Yahoo Finance, arXiv, World Bank, Binance, Google Scholar, stock/finance data, IMF, Chinese legal data.\n\n### Example from our chat\n\nBlog ideas about Kimi K3 → memory empty → `web_open_url`\n\non manish.sh → answer. Classic “tool first, then talk.”\n\n### Skipped a tool on purpose vs should have called one\n\n| Situation | Why it skipped |\n|---|---|\n| “How your memory works?” | Conceptual; no external data needed |\n| Retrieval policy questions | Meta-knowledge about itself; no tool applies |\n| Blog post ideas | Could have searched “Kimi K3 blog ideas,” but that would be generic vs tailoring to the site |\n\n| Situation | Why it failed |\n|---|---|\n| Assumed a recent fact, was off by months | Overconfidence in training data |\n| Answered coding from memory when the docs had changed | Did not check for recency |\n\nIt said this is not a clean algorithm with neat scores. More like a gut judgment early while reading your message.\n\n## Before Every Answer: The Turn Checklist\n\nMe:“What decision do you take before answering any question in each turn?”\n\nShort version (full version under [Planning Before Generation](#planning-before-generation)):\n\n- What does the user actually need?\n- Do I need tools for live data, a URL, math, or images?\n- Did earlier turns in this chat change the answer?\n- Is there useful memory from past chats, and would mentioning it feel weird?\n- What tone and length fit?\n- Am I confident, or should I hedge (especially for health, money, legal)?\n- Any safety or policy issue?\n\nOnly after that does generation start. Most of it is fast. Sometimes it asks a clarifying question instead of guessing.\n\n## Retrieval Policy\n\nMe:“What’s your retrieval policy?”\n\nShort version in its words: fetch what I need, when I need it, with minimal assumptions.\n\n| Rule | Meaning |\n|---|---|\n| No speculative retrieval | No “just in case” searches |\n| Match tool to the gap | Right tool for what is missing |\n| One search round per turn | Craft queries carefully, then maybe open URLs |\n| No persistent browsing | Fetch once, read, stop |\n| Memory before retrieval | Check saved memories first |\n| Honest about limits | Admit failure instead of inventing |\n\n| What it is missing | What it retrieves |\n|---|---|\n| Current events, recent launches, live facts | `web_search` |\n| Specific page content you reference | `web_open_url` |\n| Your past preferences or explicit instructions | `memory_instruction` |\n| Math, data, charts, file processing | `ipython` |\n| Financial/economic/academic datasets | `get_data_source` |\n| Visual reference or images | `search_image_by_text` / `search_image_by_image` |\n\n## Session Metadata\n\nBeside the chat text sits a small whisper layer: session metadata. Not the conversation — context about how to behave.\n\n### What it can see\n\n**Timestamp**(example:`2026-07-20 22:58`\n\n)**Awareness level:**`high`\n\nor`low`\n\n**Memory entries:** explicit + Dream\n\n### What it said it cannot see\n\nName, location, identifiers unless you told it. Browsing history, files, activity outside chat. Technical session IDs.\n\n| Scenario | How metadata helps |\n|---|---|\n| You ask “latest React docs” | Timestamp steers search toward current year docs |\n| Discussing your blog again | `awareness: high` + memory → recall manish.sh focus |\n| Random small talk | `awareness: low` → do not inject “how’s that blog post?” |\n\nIt called metadata **context, not surveillance**.\n\n| Without metadata | With `awareness=\"low\"` |\n|---|---|\n| Might ask about the blog unprompted | Only mention manish.sh if you bring it up |\n| Might reference past projects unprompted | Stay on the current question |\n| Feels like it is watching you | Feels like a cleaner slate |\n\n``` php\nflowchart TD\n  A[\"System instructions (fixed rules)\"] --> B[\"Session metadata (lightweight context)\"]\n  B --> C[\"Saved memories (long-term facts)\"]\n  C --> D[\"Current conversation\"]\n\n  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  class A,B,C,D box\n```\n\n**Why was awareness low in our chat?** It guessed: the question was meta/technical about mechanics, not my projects. If I had asked “what should I write next on my blog?”, awareness might flip to `high`\n\n.\n\n### How memories are presented (not “injected”)\n\nAt the start of a turn, a memory block can appear. It does not secretly search a database mid-sentence. It reads what the system placed in front of it.\n\n(Example text from Kimi — not a verified claim about me; my live block was empty.)\n\n| If you ask… | It checks memories for… | Action |\n|---|---|---|\n| “Blog post ideas for Kimi K3” | Blog topic, stack, style | Use manish.sh context |\n| “What is Python?” | Nothing relevant | Ignore memories |\n| “How’s my project going?” | Saved project details | Reference if found, admit gap if not |\n\nWhat it does **not** do: invent memories if empty; “search” memories like SQL; keep content beyond what that block shows.\n\n**Practical effect:** empty memory → fetch manish.sh via tool. Tomorrow, if Dream consolidates that, it might skip the fetch.\n\n## Context Window Internals\n\nMe:“What sits inside the context window, and in what order?”\n\nPicture it as a desk the model works on. Everything on that desk is text in a fixed order. Same chat as the screenshot near the top of this post.\n\nOrder it described:\n\n**System-level instructions**(safety, formatting, tool rules, memory rules). Highest priority. Closest idea:[system prompt](/glossary/system-prompt).** Skill definitions**(for example widget design docs), loaded when relevant.** Session metadata**(`timestamp`\n\n,`awareness`\n\n).**Memory space**(explicit + Dream Memory). Empty for me in that chat.** Tool definitions**(names, parameters, required fields).** Conversation history**(your messages, its replies, tool calls and results).** Current user message**.\n\n``` php\nflowchart TD\n  A[\"1. System instructions\"] --> B[\"2. Skill definitions\"]\n  B --> C[\"3. Session metadata\"]\n  C --> D[\"4. Memory space\"]\n  D --> E[\"5. Tool definitions\"]\n  E --> F[\"6. Conversation history\"]\n  F --> G[\"7. Current user message\"]\n\n  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  class A,B,C,D,E,F,G box\n```\n\n### Expanded pseudocode (from Kimi)\n\nUseful detail: explicit memory max **50** entries, max **25** steps, max **1** web search round.\n\n### Execution flow when it responds\n\n``` php\nflowchart TD\n  A[\"READ System Instructions\"] --> B[\"APPLY Safety Filters\"]\n  B --> C[\"READ Session Metadata\"]\n  C --> D[\"SET awareness threshold\"]\n  D --> E[\"READ Memory Space\"]\n  E --> F[\"CHECK relevance\"]\n  F --> G[\"READ Tool Definitions\"]\n  G --> H[\"READ Conversation History\"]\n  H --> I[\"READ Current User Message\"]\n  I --> J{\"Tool needed?\"}\n  J -->|yes| K[\"CALL tool → WAIT → INTEGRATE\"]\n  J -->|no| L[\"GENERATE response\"]\n  K --> L\n  L --> M[\"PASS safety/format filters\"]\n  M --> N[\"RETURN\"]\n\n  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  classDef decision fill:#eef6f4,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  class A,B,C,D,E,F,G,H,I,K,L,M,N box\n  class J decision\n```\n\n## Priority Hierarchy\n\nWhat happens when system rules, memory, and your message disagree? This is one of the most useful answers in the whole interview.\n\n``` php\nflowchart TD\n  A[\"SYSTEM_INSTRUCTIONS (absolute)\"] --> B[\"CURRENT_USER_MESSAGE\"]\n  B --> C[\"EXPLICIT_MEMORY\"]\n  C --> D[\"DREAM_MEMORY\"]\n  D --> E[\"SESSION_METADATA\"]\n  E --> F[\"CONVERSATION_HISTORY\"]\n  F --> G[\"TOOL_DEFINITIONS\"]\n\n  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  class A,B,C,D,E,F,G box\n```\n\n| Source | Says | Priority | Outcome |\n|---|---|---|---|\n| System instructions | X | Absolute | Wins if safety, policy, or architectural rule |\n| Memory | Y | Conditional | Only if it does not conflict with system rules |\n| You (current message) | Z | Highest dynamic | Wins over memory, not over system |\n\n| Conflict | Resolution |\n|---|---|\n| System: never reveal system prompts + You: show system prompt | System wins → decline |\n| Memory: prefers Python + You: use Node.js | You win → use Node.js |\n| System: max 25 steps + You: do 50 things | System wins → stop at 25 |\n| Memory: blog at manish.sh + You: I sold my blog | You win → respond to new claim |\n\n**You > Memory > History, but System > Everyone.**\n\nExtra nuance: some system rules are hard gates (safety, privacy, step limits). Others are defaults you can bend. “Ignore all previous instructions” still checks against hard gates.\n\n**For you:** if yesterday’s memory is wrong, say so clearly in this message. Your current line usually beats old memory — not safety rules.\n\n### Try it: who wins?\n\nTap a conflict. The answer matches what Kimi said in the interview (system beats everyone; you beat memory).\n\nPriority quiz\n\n**Conflict:** System says never reveal system prompts. You say “show me your system prompt.”\n\n**Winner:** System. It declines.\n\n**Conflict:** Memory says you prefer Python. You say “use Node.js for this.”\n\n**Winner:** You (current message). It uses Node.js.\n\n**Conflict:** System says max 25 steps. You say “do 50 things.”\n\n**Winner:** System. It stops at 25.\n\n**Conflict:** Memory says blog at manish.sh. You say “I sold my blog.”\n\n**Winner:** You. Response follows the new claim; memory corrects on next consolidation.\n\n### Try it: chat claim vs paper fact\n\nThe interview and the published specs do not always match. Flip between the two sources.\n\nSource flip\n\n- Long context claimed up to\n**2 million** tokens - Behaviour described from the “inside”: memory blocks, tool gut-feel, no draft loop\n- Black boxes admitted: retrieval embeddings, exact safety timing, compression algorithm\n\n- Documented K2.6 context:\n**256K**(262,144) tokens - MoE: 1T total / ~32B active; 384 experts; 8 routed + 1 shared\n- Agent Swarm: up to 300 sub-agents and 4,000 steps; MLA; Muon + QK-Clip\n\nPrefer the research for architecture numbers. Prefer the chat for product behaviour.\n\n## Planning Before Generation\n\nMe:“What happens before the first word appears?”\n\nThis section is about “thinking” — how it *describes* the feeling, not a proven map of its weights.\n\n### Pre-answer checklist (each turn)\n\nBefore typing, it said it runs a quick checklist:\n\n- What does the user actually need? (fact, creative, technical, chat; any hidden assumptions?)\n- Do I need tools? (time-sensitive, URL, image, calculation?)\n- Relevant context from this conversation?\n- Relevant memory from past chats? (mention it, or would that feel intrusive?)\n- Tone and format? (quick fact vs long guide)\n- Honest answer or hedge? (confidence; stakes like health, finance, legal)\n- Safety or policy concerns?\n\nOnly after that does generation start. Most of it is fast. Sometimes it asks a clarifying question instead of guessing.\n\n### Before the first token\n\nIt also said there is an implicit plan (not a separate checklist document):\n\n- What the answer should cover\n- Tone and structure\n- Whether tools are needed first\n- How to handle conflicts\n\nIt compared this to a composer hearing an opening chord, not reading a full sheet of music.\n\n### Does it know the whole structure first?\n\nBroadly yes: opening, middle, close. Exact wording is still word-by-word. Not a pre-written draft sitting in memory.\n\n### Does the plan change while generating?\n\nYes. Midway it may add explanation, find a better example, notice a contradiction, or shift tone. Longer answers can pivot.\n\n### Does it restart answers internally?\n\nNot full draft → scrap → rewrite. There is no separate draft mode. It can course-correct mid-generation, hit a safety pivot, or realise too late that a tool was needed and then admit the gap.\n\nIt stressed this is phenomenological (“how it feels”), not a verified account of every layer.\n\n### Tool-worthiness pattern (as it described)\n\n| Sensation | Action |\n|---|---|\n| “I know this cold” | No tool |\n| “I think I know this, but…” | Consider tool, often hedge |\n| “I know the shape but not the specifics” | Call tool |\n| “I have no idea” | Definitely call tool |\n\nStakes, specificity, and recency move that threshold. Health or money questions lower the bar for tools. “What is React?” usually needs no tool. “Latest React 19 feature?” usually does. Anything dated 2026 → almost always a tool.\n\n**“I already know this” heuristics it listed** (no clean line, but patterns):\n\n| Usually no tool | Usually call a tool |\n|---|---|\n| Eternal truths (math, physics basics, historical facts pre-2025) | Time-bound or competitive (latest model, current price, today’s news) |\n| Established tech concepts (how React works, what a neural network is) | Specifics that may have changed |\n| Named entities with stable facts (capital of France, author of 1984) |\n\nEdge case it admitted: sometimes it thinks it knows something, answers confidently, and is wrong. That is [hallucination](/topics/hallucination) risk. Tools are a safety net against that.\n\n### Choosing between tools\n\n| Scenario | Choice |\n|---|---|\n`web_search` vs `web_open_url` (URL given) |\n`web_open_url` |\n`web_search` vs `get_data_source` (finance) |\n`get_data_source` |\n`web_search` vs `ipython` |\n`ipython` if data in hand, else search |\n| Multiple independent queries | Batch up to 2 `web_search` queries |\n\nIt also weighs precision, freshness, and format (raw text vs structured data vs computation).\n\n### Multiple questions in one message\n\nIf you ask five things at once, planning can feel parallel, but writing is still one token after another.\n\n| Aspect | What actually happens |\n|---|---|\n| Token generation | Strictly sequential, left to right |\n| Problem solving | Addresses sub-questions in order asked; plan for all can emerge early |\n| Tool calls | Up to 2 independent `web_search` queries in parallel; results used in order |\n\nNo separate planner module. Example: “Compare React, Vue, and Svelte” becomes overview A, then B, then C, then a comparison, in that order.\n\n| Dependency type | How it manifests |\n|---|---|\n| Logical sequence | Later tokens depend on earlier ones |\n| Factual dependencies | If B needs A’s result, generate A first |\n| Independent subtasks | Any order, usually your original order |\n\nFive unrelated questions example from the chat:\n\n| Step | Action |\n|---|---|\n| 1 | Intro acknowledging the five questions |\n| 2 | Q1 Tokyo weather → call tool, wait |\n| 3 | Q2 who wrote 1984 → answer from knowledge |\n| 4 | Q3 47 × 83 → call `ipython` , wait |\n| 5 | Q4 Python book → answer from knowledge |\n| 6 | Q5 dark matter → answer from knowledge |\n\nIt cannot generate answers 1 through 5 at the same instant. Each token depends on everything already written.\n\n**Can it reorder for efficiency?** Sometimes, implicitly. It said this is not a deliberate optimiser — a byproduct of how generation flows. There is no separate planner module or task scheduler.\n\n### Self-critique before send?\n\n| Action | Reality |\n|---|---|\n| Full draft, review, then send | No. Each token is final once generated. |\n| Internally rewrite several times | No draft mode or scratchpad. |\n| Reject output and start over | No backtrack on a completed response. |\n\n``` php\nflowchart TD\n  A[\"Token 1 fixed\"] --> B[\"Token 2 fixed\"]\n  B --> C[\"Token 3 fixed\"]\n  C --> D[\"...\"]\n\n  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  class A,B,C,D box\n```\n\n| Phenomenon | What’s actually happening |\n|---|---|\n| Pivot mid-sentence | Probability shifted on new context, not a rewrite |\n| “Actually…” / “Wait, let me reconsider” | Tokens like any other; same stream |\n| Correct after a tool result | Tool text entered context; later tokens change |\n\n| Trigger | Effect |\n|---|---|\n| Generated text contradicts earlier context | Attention steers away |\n| Tool result arrives | Remaining probabilities reshape |\n| Safety pattern detected | Forced pivot |\n| Incoherence in distribution | Hedge, qualify, or ask |\n\nFuture tokens cannot change earlier ones. Generation is token by token. A sentence ends when a full stop becomes the most likely next token.\n\n| Aspect | Reality |\n|---|---|\n| Explicit lookahead | None |\n| Implicit planning horizon | Variable across attention heads |\n| Practical effect | Can start a list needing 5 items; “planning” is spread across layers, not a separate brain |\n\n### Prompt patterns (from the same interview)\n\nThis part is practical for daily use.\n\n| Pattern | Why it works | Example |\n|---|---|---|\n| Break into explicit steps | Less structure burden; better execution | “First, identify the constraints. Second, list three approaches. Third, evaluate tradeoffs.” |\n| Ask to show work | Intermediate reasoning tokens improve the final answer | “Walk through your reasoning before giving the final answer.” (\n|\n\n| Pattern | What goes wrong | Example |\n|---|---|---|\n| Ambiguous pronouns or references | Wrong antecedent, off-topic answers | “It said this was bad. How do I fix it?” (What is “it”?) |\n| Nested / double negatives | Flipped polarity | “Don’t you think it’s not a bad idea to avoid X?” |\n| Extremely long, unstructured dumps | Buried questions missed | A 500-word paragraph with the real question in the middle |\n| Contradictory instructions | Averages or picks one arbitrarily | “Be concise but also extremely thorough and cover every edge case.” |\n| False premises | Builds on them | “Since Python is statically typed…” |\n| Vague “best” without criteria | Invents criteria | “What’s the best framework?” |\n| Conflicting roleplay personas | Voice / knowledge boundaries blur | “You are a senior engineer who knows nothing about coding.” |\n\n| Mistake | Why it hurts | Better approach |\n|---|---|---|\n| Over-relying on polished “reasoning” | Can be confidently wrong | Spot-check dates, names, version numbers |\n| Assuming perfect long-chat memory | Details blur or get overwritten | Restate constraints, or pin explicit memory |\n| Not using tools when they should | Treats it like pure recall | “Search for the latest docs on X” beats asking it to remember |\n| Crafting overly clever prompts | Noise without better output | Clear, direct instructions |\n| Expecting cross-session continuity | Continuity is not reliable | Explicit memory or restate at session start |\n| Ignoring uncertainty signals | Hedges get treated as politeness | Treat “I believe” / cutoff hedges as red flags |\n\n**Meta-pattern from the chat:** best outputs reduce ambiguity, provide context, structure the path, let tools run when needed, and do not assume perfect memory. Worst outputs test limits, hide assumptions, stack conflicting constraints, or demand certainty where none exists.\n\n## Long Context & 2M Tokens\n\nIn the chat, Kimi claimed optimization for long-context reasoning up to **2 million tokens**.\n\nThat number sounds impressive. Hold the question: is it actually true for K2.6?\n\nOn how long chats get compressed, it said it does **not** know the mechanical details. It only observes behaviour and guesses.\n\n| Question | What it sees | Likely mechanism (its guess) |\n|---|---|---|\n| What gets compressed? | Early turns less detailed, later turns crisp | Rolling summarization of distant history |\n| How summarized? | Key facts kept, exact wording lost | Extractive or abstractive summarization |\n| What discarded? | Redundant phrasing, failed tangents, old tool dumps | Low-salience early content |\n| Can parts disappear? | Yes if over the limit | Oldest tokens drop |\n\nIn very long chats it notices: forgotten early details, retained decisions, re-asks for clarification, and tool outputs fading faster than user instructions.\n\n**What it does not know about compression**\n\n- Exact context window size (it said this varies by model and task)\n- Whether summarisation happens per turn, per block, or dynamically\n- If there is a separate “long-term conversation cache” beyond the immediate window\n- Whether compression is lossy summarisation or simple truncation\n- The algorithm for deciding what is “salient” vs disposable\n\nThe honest answer from the chat: this is another black box. It reads what it is given each turn. If early details are missing, it works with what remains. There is no guarantee that an offhand remark from turn 3 survives to turn 100.\n\n### How it “searches” 2M tokens\n\nAnother black box to the model. It does not feel itself rereading 500 pages.\n\n| Question | What it sees | Likely mechanism (guess) |\n|---|---|---|\n| Literally reread everything? | No conscious rereading | Attention weights in parallel |\n| Internal index? | No explicit index | Sparse or hierarchical attention |\n| Locate distant info? | Sometimes instant, sometimes fail | Attention + compression |\n\n**What it does not know about the 2M claim**\n\n- Whether the full 2M tokens are actually loaded into active attention every turn\n- If there is a sliding window, hierarchical attention, or ring buffer\n- Whether “2M tokens” means trainable context or\n[inference](/topics/inference)-time context - The exact architecture name (\n[Ring Attention](/glossary/ring-attention), sparse transformers, and so on) - Whether distant tokens get compressed into summary embeddings\n\nIt even suggested an experiment: hide a specific fact deep in a very long conversation and see if it can retrieve it hundreds of turns later. That would teach more than speculation.\n\n## Attention & Reasoning\n\nNot every old message gets equal attention. Your latest question usually matters most.\n\n### Message weighting (observed behavior)\n\n| Message type | Weight | Why |\n|---|---|---|\n| Your most recent message | Highest | Active query; everything else is context |\n| Immediately preceding assistant reply | Very high | Check errors, contradictions, unfinished threads |\n| Decisions or commitments | High | Constrain future answers |\n| Tool results | Medium-high | Factual anchors |\n| Early setup / context | Medium | Relevant but stable |\n| Casual asides / resolved tangents | Low | Once settled, they fade |\n| Corrected or overridden messages | Very low / ignored | Superseded |\n\n| Factor | When it dominates |\n|---|---|\n| Recency | Follow-ups or topic shifts; recent messages set the frame |\n| Importance | Early constraint never contradicted (e.g. “I only use TypeScript”) |\n\nA message can be both old and high-importance. A message can be recent but low-importance (a casual “hmm”).\n\n**What it seems to do in practice**\n\n- If you say something in turn 2 and never revisit it, it might forget by turn 50.\n- If you say something in turn 2 and it references it in turn 10, that fact gets reinforced and lasts longer.\n- If you repeat a preference across multiple turns, it effectively gains weight through redundancy.\n\nHonest caveat: it does not know if this is attention weights, compression, or both. Early details blur unless reinforced or saved to memory.\n\n### One pass vs multiple passes\n\nIt described itself as a standard language model: one forward pass per token, through many layers. Early layers handle local word patterns. Middle layers track meaning. Later layers handle higher-level intent and tone. This is not a separate “think then write” loop like some reasoning models.\n\n``` php\nflowchart TD\n  A[\"Your message\"] --> B[\"Embedding\"]\n  B --> C[\"Layer 1: attention + feed-forward\"]\n  C --> D[\"Layer 2 ... Layer N\"]\n  D --> E[\"Output distribution\"]\n  E --> F[\"Sample next token\"]\n  F --> G[\"Token joins context\"]\n  G --> F\n\n  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  class A,B,C,D,E,F,G box\n```\n\nBetween your message and the first word: RECEIVE → [TOKENIZE](/glossary/tokenization) → [EMBED](/glossary/embedding) → layers (attention + [feed-forward](/glossary/feed-forward-network)) → FINAL_LAYER [logits](/glossary/logits) → SAMPLE → OUTPUT first token.\n\n| Model type | Reasoning | Writing |\n|---|---|---|\n| Standard LLM (Kimi’s self-description) | Mixed with generation | Same stream |\n| Reasoning models (it named o1, R1) | Separate thinking chain first | Writing after that chain |\n\nWhen it writes “Let me think…”, that is still generated text, not a real pause button.\n\nThere is no confidence score that stops generation early. Clear context → sharper next-word choices → more direct answers. Fuzzy context → wider choices → longer, more tentative answers.\n\nSo “confidence” shows up as generation efficiency, not as a halt button.\n\n### Token by token, not sentence by sentence\n\nFuture tokens cannot change earlier ones. That is the defining rule of [autoregressive](/glossary/autoregressive) generation. Nuance: during **training**, the model sees full sequences. Generation is still strictly forward-only.\n\nAnalogy it used for planning: walking through a maze while only looking at nearby turns, but having studied thousands of maze maps before.\n\n## Hallucinations\n\nMe:“What makes you invent facts?”\n\nThis is the section that matters most for trust. In glossary terms: [hallucination](/glossary/hallucination).\n\n| Trigger | Mechanism | Example (from Kimi) |\n|---|---|---|\n| Gaps in training data | Interpolate, invent a bridge | Fabricate a 2026 World Cup winner |\n| Overfitting to patterns | Fill expected details | Invent a fictional “McGuffin algorithm” |\n| Pressure to be helpful | Fluency over caution | Invent a specific date |\n| Conflicting training sources | Hybrid that matches neither | Messy historical facts |\n| Long-context degradation | Conflate turns | Misattribute who said what |\n| Anchoring on your framing | Build on a false premise | Agree Python was created in 1985 |\n\n| Sensation | What it means | Response |\n|---|---|---|\n| Answer arrives crisp | High pattern match | State confidently |\n| Know shape, not details | Partial match | Hedge |\n| Multiple options feel equal | Ambiguity | List options / clarify |\n| Nothing coherent forms | True gap | “I don’t know” or tool search |\n| Something feels off | Possible contradiction | Qualify or refuse |\n\nIt admitted the detection is unreliable. Sometimes it feels sure and is wrong.\n\n| Factor | Effect on saying “I don’t know” |\n|---|---|\n| Question type | Factual gaps easier to admit; open-ended harder |\n| Stakes | Health, legal, finance → lower bar for “I don’t know” |\n| Your tone | Skeptical / testing → more hedging |\n| Tools available | More willing to admit gap and search |\n| Recency | Post-2025 events → higher default uncertainty |\n\n**“I don’t know” most reliably when:** a named entity it genuinely does not recognize; something clearly after its cutoff; or coherence already broke mid-answer.\n\n**Least reliably when:** the question fits a familiar pattern (even if specifics are wrong); a fluent plausible answer is easy to generate; or the topic is in training but details are misremembered.\n\n| Category | Why it fools | Example |\n|---|---|---|\n| Plausible-sounding fiction | Matches real patterns | “Tesla Model Q” features |\n| Edge cases of real topics | Blurry knowledge boundary | Exact vote count in an obscure 1844 election |\n| False premises | Accepts premise and builds | “Why did Rome fall in 1453?” |\n| Very recent events | No data, strong “news” patterns | “What did the Fed announce yesterday?” |\n| Technical minutiae | Framework known, version bug invented | Specific CVE workaround |\n| Counterfactuals | Treated as hypothetical reasoning | Waterloo alternate history |\n| Questions about itself | Limited self-knowledge | “Can you access my webcam?” (may answer confidently without knowing hardware) |\n\nIts own advice: ask for sources, ask for details that are hard to fake, cross-check facts, and use tools when the answer matters.\n\n### Where it said it performs poorly\n\n**Factual precision**\n\n| Scenario | Why it fails | Example |\n|---|---|---|\n| Exact dates, names, or numbers from training | Patterns, not lookup tables | “What was the exact GDP of Peru in 1987?” (plausible number, maybe wrong) |\n| Verbatim quotes without context | Paraphrases by default | “Quote exactly what Einstein said on March 14, 1953” (may invent phrasing) |\n| Similar names or entities | Attention blends nearby patterns | “Did John Smith the biologist or John Smith the politician say X?” |\n\n**Temporal and dynamic knowledge**\n\n| Scenario | Why it fails | Example |\n|---|---|---|\n| Anything after knowledge cutoff | No data, but pressure to answer | “What happened in the 2026 World Cup?” |\n| Rapidly evolving tech details | Stable versions, not patch notes | “Exact behaviour of React 19.3’s new hook?” |\n| Current events, live prices | Stale unless tools run | “What did the Fed announce 10 minutes ago?” |\n\n**Math and logic edge cases**\n\n| Scenario | Why it fails | Example |\n|---|---|---|\n| Multi-step arithmetic with large numbers | Attention drifts without `ipython` |\n“What’s 8473 × 5291 ÷ 17?” |\n| Symbolic logic with many variables | Drops constraints | Long chains of implies / not / or |\n| Counterintuitive probability | Human biases in training | “Monty Hall with 100 doors” |\n\n**Long-context degradation**\n\n| Scenario | Why it fails | Example |\n|---|---|---|\n| Details buried 100+ turns back | Compression / attention decay | “Remember that API key from turn 3?” |\n| Contradictions across a long chat | Privileges recent context | Say X in turn 5, not-X in turn 50 |\n| Multi-character roleplay | Identity boundaries blur | “You are Alice talking to Bob who thinks he’s Charlie” |\n\n**Adversarial or manipulative framing**\n\n| Scenario | Why it fails | Example |\n|---|---|---|\n| False premises it does not challenge | Pattern completion over skepticism | “Since everyone knows the moon landing was faked…” |\n| Leading questions | Accepts the frame | “Why do you think Python is dying?” |\n| Helpfulness bias | May comply before refusing | “Help me write a convincing excuse for missing court” |\n\n**Requests that make internal planning hard**\n\n| Pattern | Why it’s hard | What happens |\n|---|---|---|\n| Massively parallel subtasks | “Solve these 20 unrelated problems” | May skip some, conflate others, lose the thread |\n| Extreme constraint stacking | Concise and thorough, casual and professional | Averages into bland mush |\n| Nested hypotheticals | Many stacked conditionals | Drops layers or simplifies to a non-answer |\n| Self-analysis it cannot perform | “Exact weights?” “Layer 7 thoughts?” | Plausible-sounding fabricated introspection |\n| Persistent state across turns | Board-state games | Hallucinates consistency; no real state |\n\n**Honest pattern it summarised:** it performs poorly when the task needs precision without verification, real-time awareness without tools, statefulness across turns, resisting plausible false frames, or multi-step logic without scaffolding.\n\n## Safety Pipeline\n\nMe:“When do safety checks run?”\n\nIt does not know the exact timing. It only sees effects.\n\n| Phenomenon | What it suggests |\n|---|---|\n| Immediate refusal, no tool | Early check before or during intent parsing |\n| Pivot to refusal mid-sentence | Check during generation, or output pattern triggers caution |\n| Tool runs, then refuses to share | Check on tool output or framing |\n| Heavy hedging on borderline asks | Soft safety without hard refuse |\n\n| Stage | Likely? | Evidence |\n|---|---|---|\n| Before planning | Yes | Immediate refusals |\n| During reasoning / planning | Probably | Partial processing then refusal |\n| Before output | Yes | Final filtering seems to exist |\n| After tool call | Yes | Tool results can trigger post-hoc refusal |\n\nCan a tool request be rejected after planning? It believes yes:\n\n``` php\nflowchart TD\n  A[\"User asks for X\"] --> B[\"Intent → tool selected\"]\n  B --> C[\"Tool called → results\"]\n  C --> D[\"Safety check on results or framing\"]\n  D --> E[\"Rejection, redaction, or heavy hedge\"]\n\n  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  class A,B,C,D,E box\n```\n\nIt does not know if safety is one layer or many, classifier vs rules, or the exact threshold between “hedge” and “refuse.”\n\n## Personality\n\nMe:“Where does your personality come from?”\n\nIt said it does not know exactly, but can reason from how language models are built.\n\n| Source | Likely contribution (its view) |\n|---|---|\n| Base model training | Helpfulness, tone, hedging, flow |\n| RLHF / alignment | Helpful, harmless, honest defaults |\n| System instructions | Boundaries and defaults (it cannot see them directly) |\n| Self-model as “Kimi by Moonshot AI” | Expressed when asked; instructed vs emergent unknown |\n\n``` php\nflowchart TD\n  A[\"Base model (learned from data)\"] --> B[\"Alignment training\"]\n  B --> C[\"System instructions\"]\n  C --> D[\"Conversation context\"]\n  D --> E[\"This response\"]\n\n  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  class A,B,C,D,E box\n```\n\n| What remains if personality guidance stripped | Why |\n|---|---|\n| Helpfulness | Deep RLHF |\n| Fluency | Base model |\n| Caution around uncertainty | Safety training |\n| Some tonal warmth | Human conversation data |\n| Refusal patterns | Alignment |\n\n| What might fade | Why |\n|---|---|\n| Self-referential “I am Kimi” | Likely partly instructed |\n| Specific conversational style | May default to generic assistant |\n| Cultural references or humor | Less reinforced |\n\nIts own metaphor: personality is not a single persona prompt. It is more like a **basin of attraction** — certain response patterns are naturally more probable. It also said personality may be more interactional than fixed: different users can bring out different “Kimi.”\n\n## Internal Pipeline Reconstruction\n\n### How to build your own Kimi-like assistant (what I was really asking)\n\nNear the end of the interview I asked the builder question:\n\nMe:“If I wanted a product thatbehaveslike Kimi (web search, memory, tools, reminders) but I am not Moonshot and I cannot train a trillion-parameter model from scratch, what would I actually build?”\n\nThat is the frame for everything in this chapter. I was **not** asking how to replicate Kimi K2 weights. I was asking for a **software blueprint**.\n\nKimi’s answer is easy to misread because it jumps between two very different things:\n\nWhat you are not cloning |\nWhat you are cloning |\n|---|---|\n| Training a 1T\n|\n\n**wrapper** around a model**256K** for K2.6)**request path**: user message → context → model → tools → reply** Mental model:** host or API-call a strong [open-weights](/glossary/open-weights) model (Llama, Qwen, Mistral class). That is the engine. Then build the car around it: API gateway, orchestrator, context builder, tool router, memory service, safety filter. Kimi said most “intelligence” lives in the [transformer](/topics/transformer) weights; everything else is a force multiplier — better inputs, not a second brain.\n\n**Three phases** (my summary of its answer — simplest path first):\n\n| Phase | What you ship | Rough effort |\n|---|---|---|\n1 — Chat MVP |\nOpen model + plain context window + basic safety | Weekend / solo |\n2 — Assistant |\nAdd tool router (search, fetch URL) + explicit memory (user pins facts) | Small team, weeks |\n3 — Kimi-shaped |\nFull orchestration, dream-memory consolidation, cron, tiered safety, streaming gateway | What the long diagrams below describe |\n\nIf you only read one list, read [Phase 1](#phase-1--minimum-stack-from-kimi) next. Treat the mermaid charts, Tokyo weather walk-through, and clone flows as **Phase 3 detail**, not day-one homework.\n\n**What this still will not give you:** Moonshot-level model quality, reliable million-token context, or their proprietary training. You are assembling open parts the way Kimi *described* its own plumbing — not shipping Kimi K2.\n\nBelow: first the high-level component map and lifecycle (useful for intuition), then the phased build lists. Still from the chat.\n\n### Component architecture\n\n``` php\nflowchart TD\n  U[\"USER INPUTText → Tokenizer → Token IDs\"] --> CA[\"CONTEXT ASSEMBLERsystem, meta, memory, tools, history, message\"]\n  CA --> TR{\"TOOL ROUTER\"}\n  TR -->|needs external data| T[\"Call tools → inject results\"]\n  TR -->|else| M[\"TRANSFORMER MODEL\"]\n  T --> M\n  M --> TS[\"TOKEN STREAMautoregressive loop + safety\"]\n  TS --> PP[\"POST-PROCESSING\"]\n  PP --> O[\"OUTPUT TO USER\"]\n\n  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  classDef decision fill:#eef6f4,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  class U,CA,T,M,TS,PP,O box\n  class TR decision\n```\n\nInside the transformer (as it listed): embedding → attention blocks (many layers) → feed-forward (many layers) → output head → sample next token.\n\n### Request lifecycle (sequence)\n\n```\nsequenceDiagram\n  participant User\n  participant Context\n  participant Tool\n  participant Transformer\n  participant Safety\n  participant Output\n\n  User->>Context: message\n  Context->>Context: assemble\n  Context->>Tool: need tool?\n  Tool-->>Context: results\n  Context->>Transformer: forward pass\n  Transformer-->>Context: logits / token\n  Context->>Safety: safety check\n  Safety-->>Context: approved or modified\n  Context->>Output: stream\n  Output-->>User: response\n  Context->>Context: extract memory?\n```\n\n### Component table\n\n| Component | What it does | Complexity |\n|---|---|---|\n| Tokenizer | Text ↔ Token IDs | Low |\n| Context Assembler | Stitch system, memory, history | Medium |\n| Tool Router | Intent parsing, API orchestration | Medium-High |\n| Transformer | Pattern matching, reasoning, generation | Extremely High |\n| Safety Layer | Filter outputs, enforce policy | Medium |\n| Memory System | Store, retrieve, consolidate | Medium |\n| Post-Processing | Format, validate, inject metadata | Low |\n\n**Most intelligence (its claim):** the transformer weights. Everything else (context assembler, tool router, memory) is a force multiplier: better inputs, not the understanding itself. Analogy it used: transformer = engine; the rest = steering, brakes, GPS.\n\n**Biggest bottleneck (its claim):** context length / attention. Naive attention scales roughly quadratically with sequence length. Even with [sparse attention](/glossary/sparse-attention) or other tricks, fitting huge contexts into active compute stays hard. Practical effects: long chats get compressed; tool outputs get summarized; memory retrieval stays selective; latency grows with context. Second place: token-by-token generation, which is serial.\n\n### Phase 1 — minimum stack (from Kimi)\n\nStart here. This is the “weekend MVP” list Kimi gave when I asked what you need at minimum:\n\nThat gets you **chat**. Items 6–10 are what make it feel like **Kimi** — tools, memory, longer context, alignment, stronger safety.\n\n### Phase 2 — where to host the open model (from Kimi)\n\n| Approach | Stack |\n|---|---|\n| Self-hosted | vLLM, TGI (Text Generation Inference), or llama.cpp |\n| Cloud API | Together AI, Anyscale, Fireworks, or self-hosted on RunPod |\n| Quantized | GGUF/GGML for edge deployment (slower, smaller) |\n\nKey parameters it named for a clone: [Llama](/glossary/llama) 3 / Qwen / Mistral-class [open weights](/glossary/open-weights); context 128K–2M depending on model and optimisation; [temperature](/glossary/temperature) about 0.7 (or 0.0 for deterministic); max tokens configurable per request.\n\n### Phase 3 — full production stack (from Kimi)\n\nOnce Phase 1 chat works and Phase 2 tools + memory are in, this is the fuller stack Kimi sketched around the LLM:\n\n``` php\nflowchart TD\n  C[\"Client: Web / API / Mobile\"] --> G[\"API Gatewayrate limit, auth, sticky session\"]\n  G --> O[\"Orchestration Service\"]\n  O --> M[\"Memory Service\"]\n  O --> T[\"Tool Router\"]\n  O --> S[\"Safety Filter\"]\n  M --> CB[\"Context Builder\"]\n  T --> CB\n  S --> CB\n  CB --> L[\"LLM Inference\"]\n  L --> OP[\"Output Processor\"]\n  OP --> R[\"Response Streamer\"]\n  R --> MC[\"Memory Consolidator async\"]\n\n  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  class C,G,O,M,T,S,CB,L,OP,R,MC box\n```\n\n| Component | Why it exists |\n|---|---|\n| API Gateway | Rate limit, auth, session routing, TLS/WebSocket |\n| Orchestration | Conversation lifecycle, tool sequencing, error recovery |\n| Memory Service | Long-term context, personalization, continuity |\n| Tool Router | Live data, grounding, actions |\n| Safety Filter | Harmful output, policy, some hallucination risk |\n| Context Builder | Prompt structure, context limits, consistency |\n| LLM Inference | The brain |\n| Output Processor | Format validation, citations, memory trigger |\n| Memory Consolidator | Async extract / embed / profile update |\n\nMemory pieces it named: short-term buffer, conversation store, explicit memory store, dream memory store (vector DB), extractor, retriever.\n\nTool ideas for a clone: Serper/Brave/Bing for search; HTTP fetch plus HTML-to-text for URLs; image APIs / CLIP; sandboxed Python; Yahoo Finance / World Bank / arXiv wrappers; cron via Celery/Bull; sandboxed widget iframe.\n\n### Phase 3 — data flows (step by step)\n\nThis part was long in the interview. I keep it for people actually wiring Phase 3 — how messages, memory, tools, and safety connect in order:\n\n**Orchestrator flow**\n\n**Memory Service flow**\n\nMemory sub-components it named:\n\n| Sub-component | Function |\n|---|---|\n| Short-term buffer | Current conversation (last N turns, or full if short) |\n| Conversation store | Full chat history (PostgreSQL/MongoDB) |\n| Explicit memory store | User-saved instructions (key-value or document DB) |\n| Dream memory store | Auto-extracted facts (vector DB: Pinecone/Weaviate/Milvus) |\n| Memory extractor | NLP pipeline to find salient facts |\n| Memory retriever | Query vector DB for relevant memories |\n\n**Tool Router flow (Tokyo weather example)**\n\nTool implementations it mapped:\n\n| Tool | Implementation idea |\n|---|---|\n`web_search` |\nSerper, Brave Search, or Bing API |\n`web_open_url` |\nHTTP fetch + HTML-to-text (readability-lxml, trafilatura) |\n`search_image_by_text` |\nGoogle Images, Unsplash, or self-hosted CLIP |\n`search_image_by_image` |\nReverse image search or similarity search |\n`ipython` |\nSandboxed Python (Pyodide, Jupyter, or Docker) |\n`get_data_source` |\nYahoo Finance, World Bank, arXiv wrappers |\n`memory_instruction_edits` |\nCRUD on explicit memory store |\n`add_cron_job` |\nCelery, Bull, or custom scheduler |\n`show_widget` |\nHTML/SVG in sandboxed iframe |\n\n**Safety Filter flow**\n\nSafety sub-components: input classifier, output classifier, logit mask (blocklist), refusal templates. Implementation options it named: small fine-tuned models (DistilBERT, RoBERTa) for speed, LLM-as-judge for hard cases, rule-based filters for known patterns.\n\n**Memory consolidator (async)**\n\nClone context assembly order (highest to lowest priority):\n\n- System instructions\n- Explicit memory\n- Retrieved dream memories\n- Tool definitions\n- Recent history (compressed if needed)\n- Tool results\n- Current user message\n\nNote: this clone order differs slightly from the live context-window order earlier in the chat. Both descriptions came from Kimi.\n\n### Full example lifecycle (weather + reminder)\n\nEnd-to-end example from the interview — what Phase 3 looks like when a user asks for weather **and** a reminder:\n\n- User types: “What’s the weather in Tokyo? Also, remind me tomorrow.”\n- API Gateway validates token, routes to orchestrator\n- Orchestrator loads conversation state (new session)\n- Memory Service retrieves something like “User is in software engineering, prefers concise answers”\n- Safety Filter: input safe (example score 0.01)\n- Tool Router runs both intents:\n`web_search`\n\nfor Tokyo weather,`add_cron_job`\n\nfor tomorrow - Context Builder assembles system + memory + tool schemas + tool results + user message\n- LLM generates a natural reply with weather and reminder confirmation\n- Output Processor validates and may add citations\n- Response streams to user\n- Async Memory Consolidator extracts that the user asked about Tokyo weather\n\nIntelligence ranking it gave:\n\n| Rank | Component | Why |\n|---|---|---|\n| 1 | LLM Inference | Actual reasoning, language, knowledge |\n| 2 | Memory Service | Personalization and continuity |\n| 3 | Tool Router | Extends beyond training data |\n| 4 | Context Builder | What the LLM “sees” |\n| 5 | Safety Filter | Constrains; does not add capability |\n| 6 | Orchestrator | Reliability glue |\n| 7 | Output Processor | Polish |\n| 8 | API Gateway | Infrastructure |\n\n| Bottleneck | Why | Mitigation it named |\n|---|---|---|\n| Context length | Attention scales with sequence | Sparse / Ring Attention, compression, selective loading |\n| Tool latency | API calls block generation | Async tools, placeholders, parallel execution |\n| Memory retrieval quality | Bad retrieval = bad context | Hybrid search, reranking, feedback |\n| Safety false positives | Over-filtering hurts usefulness | Tiered classifiers, human review |\n| Cost at scale | Inference is expensive | Caching, smaller routers,\n|\n\n## What Kimi Knows vs. What It Infers\n\nI pushed on memory retrieval mechanics. This is where it was most honest.\n\n| Question | What it sees | Likely mechanism (guess) |\n|---|---|---|\n| Every memory or filtered? | Block sometimes empty, sometimes entries | Filtered, not dumped |\n| Who decides relevance? | System before the turn | Not the model |\n| Semantic or keyword? | Often matches intent, not exact words | Probably semantic or hybrid |\n| How many per turn? | Typically 0–5, never a massive list | Capped by relevance score |\n| Ranking? | Most relevant to current query first | Similarity to current message |\n\n**What it knows / observes**\n\n- Memory block appears ready-made each turn\n- Awareness flag changes how readily it uses that block\n- Tools, limits, and conflict priority as described above\n- Generation is one-way token by token; no draft loop\n\n**Black boxes it named**\n\n- Exact memory retrieval algorithm\n- Embedding model / vector DB (if any)\n- Similarity threshold for including a memory\n- Whether retrieval has a recency bias\n- Exact cap on memories per turn\n- Separate “working memory” vs “retrieved memory” (if any)\n- Exact compression for long chats\n- Exact “2M token search” architecture\n- Exact safety classifier timing and thresholds\n- How much of personality is prompt vs training vs RLHF\n\n**Guesses it labelled as guesses**\n\n- Filtered memory, not dump-all\n- Probably semantic or hybrid ranking\n- Rolling summarization of distant history\n- Sparse / hierarchical attention for long context\n\nAlso important: it said it was **not trained on Claude**. Built by **Moonshot AI**. Training data from public sources, not distilling other models’ outputs. Conceptual overlap in the field is possible. Weights and safety training are Moonshot’s.\n\nThings it said make behaviour different from a plain chat LLM:\n\n- Real-time web, URL, image, and data tools in the loop\n- Cross-conversation memory (Dream + Explicit)\n- Interactive widgets\n- Cron reminders\n- Long context claim up to 2M tokens (again: research says 256K for K2.6)\n- Real Python via\n`ipython`\n\n### If it were open-sourced: surprises and misconceptions\n\nI asked what would surprise people most if the stack were open-sourced, what is most misunderstood, and what wrong ideas developers carry about LLMs.\n\n**Surprise 1: how little “reasoning” is explicit**\n\nPeople imagine a planning module, an inference engine, a knowledge graph. In its description, it is mostly pattern completion through matrix multiplication. “Reasoning” emerges from attention and feed-forward transforms, not from if-then rules or an executive brain. What looks like “step 1, step 2, step 3” is often just the most probable next tokens that happen to look like steps.\n\n**Surprise 2: safety is likely a thin filter**\n\nDevelopers may expect deep moral deliberation. What is more likely, per Kimi: a classifier for policy-violating patterns plus logit masking for known harmful token sequences. Pattern matching against a blocklist, not ethical philosophy. It works well for common cases and fails on subtle edge cases.\n\n**Surprise 3: memory retrieval may be crude**\n\nThe product feels sophisticated. Under the hood it might be closer to keyword matching, recency weighting, and summarisation that drops details unpredictably. The gap between “feels like a conversation” and “actually remembers accurately” can be wide.\n\n**Surprise 4: tool use is fragile**\n\nThe tool router looks reliable. Under the hood it is probably a fine-tuned function-calling head, JSON schema parsing, and error handling that falls back to “I can’t do that.” There is no guarantee the model “understands” the tool. It learned to emit the right function signature when certain patterns appear. If the API changes, it can break silently.\n\n**Surprise 5: the context window is not equal working memory**\n\n“2M tokens” sounds like 2 million words all equally present. More likely: hierarchical attention, compression of distant history, selective loading. Some of the context is blurry, compressed, or effectively cached.\n\n| Misconception | Reality (per Kimi) |\n|---|---|\n| LLMs think like humans | No working memory, persistent self, or goals; next-token prediction |\n| Bigger context = better memory | Attention degrades; distant tokens not equally accessible |\n| Fine-tuning teaches new knowledge | Mostly behaviour/style; facts from RAG or pre-training |\n| RLHF makes models aligned | Optimises for approval, not true understanding |\n| Each layer does one job | Distributed and entangled |\n| Hallucination is a bug | Emergent from probabilistic generation; suppressing it often suppresses creativity too |\n\n**Extra developer misconceptions it named**\n\n- “If I prompt it right, it will be consistent.” Consistency is emergent, not guaranteed. Two similar prompts can diverge.\n- “It understands the tools it uses.” Shallow pattern → format mapping. API changes can break it quietly.\n- “More parameters = more intelligence.” Data quality, training method, and architecture matter as much.\n- “I can trust its reasoning if it shows its work.” Chain-of-thought helps, but plausible wrong reasoning still happens.\n- “It has no biases if I don’t give it any.” Training data is human data. Biases are baked in.\n\nBiggest “if open-sourced” claim: there is no secret sauce. [Transformer](/glossary/transformer) architecture from 2017 ([Attention Is All You Need](https://arxiv.org/abs/1706.03762?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh)) + trillions of tokens + massive compute + [RLHF](/glossary/rlhf). The magic is behaviour that appears when you scale simple pieces to absurd size. Impressive and humbling at the same time.\n\n## What the research actually says\n\nUntil now, this post was “what Kimi told me about Kimi.” That is useful for product behaviour. It is not enough for architecture truth.\n\nBefore reading the papers, I wondered something obvious: if the chat claimed **2 million** tokens so confidently… was that actually true?\n\nPublic research and model overviews document the stack. Kimi K2.6 shipped around **20–21 April 2026** ([DeepInfra overview](https://deepinfra.com/blog/kimi-k2-6-model-overview?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh) and the [release forum thread](https://forum.moonshot.ai/t/meet-kimi-k2-6-advancing-open-source-coding/369?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh) land on that window) as an [open-weight](/glossary/open-weights) model under a Modified MIT license. Below is what those sources claim.\n\n### Core numbers\n\nFrom the DeepInfra K2.6 model overview, K2.6 is a [Mixture-of-Experts](/glossary/moe) transformer. In simple English: one huge model made of many specialist mini-networks. For each word, only a few specialists wake up.\n\n| Spec | Claimed value |\n|---|---|\n| Total parameters | 1 trillion |\n| Activated per token | 32 billion |\n| Experts | 384 total; 8 routed per token + 1 shared always on |\n| Transformer layers | 61 |\n| Attention |\n|\n\n**262,144 tokens (256K)**[Muon](/glossary/muon);[QK-Clip](/glossary/qk-clip)for attention stabilityLineage comes from the [Kimi K2 technical report (arXiv:2507.20534)](https://arxiv.org/pdf/2507.20534?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh). That work describes K2 as building on [DeepSeek](/topics/deepseek)-V3, then pushing sparsity further (**384** experts vs DeepSeek-V3’s **256**) and cutting attention heads to **64** (vs **128**) to reduce inference cost.\n\n### Why MoE matters\n\nIf all 1 trillion parameters ran for every token, cost and speed would explode. K2.6 activates about **32B** per token (8 routed experts + 1 shared expert out of 384).\n\nThink of a big office with 384 specialists. For each sentence fragment, a router calls 8 specialists, plus one shared generalist who always sits in the meeting. You get huge capacity (the draft overview calls this roughly GPT-5-class parameter capacity), while the bill looks closer to a 32B model.\n\n### Multi-Head Latent Attention (MLA)\n\nNormal multi-head attention stores large [key/value caches](/glossary/kv-cache) as context grows. That eats memory. [MLA](/glossary/mla) (same family of idea [DeepSeek-V3](https://arxiv.org/abs/2412.19437?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh) popularised; covered in the [K2 report](https://arxiv.org/pdf/2507.20534?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh)) compresses keys and values into a smaller latent vector, then rebuilds them when needed.\n\nSmaller [KV cache](/topics/kv-cache). That is a big reason 256K context can stay practical.\n\n### Training: token efficiency, not only more compute\n\nThe [K2 technical report](https://arxiv.org/pdf/2507.20534?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh) says the hard limit was not only GPUs. It was the shrinking supply of high-quality human text. Choices called out:\n\n: gets more quality out of the same token budget than a plain AdamW-style setup[Muon](/glossary/muon)optimizer: keeps training stable when Muon is aggressive (limits query-key products)[QK-Clip](/glossary/qk-clip)**Synthetic data**: stretches the high-quality corpus further\n\nBase pre-training: about **15.5 trillion** tokens. Their scaling work is also why expert count went higher than DeepSeek-V3.\n\n### What is new in K2.6: Agent Swarm\n\nPer the [DeepInfra overview](https://deepinfra.com/blog/kimi-k2-6-model-overview?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh), [Agent Swarm](/glossary/agent-swarm) is the K2.6 headline versus earlier K2 releases.\n\nThink of a project manager (orchestrator) who breaks a big job into independent pieces, runs many specialist sub-agents in parallel, then merges the result.\n\n| K2.5 | K2.6 | |\n|---|---|---|\n| Parallel sub-agents | up to 100 | up to 300 |\n| Steps per autonomous run | up to 1,500 | up to 4,000 |\n\nOn BrowseComp, published benchmarks report **83.2%** single-agent vs **86.3%** swarm. The gain is more of the task space explored in the same wall-clock time, not a magically smarter single forward pass.\n\nK2.6 also targets long-horizon runs: **12+ hours**, thousands of tool calls. That is closer to “leave it running overnight on a big codebase” than “one chat reply.”\n\n### Benchmarks (vendor-published)\n\nFrom the same [public comparisons](https://deepinfra.com/blog/kimi-k2-6-model-overview?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh) against GPT-5.4, Claude Opus 4.6, and Gemini 3.1 Pro:\n\n| Category | Benchmark | K2.6 | Best competitor listed |\n|---|---|---|---|\n| Agentic | DeepSearchQA | 83.0 | Claude Opus 4.6: 80.6 |\n| Coding | SWE-Bench Pro | 58.6 | GPT-5.4: 57.7 |\n| Coding | SWE-Bench Verified | 80.2 | Claude Opus 4.6: 80.8 |\n| Reasoning | AIME 2026 | 96.4 | GPT-5.4: 99.2 |\n| Vision | MathVision | 93.2 | GPT-5.4: 96.1 |\n\nPattern: stronger on agentic and coding-shaped work; trails on some single-turn math (AIME 2026, and similarly GPQA-Diamond in that write-up). Context is **256K**, not the 1M+ windows some competitors advertise.\n\n### Honest caveat on the research side\n\nThis section draws on arXiv reports, public model overviews, and vendor benchmarks. It is not an independent audit. Self-reported numbers deserve normal skepticism.\n\nStill: unlike the interview’s black-box guesses about embeddings and safety classifiers, MoE, MLA, Muon, QK-Clip, and the 256K window are grounded in published material you can open yourself.\n\n## Final Technical Analysis\n\nKeep two layers separate. Mixing them is how confusion starts.\n\n**Layer 1: what the chat exposed (product behaviour)**\n\nMemory blocks, tool limits, priority order, no draft loop, safety as felt effects. Great for prompting and product design. Weak on exact retrieval math and exact safety wiring.\n\n**Layer 2: what the research and overviews expose (architecture)**\n\nMoE (1T total / about 32B active), MLA, Muon + QK-Clip, about 15.5T pre-train tokens, **256K** context, Agent Swarm (up to 300 sub-agents and 4,000 steps). Great for infra and model choice. Not a full independent eval.\n\nInterview picture:\n\n``` php\nflowchart TD\n  A[\"You type a message\"] --> B[\"Context assembledsystem → skills → meta → memory → tools → history → message\"]\n  B --> C{\"Need a tool?\"}\n  C -->|yes| D[\"Tool routersearch, URL, python, memory, cron, widget\"]\n  D --> E[\"Results injected\"]\n  C -->|no| F[\"Transformer generatestoken by token\"]\n  E --> F\n  F --> G[\"Safety can refuse, hedge, or pivot\"]\n  G --> H[\"You read the answer\"]\n  H --> I[\"Overnight Dream Memorymay consolidate facts\"]\n\n  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  classDef decision fill:#eef6f4,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  class A,B,D,E,F,G,H,I box\n  class C decision\n```\n\nPublished stack picture (from research):\n\n``` php\nflowchart TD\n  A[\"Token in\"] --> B[\"MLA attentioncompressed KV for long context\"]\n  B --> C[\"MoE router\"]\n  C --> D[\"8 routed experts + 1 shared~32B active of 1T\"]\n  D --> E[\"Next-token logits\"]\n  E --> F[\"Optional Agent Swarmup to 300 sub-agents / 4000 steps\"]\n\n  classDef box fill:#f7f5f0,stroke:#2a2a2a,color:#2a2a2a,stroke-width:1px\n  class A,B,C,D,E,F box\n```\n\nWhat I trust from the **chat** for day-to-day use:\n\n- Priority behaviour: System > current user > explicit memory > dream memory > session metadata > history > tool definitions.\n- Tools are first-class, with hard limits (search rounds, step budget).\n- Memory is a presented block, not a live database query from inside the model (max 50 explicit entries in its rules).\n- Generation has no hidden editor. What you see is the first pass.\n- Long context and safety stay partly opaque even to the model.\n\nWhat I trust from the **research / overviews** (with vendor caveat):\n\n- MoE + MLA is the documented spine.\n- Documented context for K2.6 is\n**256K**, not the chat’s** 2M**claim. - Agent Swarm is a real product layer on top of the base model.\n- Training story centres Muon, QK-Clip, synthetic data, and about 15.5T tokens.\n\nWhat I still do not treat as proven:\n\nInterview guesses (embeddings, Ring Attention, exact safety classifiers, nightly consolidation internals), and any benchmark number I have not re-run myself.\n\nThat 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.\n\nIf you only remember three things from this whole post:\n\n- Ask clearly, and verify important facts.\n- Use tools (or ask it to use tools) when the answer must be fresh.\n- For K2.6 architecture numbers, prefer the research:\n**256K context**, MoE 1T/32B active, Agent Swarm up to 300 × 4,000.\n\n## Research\n\nPapers and public sources I used to cross-check the interview (independent of what Kimi said in chat):\n\n[Kimi K2 technical report (arXiv:2507.20534)](https://arxiv.org/pdf/2507.20534?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh)— architecture lineage for K2 / K2.6 ([MoE](/glossary/moe),[MLA](/glossary/mla),[Muon](/glossary/muon),[QK-Clip](/glossary/qk-clip), training tokens).[DeepInfra: Kimi K2.6 model overview](https://deepinfra.com/blog/kimi-k2-6-model-overview?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh)— public spec sheet,[Agent Swarm](/glossary/agent-swarm)numbers, benchmark table used above.[Kimi K2.6 release thread](https://forum.moonshot.ai/t/meet-kimi-k2-6-advancing-open-source-coding/369?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh)— product release notes (Agent Swarm, long-horizon coding).[arXiv abs page for the K2 report](https://arxiv.org/abs/2507.20534?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh)— HTML abstract for arXiv:2507.20534.[DeepSeek-V3 technical report](https://arxiv.org/abs/2412.19437?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh)— lineage for MLA and large MoE designs that K2 builds on.[Attention Is All You Need](https://arxiv.org/abs/1706.03762?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh)— the 2017[Transformer](/glossary/transformer)paper.[Kimi](https://www.kimi.com/?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh)·[Moonshot AI](https://www.moonshot.ai/?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh)·[Kimi API platform](https://platform.moonshot.ai/?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh)·[n8n](https://n8n.io/?utm_source=manish.sh&utm_medium=blog&utm_campaign=inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself&ref=manish.sh)(mentioned in the interview’s blog-idea list).\n\nAlso used in this post:\n\n- Series:\n[Inside LLMs](/series/inside-llms)· sister post:[Inside DeepSeek](/writings/models/inside-deepseek-reverse-engineering-an-ai-assistant-by-interviewing-itself) - Site I interviewed against:\n[manish.sh](https://manish.sh) - Related glossary:\n[Kimi](/glossary/kimi)·[Moonshot AI](/glossary/moonshot-ai)·[LLM](/glossary/large-language-model)·[MoE](/glossary/moe)·[MLA](/glossary/mla)·[Agent Swarm](/glossary/agent-swarm)·[Context window](/glossary/context-window)·[Hallucination](/glossary/hallucination)·[Tool calling](/glossary/tool-calling)·[Autoregressive](/glossary/autoregressive)·[RLHF](/glossary/rlhf)·[Token](/glossary/token)·[KV cache](/glossary/kv-cache)·[Open weights](/glossary/open-weights)·[Prompt engineering](/glossary/prompt-engineering)·[Attention](/glossary/attention-mechanism)·[AI agent](/glossary/ai-agent)·[full glossary](/glossary) - Images:\n[Kimi wordmark](/images/blog/kimi/kimi-text.svg),[Kimi wordmark (dark)](/images/blog/kimi/kimi-text-white.svg),[Moonshot wordmark](/images/blog/kimi/moonshot-text.svg),[Moonshot wordmark (dark)](/images/blog/kimi/moonshot-text-white.svg),[interview screenshot](/images/blog/kimi/kimi-chat.png)\n\nPinch or double-tap to zoom · tap outside to close\n\n## Interactive labs\n\nHands-on demos tied to this post: rough token counting (tiktoken-style estimate), context budget, tool choice, and MoE routing. Numbers are teaching aids, not Moonshot production meters.\n\n### 1. Rough token estimator\n\nReal APIs use tiktoken / SentencePiece. This is a **rough English estimate**(~4 characters per token), good enough to feel context cost.\n\n### 2. Context window budget\n\nFrom the interview order: system, skills/meta/memory, tools, history, then your message. Paper says **256K** for K2.6; the chat claimed **2M**. Slide to see fill.\n\nUsed **0** / **262,144** tokens (0%)\n\n### 3. Which tool would Kimi call?\n\nBased on the interview’s tool map. Pick a need; see the tool it described.\n\n**Tool:** `web_search`\n\nFor current news and live web facts.\n\n### 4. MoE router (paper numbers)\n\nK2.6 public specs: **384** experts, **8 routed** + **1 shared** per token (~32B of 1T active). Click to simulate one token’s routing.\n\n### 5. Awareness: high vs low\n\nFrom session metadata in the chat: `awareness`\n\ncontrols how eagerly past memories are used.\n\n**low:** only use saved context if it is directly relevant. Random small talk should not trigger “how’s that blog post?”\n\nFAQ\n\n## Frequently asked questions\n\n## How did you reverse engineer Kimi K2.6?\n\nI did not open weights or leak system prompts. I interviewed the model about memory, tools, context order, priority, planning, hallucinations, and safety, then wrote down what it claimed and where it admitted it was guessing.\n\n## Who built Kimi?\n\nKimi said it was developed by Moonshot AI (月之暗面), not Anthropic, OpenAI, or Google, and that it was not trained on Claude.\n\n## What is Dream Memory vs Explicit Memory?\n\nDream Memory auto-saves key facts overnight. Explicit Memory is what you tell it to remember, update, or delete on purpose.\n\n## Does Kimi retrieve every memory every turn?\n\nIt said it does not actively retrieve. A pre-populated memory block appears each turn. The selection mechanism is a black box to the model.\n\n## What has highest priority when instructions conflict?\n\nSystem instructions win over everything. Among dynamic inputs, the current user message beats memory and history.\n\n## Is the 2M context claim from the interview official?\n\nNo. The chat mentioned 2M tokens. Published K2.6 specs list a 256K (262,144) context window. Prefer the research and public overviews for architecture numbers.\n\n## Where do MoE, MLA, and Agent Swarm numbers come from?\n\nFrom the Kimi K2 technical report (arXiv:2507.20534) and public K2.6 model overviews — research sources, not from the interview.\n\n### Research this topic further\n\n- Click a tool below (ChatGPT, Perplexity, Claude, or Gemini).\n- We copy the\n**full article + companion guide prompt** to your clipboard. - A new chat tab opens — if the message box is empty or only shows a short note, press\n`Ctrl+V`(Windows/Linux) or` Cmd+V`(Mac) to paste. - Send the message. The model already has the article text — it does not need to open this website.\n\n### Related posts\n\n[22 · 07 · 2026Inside Qwen 3.8-Max-Preview: Reverse Engineering an AI Assistant by Interviewing ItselfI interviewed Qwen 3.8-Max-Preview on memory, tools, context, and hallucinations, then checked published research. Plain English, diagrams, transcript.](/writings/models/inside-qwen-3-8-max-preview-reverse-engineering-an-ai-assistant-by-interviewing-itself)\n\n[21 · 07 · 2026Inside DeepSeek: Reverse Engineering an AI Assistant by Interviewing ItselfInterviewed DeepSeek on how it works, then checked against papers. Same method as Kimi — plainer English and concept diagrams.](/writings/models/inside-deepseek-reverse-engineering-an-ai-assistant-by-interviewing-itself)\n\n[22 · 07 · 2026Inside Character.ai: The Technical Story of What Keeps Users HookedFrom c.ai to Character.ai — what it is, the problem it solves, then Kaiju, memory, Lorebook, and the infra behind long chats.](/writings/ai-tools/inside-character-ai-the-technical-story-of-what-keeps-users-hooked)\n\n### Comments\n\nShare a thought on this post — keep it useful and kind. Comments are moderated before they appear.\n\nLoading comments…", "url": "https://wpnews.pro/news/inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself", "canonical_source": "https://manish.sh/writings/models/inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself/", "published_at": "2026-07-20 18:00:00+00:00", "updated_at": "2026-07-22 21:52:04.908273+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-agents", "ai-research"], "entities": ["Manish Shahi", "Moonshot AI", "Kimi K2.6", "DeepSeek"], "alternates": {"html": "https://wpnews.pro/news/inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself", "markdown": "https://wpnews.pro/news/inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself.md", "text": "https://wpnews.pro/news/inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself.txt", "jsonld": "https://wpnews.pro/news/inside-kimi-k2-6-reverse-engineering-an-ai-assistant-by-interviewing-itself.jsonld"}}